From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cagney <ac131313@cygnus.com>
To: "H . J . Lu" <hjl@lucon.org>
Cc: GDB <gdb@sourceware.cygnus.com>
Subject: Re: Print 64bit address from gdb
Date: Thu, 09 Aug 2001 17:30:00 -0000
Message-id: <3B732B2A.1020304@cygnus.com>
References: <20010809161153.A25494@lucon.org>
X-SW-Source: 2001-08/msg00101.html

> I am looking at the sign extended vma bug. The gdb output doesn't make
> any sesnes to me:
> 
> During symbol reading, inner block (0x802ac9d4-0xffffffff) not inside outer block (0x802aca18-0xffffffff).


Mutter something about varargs being dangerous ....  This was on a 
little endian host right?


> There is
> 
> struct complaint innerblock_anon_complaint =
> {"inner block (0x%lx-0x%lx) not inside outer block (0x%lx-0x%lx)", 0, 0};
> 
> I don't think it works with the sign extended vma from the 64bit bfd.
> Am I right? Are we going to fix it? I guess we should pass
> 
> {"inner block (0x%llx-0x%llx) not inside outer block (0x%llx-0x%llx)", 0, 0};
> 
> if the address is long long.


``long long''? ``%ll''?

There are two possible fixes.  Use paddr()/paddr_nz() when the message 
is for debugging or is considered language independant raw value.  Use 
GDB's print formatting mechanism when the context is language dependant.

Looking at complaints.[hc] other than changing things to functions, is 
there a robust (i.e. verifiable at complile time) way of fixing this?

	Andrew