Re: [avr-gcc-list] objdump disassembly lacking RAM symbol names

[Senthil Kumar Selvaraj]

Paul LeoNerd Evans writes:

> (First off, this is a binutils question, not really gcc itself; hoping
> this is still the appropriate mailing list - if not let me know where
> it should go instead).
>
> I find that `objdump -d` doesn't give me RAM symbol names when
> disassembling `ld` or `st` instructions. For example, in a program
> containing
>
>   static uint8_t long_buttons;
>
> My nm -d output contains:
>
>   $ avr-nm .build/ppqbase.elf | grep long_b
>   008002ec b long_buttons
>
> So it lives at address 0x2EC in RAM, but yet
>
>   $ avr-objdump -d .build/ppqbase.elf | grep long_b
>
>   $ avr-objdump -d .build/ppqbase.elf | grep 2EC
>      c28:       80 91 ec 02     lds     r24, 0x02EC
>      c38:       80 91 ec 02     lds     r24, 0x02EC
>      d00:       d0 93 ec 02     sts     0x02EC, r29
>
> I had been hoping the output to decode these addresses into symbolic
> variable names.
>
> Is there something special I need to do to enable this?

Off the top of my head, I think it's because objdump thinks long_buttons
is at 0x8002ec, whereas the immediate values in the lds/sts instructions
don't have the 0x80 prefix (0x02ec). Maybe objdump can be taught to
ignore the 0x80 prefix - I'll check and let you know whether that's
really the problem and if it is fixable.

Regards
Senthil