Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Address of global variables using EDC Dwarf Reader

Let me check about the compiler options.

 

Thanks for the reply Warren.

 

Best Regards,

Vinod

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Warren Paul
Sent: Wednesday, October 09, 2013 5:56 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Address of global variables using EDC Dwarf Reader

 

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

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Vinod Appu P. G.
Sent: Wednesday, October 09, 2013 7:05 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Address of global variables using EDC Dwarf Reader

 

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.

 

Best Regards,

Vinod

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Warren Paul
Sent: Thursday, July 11, 2013 10:01 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Address of global variables using EDC Dwarf Reader

 

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

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Vinod Appu P. G.
Sent: Thursday, July 11, 2013 1:53 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Address of global variables using EDC Dwarf Reader

 

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?

 

Best Regards,

Vinod

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Warren Paul
Sent: Monday, July 01, 2013 11:24 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Address of global variables using EDC Dwarf Reader

 

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.

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Vinod Appu P. G.
Sent: Monday, July 01, 2013 9:09 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Address of global variables using EDC Dwarf Reader

 

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).

 

Best Regards,

Vinod

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Warren Paul
Sent: Friday, June 28, 2013 6:29 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Address of global variables using EDC Dwarf Reader

 

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

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Vinod Appu P. G.
Sent: Friday, June 28, 2013 12:08 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Address of global variables using EDC Dwarf Reader

 

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

 

Best Regards,

Vinod

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Warren Paul
Sent: Wednesday, February 20, 2013 10:46 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Address of global variables using EDC Dwarf Reader

 

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

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Vinod Appu P. G.
Sent: Wednesday, February 20, 2013 4:23 AM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Address of global variables using EDC Dwarf Reader

 

Hi Warren,

 

Thanks for the response, it’s a cool one and help me to solve the problems.

 

Thanks,

Vinod

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Warren Paul
Sent: Wednesday, February 13, 2013 12:55 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Address of global variables using EDC Dwarf Reader

 

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

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Vinod Appu P. G.
Sent: Tuesday, February 12, 2013 4:55 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Address of global variables using EDC Dwarf Reader

 

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

 

 

***** Confidentiality Statement/Disclaimer *****

This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt.
The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message.


 

***** Confidentiality Statement/Disclaimer *****

This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt.
The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message.


 

***** Confidentiality Statement/Disclaimer *****

This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt.
The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message.




This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you.

 
***** Confidentiality Statement/Disclaimer *****

This message and any attachments is intended for the sole use of the intended recipient. It may contain confidential information. Any unauthorized use, dissemination or modification is strictly prohibited. If you are not the intended recipient, please notify the sender immediately then delete it from all your systems, and do not copy, use or print. Internet communications are not secure and it is the responsibility of the recipient to make sure that it is virus/malicious code exempt.
The company/sender cannot be responsible for any unauthorized alterations or modifications made to the contents. If you require any form of confirmation of the contents, please contact the company/sender. The company/sender is not liable for any errors or omissions in the content of this message.

Back to the top