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

[Pitchumani Sivanupandi]

On Wed, 2016-05-25 at 15:12 +0530, Senthil Kumar Selvaraj wrote:
> 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.
> 

Fixed by adding default data address space origin to the symbol
addresses. Disassembling now can show the symbol names in the comments.
https://sourceware.org/ml/binutils/2016-06/msg00024.html

Regards,
Pitchumani