[patch] '0x' prefix on objdump addresses

[patch] '0x' prefix on objdump addresses

[Graydon Hoare]

Hi,

I've had a customer file a bug on this item, and on closer inspection it
appears that all objdump configurations fail to distinguish the printed
forms of different sorts of address operands which resolve near symbols;
eg. 15 (unsigned, hex) and 15 (signed, decimal). The hex ought to be
printed as 0x15, by customer's reckoning.

I talked to fche about this, and his impression was it ought to have
been fixed in objdump long ago (and it was fixed, back in 1997, for
symbols which are not resolved near addresses); is there a general
consensus about why it should/shouldn't happen for general addresses? 

The biggest problem I can forsee is the large-ish number of testsuites
this would trivially invalidate. The whole gas suite, at least, would
need adjusting. Any volunteers?

Here's the patch, at any rate.

-graydon

Index: objdump.c
===================================================================
RCS file: /cvs/src/src/binutils/objdump.c,v
retrieving revision 1.46
diff -u -r1.46 objdump.c
--- objdump.c   2001/12/18 08:22:30     1.46
+++ objdump.c   2002/01/10 20:01:05
@@ -797,6 +797,7 @@
      struct disassemble_info *info;
      boolean skip_zeroes;
 {
+  (*info->fprintf_func) (info->stream, "0x");
   objdump_print_value (vma, info, skip_zeroes);
 
   if (sym == NULL)

Re: [patch] '0x' prefix on objdump addresses

[Hans-Peter Nilsson]

On 10 Jan 2002, Graydon Hoare wrote:
> The biggest problem I can forsee is the large-ish number of testsuites
> this would trivially invalidate. The whole gas suite, at least, would
> need adjusting. Any volunteers?

Aren't you supposed to fix any breakages in the test-suite (gas
and ld, maybe elsewhere) when you change objdump output?

brgds, H-P

Re: [patch] '0x' prefix on objdump addresses

[Graydon Hoare]

On Thu, 2002-01-10 at 16:38, Hans-Peter Nilsson wrote:
> On 10 Jan 2002, Graydon Hoare wrote:
> > The biggest problem I can forsee is the large-ish number of testsuites
> > this would trivially invalidate. The whole gas suite, at least, would
> > need adjusting. Any volunteers?
> 
> Aren't you supposed to fix any breakages in the test-suite (gas
> and ld, maybe elsewhere) when you change objdump output?

yes, of course. I really just want to double-check with the wider
objdump user/developer community to ensure the work is not the sort of
thing someone is going to immediately undo, if I happen to do it; and
perhaps raise anyone's antennae if they think their own testsuites,
outside the typical toolchain suites, are going to break.

-graydon

Re: [patch] '0x' prefix on objdump addresses

[Andrew Cagney]

> Hi,
> 
> I've had a customer file a bug on this item, and on closer inspection it
> appears that all objdump configurations fail to distinguish the printed
> forms of different sorts of address operands which resolve near symbols;
> eg. 15 (unsigned, hex) and 15 (signed, decimal). The hex ought to be
> printed as 0x15, by customer's reckoning.


Would you mind providing examples.

Andrew

Re: [patch] '0x' prefix on objdump addresses

[LeakyStain]

I would strongly argue against this trivial change; it is not worth the
trouble. I have test suites that would break.

And besides, the _correct_ syntax for a hex number is 16#abcd# :) 
(from Ada, the world's best language :).

If you _really_ want a different output syntax, put in an option to
enable
it.

-- Stephe

Graydon Hoare wrote:
> 
> On Thu, 2002-01-10 at 16:38, Hans-Peter Nilsson wrote:
> > On 10 Jan 2002, Graydon Hoare wrote:
> > > The biggest problem I can forsee is the large-ish number of testsuites
> > > this would trivially invalidate. The whole gas suite, at least, would
> > > need adjusting. Any volunteers?
> >
> > Aren't you supposed to fix any breakages in the test-suite (gas
> > and ld, maybe elsewhere) when you change objdump output?
> 
> yes, of course. I really just want to double-check with the wider
> objdump user/developer community to ensure the work is not the sort of
> thing someone is going to immediately undo, if I happen to do it; and
> perhaps raise anyone's antennae if they think their own testsuites,
> outside the typical toolchain suites, are going to break.
> 
> -graydon

