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