GNU Arm Embedded Toolchain

address differences between cortex-m4 loaded image and objdump -S listing

Asked by Steve Stearns

Greetings,

I'm building under linux with arm-none-eabi-... tools for Cortex-m4. I'm loading (on windows) the .out file via IAR or, equivalently, the .bin file via ST Utils. IAR and ST Utils agree with each other on what should get loaded where in the flash. However, none of the functions are loaded where the ...eabi-objdump -S generated listing says they are. Also, the offset between the flash locations and the listing locations is not constant for different routines.

How do I generate a listing in which the memory locations match the locations as loaded into flash?

Thanks in advance for any guidance,

Steve.

Question information

Language:
English Edit question
Status:
Solved
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Solved by:
Steve Stearns
Solved:
Last query:
Last reply:
Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said : 		#1

Hi Steve,

my guess is that objdump -S shows the virtual memory address rather than the load address. You can find both information in the output of readelf -l but the granularity is the segments in the executable rather than the functions. You need to do the offset computation by yourself.

Best regards.

Revision history for this message
Steve Stearns (sstearns) said : 		#2

I'm very appreciative of the suggestion but, alas, that's not the case
here. This is a static link and the readelf output shows no offset between
the VirtAddr and the PhysAddr. Additionally, all the code is in a single
segment so all of the functions would have the same offset which, sadly,
they don't. I only have three readelf listed segments which are
 associated with: code, initialized variables and uninitialized ram.

It seems reasonable to me that there must be some (even if inconvenient)
way to generate a correctly located listing as, after all, the loaders have
to do it...

Optimistically yours,

Steve.

On Fri, Jun 5, 2015 at 2:56 AM, Thomas Preud'homme <
<email address hidden>> wrote:

> Your question #267784 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/267784
>
> Status: Open => Answered
>
> Thomas Preud'homme proposed the following answer:
> Hi Steve,
>
> my guess is that objdump -S shows the virtual memory address rather than
> the load address. You can find both information in the output of readelf
> -l but the granularity is the segments in the executable rather than the
> functions. You need to do the offset computation by yourself.
>
> Best regards.
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
>
> https://answers.launchpad.net/gcc-arm-embedded/+question/267784/+confirm?answer_id=0
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/gcc-arm-embedded/+question/267784
>
> You received this question notification because you asked the question.
>

Revision history for this message
Steve Stearns (sstearns) said : 		#3

Update: In the category of obscure user tricks, it appears that via a non-obvious build error in one of the libs that was linked into the main.out, the resulting linked and located file was corrupted in a way that was not apparent to either ...-objdump or either of my flash loaders. However once that was fixed (as part of fixing what was thought to be an unrelated lib specific issue) the memory image and the listing now agree.

Thanks again for your help nonetheless.

Best regards,
Steve.