AnsweredAssumed Answered

ADSP-SC58x SHARC+ : generating listing files

Question asked by pinaz on Nov 30, 2015
Latest reply on Dec 21, 2015 by kennie

objdump (the open-source software packaged into CCES) is capable of decoding ELF debugging information (at least for known, published architectures).

 

This makes it possible to generate a listing file intermixed with the original source code (for the ARM on the ADSP-SC58x).  Example usage would be:

 

"c:\Analog Devices\CrossCore Embedded Studio 2.1.0\ARM\arm-none-eabi\arm-none-eabi\bin"\objdump -S user_Core0

 

(Side note: why does CCES name ARM ELF files with no file name extension!?)

 

Alas, the same functionality doesn't seem to be available for SHARC(+).

 

One can see that CCES is generating debug line information (by using objdump to print out the ELF debugging information in a SHARC "DXE"):

 

"c:\Analog Devices\CrossCore Embedded Studio 2.1.0\ARM\arm-none-eabi\arm-none-eabi\bin"\objdump -Wl user_Core1.dxe

 

However, there doesn't seem to be a command line SHARC utility that provides the equivalent to objdump -S.

 

The closest seems to be

 

"c:\Analog Devices\CrossCore Embedded Studio 2.1.0\elfdump" -ns foo user_Core1.dxe

 

where "foo" is replaced with the name of section being decoded.  This section name can be found by adding the "Generate symbol map (-map)" option to the project settings for the SHARC linker.  That, then, generates an XML file that can be loaded with Internet Explorer (or other browser with XML viewing capability).  Then, the user can look for the particular "Output section".

 

objdump uses the ELF information to know which sections are code and which are data, so it eliminates that complexity.  There is a "-ns *" option for elfdump, but that decodes all sections, including data.

 

However, even after going through this complexity, all elfdump outputs is the public symbol names at the corresponding first instruction.  There is no intermixed source code.

 

Am I missing something?  Thanks.

Outcomes