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 _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list