Hi Vinod,
EDC was
written to support up to Dwarf version 3. At the time
version 4 had not been released. I’m not sure if the
bug you’re seeing is related specifically to version 4,
or if it’s just something unexpected in the general
dwarf info. My guess would be the latter. Which
compiler are you using? Some build tools let you choose
which debug format to generate with a switch. That
could be a workaround.
Thanks,
Warren
Hi Warren,
It’s very
sad to say that myself again stuck with the Dwarf stuff.
This time it’s related to the Dwarf version 4. I found
that my code, which using EDC Dwarf reader not working
properly with Dwarf 4 (it’s working perfectly with Dwarf
version 2). Especially it’s not getting any info about
‘C’ files but it’s working fine with ‘asm’ files. So my
question is simple, does the EDC Dwarf reader support
Dwarf version 4. If so, is there any API change specific
to Dwarf 4.
I believe
this is because GCC generates absolute paths in Dwarf on
Windows without the drive letter in many cases. You
could argue that it shouldn’t when not generated on
Windows, or be controlled by a pref. You can probably
log a bug for it, but currently there are no committers
and it’s not being built as part of CDT. For now you’ll
have to fix it locally and do your own build.
Thanks,
Warren
Hey Warren,
The line
info provider stuff worked fine. Think that we can
proceed with it. Thanks for your help. J
Here I
would like to discuss about one more issue related to
dwarf reader. What I have done so far to get this issue
is described below.
=>
I have a
vmlinux elf, which was compiled in the target file
system (/home/somedirectory). I have used it to get the
source file information using DwarfDebugInfoProvider. getSourceFiles API
on a
windows machine (copied the vmlinux.elf to some folder
in the D drive), I got source file path like
D:/home/somedirectory. Which is not expected.
=>
On further
investigation, I found that it’s the problem with DwarfFileHelper class
and its normalizeFilePath
API. In this API, there were some checks like
HostOS.IS_WIN32, and which makes the issue.
Is it a
valid scenario?
Is there
any further developments ongoing with EDC dwarf reader?
Can I
report a bug and submit a patch?
It’s
possible there’s a memory leak in there somewhere. I
don’t see how this snippet is doing what you listed as
your requirements though. I think you’d want to get the
line info provider for each compile unit for 1/2/3. For
4 you can simply get symbol at address (if any). That
will work for code, not data. There is no
correspondence between variable declaration/definition
and source line.
Hi Warren,
I have
changed my VM args as you mentioned below. But the code
snippet given below is still causing the same problem L.
Can you
please check whether the usage of API’s in the snippet
is correct or not (Please take a trial run).
Hi Vinod,
It’s
strange that you’d run out of memory parsing a 92MB
file, as we were parsing files ~1GB. Check your vm heap
arguments. I assume you’re either running/debugging
this from Eclipse. If so, edit the VM args in the
arguments tab of your launch config to have something
like –Xms256m -Xmx512m.
Thanks,
Warren
Hi Warren,
Sorry to
say that still I got some trouble with dwarf reader
stuff. This time we need to parse VMLINUX image (92 MB)
as a part of adding Linux support.
Actually I
am interested on following things.
1. Source file names
2. Address of each source line inside
each source file
3. Line number
4. Symbol information in that line ,
if it is present ( function, global variable etc.) and
its type
I am using
the repository @ eclipse/cdt.edc in GITHUB. Still I am
doing some tests with LineInfoProvider and other stuffs,
which I got from the Test cases in the repository.
Please see
the code snippet I have used .
Path modulePath = new Path("D:/vinod/vmlinux");//Linux kernal
path
ElfExecutableSymbolicsReaderFactory fact = new
ElfExecutableSymbolicsReaderFactory();
IExecutableSymbolicsReader exeReader = fact.createExecutableSymbolicsReader(modulePath);
DwarfDebugInfoProvider dip = new
DwarfDebugInfoProvider(exeReader);
Map<String, List<PublicNameInfo>> variables = dip.getPublicVariables();
final
Iterator<Entry<String, List<PublicNameInfo>>>
it = variables.entrySet().iterator();
while
(it.hasNext()) {
IPath file = null;
Map.Entry pairs = (Map.Entry) it.next();
final String
variableName = (String) pairs.getKey();
IModuleScope moduleScope = dip.getModuleScope();
if(null !=
moduleScope){
moduleScope.getVariablesByName(variableName, false);
//moduleScope.get
Collection<ISymbol> unMangledSymbols = dip.getExecutableSymbolicsReader().findUnmangledSymbols(variableName);
for(ISymbol
symbol: unMangledSymbols){
System.out.println(symbol.getName()
+ symbol.getAddress());
}
}
}
I got the
following Exception ,
Exception
in thread "main" java.lang.OutOfMemoryError: Java heap
space
at
org.eclipse.cdt.debug.edc.internal.symbols.dwarf.DwarfInfoReader.parseCompilationUnitForAddressesPrivate(DwarfInfoReader.java:853)
at
org.eclipse.cdt.debug.edc.internal.symbols.dwarf.DwarfInfoReader.parseCompilationUnitForAddresses(DwarfInfoReader.java:870)
at
org.eclipse.cdt.debug.edc.internal.symbols.dwarf.DwarfDebugInfoProvider.getVariablesByName(DwarfDebugInfoProvider.java:961)
at
org.eclipse.cdt.debug.edc.internal.symbols.dwarf.DwarfModuleScope.getVariablesByName(DwarfModuleScope.java:134)
at MemmoryLeakMain.main(MemmoryLeakMain.java:45)
Expecting a
swift response. J
No
problem. I’m glad it helped.
This might
be a good time to ask the list if anyone else out there
is using EDC? It sort of died when the Nokia group fell
apart, but we’ve been quietly resurrecting it here at
Silicon Labs (with some of the same team from Nokia and
former CDT committers). At some point we’re planning on
contributing back our changes and possibly volunteering
some committers to help maintain it going forward.
Doug, I’ve
been meaning to talk to you about this but have just
been too swamped.
Anyway, I’m
just gauging interest at this point.
Thanks,
Warren
Hi Warren,
Thanks for
the response, it’s a cool one and help me to solve the
problems.
Thanks,
Vinod
Hi Vinod,
If this is
a pure embedded target where the executable will not be
relocated, then you can use the symbol table. See
org.eclipse.cdt.debug.edc.symbols.IExecutableSymbolicsReader.findSymbols(String)
or
org.eclipse.cdt.debug.edc.symbols.IExecutableSymbolicsReader.findUnmangledSymbols(String).
Otherwise
you’ll the module to get the relocated address. See
org.eclipse.cdt.debug.edc.symbols.IModuleScope.getVariablesByName(String,
boolean). Once you have the IVariable you’re looking
for, you can resolve the runtime address by getting the
ILocationProvider, then the IVariableLocation, then the
IAddress.
I hope that
helps.
Thanks,
Warren
Hi All,
We are facing a problem with getting
address of global variables using Dwarf Reader (from EDC
project).
I can’t find a API which gives the
constant address for a global variable (I have checked
with Variable.java ).
Hope somebody can give a better option
to get the same without any side effects.
Thanks in Advance,
Vinod