Re: [patch] '0x' prefix on objdump addresses

[Hans-Peter Nilsson]

On 10 Jan 2002, Graydon Hoare wrote:

> On Thu, 2002-01-10 at 16:38, Hans-Peter Nilsson wrote:
> > On 10 Jan 2002, Graydon Hoare wrote:
> > > The biggest problem I can forsee is the large-ish number of testsuites
> > > this would trivially invalidate. The whole gas suite, at least, would
> > > need adjusting. Any volunteers?
> >
> > Aren't you supposed to fix any breakages in the test-suite (gas
> > and ld, maybe elsewhere) when you change objdump output?
>
> yes, of course. I really just want to double-check with the wider
> objdump user/developer community to ensure the work is not the sort of
> thing someone is going to immediately undo, if I happen to do it; and
> perhaps raise anyone's antennae if they think their own testsuites,
> outside the typical toolchain suites, are going to break.

FWIW, I don't really disagree with the change, but I agree an
example would help.  Particularly, an example that shows where
no-0x actually leads to confusion might help convincing those
arguing against the patch.

brgds, H-P

Re: [patch] '0x' prefix on objdump addresses

[Graydon Hoare]

On Thu, 2002-01-10 at 17:40, Andrew Cagney wrote:
> > Hi,
> > 
> > I've had a customer file a bug on this item, and on closer inspection it
> > appears that all objdump configurations fail to distinguish the printed
> > forms of different sorts of address operands which resolve near symbols;
> > eg. 15 (unsigned, hex) and 15 (signed, decimal). The hex ought to be
> > printed as 0x15, by customer's reckoning.
> 
> 
> Would you mind providing examples.

Sure:

$ objdump -d ne_locks.o

  [...]
  15f:   8b 1f                   mov    (%edi),%ebx
  161:   85 db                   test   %ebx,%ebx
- 163:   74 2b                   je     190 <submit_lock+0x40>
+ 163:   74 2b                   je     0x190 <submit_lock+0x40>
  165:   8d 74 26 00             lea    0x0(%esi,1),%esi
  169:   8d bc 27 00 00 00 00    lea    0x0(%edi,1),%edi
  [...]

It's a matter of consistency; all hex values in the disassembly _except_
this case are already prefixed by "0x".  

-graydon

Re: [patch] '0x' prefix on objdump addresses

[Ian Lance Taylor]

Graydon Hoare <graydon@redhat.com> writes:

> $ objdump -d ne_locks.o
> 
>   [...]
>   15f:   8b 1f                   mov    (%edi),%ebx
>   161:   85 db                   test   %ebx,%ebx
> - 163:   74 2b                   je     190 <submit_lock+0x40>
> + 163:   74 2b                   je     0x190 <submit_lock+0x40>
>   165:   8d 74 26 00             lea    0x0(%esi,1),%esi
>   169:   8d bc 27 00 00 00 00    lea    0x0(%edi,1),%edi
>   [...]
> 
> It's a matter of consistency; all hex values in the disassembly _except_
> this case are already prefixed by "0x".  

The addresses on the left are in hex but are not prefixed by 0x.  The
190 is an address which will appear on the left in a few lines.  If we
add the 0x before 190, then I think we have add a 0x to the addresses
on the left as well.

Ian

Re: [patch] '0x' prefix on objdump addresses

[Philip Blundell]

On Mon, 2002-01-14 at 17:23, Graydon Hoare wrote:
>   [...]
>   15f:   8b 1f                   mov    (%edi),%ebx
>   161:   85 db                   test   %ebx,%ebx
> - 163:   74 2b                   je     190 <submit_lock+0x40>
> + 163:   74 2b                   je     0x190 <submit_lock+0x40>
>   165:   8d 74 26 00             lea    0x0(%esi,1),%esi
>   169:   8d bc 27 00 00 00 00    lea    0x0(%edi,1),%edi
>   [...]
> 
> It's a matter of consistency; all hex values in the disassembly _except_
> this case are already prefixed by "0x".  

Well, except also the addresses themselves (which are, of course, the
targets of the branches in question).  Not that I care particularly, but
the old behaviour never struck me as very inconsistent.  

p.