[Top][All Lists]

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

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

From: Svein E. Seldal
Subject: Re: [avr-gcc-list] [VOTE] objdump patch
Date: Mon, 13 Sep 2004 22:34:34 +0200
User-agent: Mozilla Thunderbird 0.7.3 (X11/20040830)

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.


reply via email to

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