Re: [avr-gcc-list] [VOTE] objdump patch

[Svein E. Seldal]

Ben L. Titzer wrote:
> Moreover, I'd like to propose the following (or at least a switch that 
> enables the following):
>
> > > 0x20c:       0x02 0xc0           rjmp    0x212 <.do_copy_data_start>  
> > >    ; .+4

The decision to not use 0x as a prefix to hexadecimal numbers are caused 
by the convension used by binutils (globally). The address and the 
machine-code are not printed by the avr specific part of binutils, but 
rather by the global implementation. In fact, objdump has a tendency not 
to use 0x prefix on any hexadecimal number: The function that I call to 
get the symbol name will for the example above return:

        "212 <.do_copy_data_start>"

The AVR port, uses the 0x prefix in all of its hexadecimal numbers in 
the opcodes. So I adopted this scheme and added 0x as a prefix to the 
symbol string to make sure these prints in the same manner as the rest.

The objdump output on other targets, like i386, does not have 0x on the 
opcode bytes. Nor do they use 0x in front of the symbol references, 
because it refers to _line_ 80497c0, not address 0x80497c0. But other 
immediate numbers in the op-codes are still listed in hex with 0x prefix.

8049796:    a1 58 da 0b 08        mov    0x80bda58,%eax
804979b:    74 21                 je     80497c0 <frame_dummy+0x30>

Hence my "0x" addition on the "212 <..." string print might or might not 
be the correct thing to do. Mostly in respect of the consistency of all 
binutils tools and targets.

If you do want this to change, you can send a mail to 
mailto:address@hidden and see what the community thinks 
about this idea.

HTH,
Svein