[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Senthil Kumar Selvaraj
Subject: Re: [avr-gcc-list] objdump disassembly lacking RAM symbol names
Date: Wed, 25 May 2016 15:12:16 +0530
User-agent: mu4e 0.9.17; emacs 24.5.1

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]