objdump disassembly lacking RAM symbol names

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

objdump disassembly lacking RAM symbol names

Paul "LeoNerd" Evans
(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?

--
Paul "LeoNerd" Evans

[hidden email]
http://www.leonerd.org.uk/  |  https://metacpan.org/author/PEVANS

_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list

attachment0 (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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


_______________________________________________
AVR-GCC-list mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: objdump disassembly lacking RAM symbol names

Sivanupandi, Pitchumani
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Loading...