From: Joel Brobecker <brobecker@adacore.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] convert a host address to a string
Date: Fri, 09 Jan 2009 13:12:00 -0000 [thread overview]
Message-ID: <20090109131227.GL24105@adacore.com> (raw)
In-Reply-To: <200901081326.n08DQEgY002357@brahms.sibelius.xs4all.nl>
[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]
> > 3. Work through uintptr_t.
> >
> > #ifdef PRINTF_HAS_LONG_LONG
> > fprintf (buf, "0x%llx", (unsigned long long) (uintptr_t) address);
> > #else
> > fprintf (buf, "0x%lx", (unsigned long) (uintptr_t) address);
> > #endif
>
> This wouldn't be the first place where we'd use a double cast in
> connection with intptr_t/uintptr_t. So I'd say that while this is a
> bit ugly, it's certainly acceptable. It's by far the simplest way to
> fix things.
Here is a new patch implementing this approach. As I told Kai,
it's probably not going to work for x86_64/XP, but it works for
x86_64/Vista (I think Kai agreed to take on the job of improving
this approach to work on XP as well :-).
2009-01-09 Joel Brobecker <brobecker@adacore.com>
* utils.c (host_address_to_string): Cast the address to uintptr_t
first to avoid a possible compilation warning about casting to
an integer of the wrong size. Then format the address using
unsigned long long if supported by printf. Otherwise, fallback
on using usingned long, hoping that long is large enough to hold
an address.
Tested on x86-linux. I also verified that it still builds on
x86_64 Vista, as well as x86/Windows XP (on XP, PRINTF_HAS_LONG_LONG
is undefined).
--
Joel
[-- Attachment #2: host_addr_to_str.diff --]
[-- Type: text/plain, Size: 2332 bytes --]
diff --git a/gdb/utils.c b/gdb/utils.c
index 9e2dfd7..dd606a2 100644
--- a/gdb/utils.c
+++ b/gdb/utils.c
@@ -3071,10 +3071,44 @@ host_address_to_string (const void *addr)
{
char *str = get_cell ();
- /* We could use the %p conversion specifier to sprintf if we had any
- way of knowing whether this host supports it. But the following
- should work on the Alpha and on 32 bit machines. */
- sprintf (str, "0x%lx", (unsigned long) addr);
+ /* We do not use the %p conversion specifier, because the resulting
+ image can vary from implementation to implementation. For instance,
+ some implementations format the pointer value with a leading "0x"
+ whereas others don't (Solaris, for instance). Also, it is unspecified
+ whether the alphabetical digits are printed using uppercase letters
+ or not (in GDB, we want lowercase).
+
+ So we use the %x type instead. This, however, introduces
+ a couple of issues:
+
+ 1. The %x type expects an integer value, not a pointer.
+ So we first need to cast our pointer to an integer type
+ whose size is identical to the size of our pointer.
+ We use uintptr_t for that.
+
+ 2. The %x type alone expects and int, which is not always
+ large enough to hold an address. Usually, type "long"
+ has the same size as pointers, but certain ABIs define
+ the size of pointers to be larger than the size of long
+ (64bit Windows is one such example).
+
+ So, to be certain to have a type that's large enough
+ to hold an address, we need to use "long long". But
+ the trick is that not all printf implementations support
+ the "ll" modifier. On those platforms where the "ll"
+ modifier is not available, we'll assume that type "long"
+ is large enough to contain an address.
+
+ To make sure that the type we pass to sprintf matches
+ the type we specified in our expression, we perform
+ a second cast to "unsigned long long" if we used "%llx",
+ or "unsigned long" if we used "%lx". */
+
+#ifdef PRINTF_HAS_LONG_LONG
+ sprintf (str, "0x%llx", (unsigned long long) (uintptr_t) addr);
+#else
+ sprintf (str, "0x%lx", (unsigned long) (uintptr_t) addr);
+#endif
return str;
}
next prev parent reply other threads:[~2009-01-09 13:12 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-07 12:19 Joel Brobecker
2009-01-07 16:17 ` Mark Kettenis
2009-01-08 10:19 ` Joel Brobecker
2009-01-08 10:25 ` Kai Tietz
2009-01-08 10:48 ` Joel Brobecker
2009-01-08 11:02 ` Kai Tietz
2009-01-08 11:25 ` Joel Brobecker
2009-01-08 11:31 ` Kai Tietz
2009-01-08 12:49 ` Mark Kettenis
2009-01-08 12:54 ` Joel Brobecker
2009-01-08 13:04 ` Kai Tietz
2009-01-08 13:12 ` Mark Kettenis
2009-01-08 13:26 ` Mark Kettenis
2009-01-08 13:35 ` Kai Tietz
2009-01-08 13:42 ` Joel Brobecker
2009-01-08 14:04 ` Kai Tietz
2009-01-08 16:18 ` Mark Kettenis
2009-01-08 16:23 ` Kai Tietz
2009-01-09 9:57 ` Joel Brobecker
2009-01-09 10:05 ` Kai Tietz
2009-01-09 13:12 ` Joel Brobecker [this message]
2009-01-09 14:28 ` Kai Tietz
2009-01-10 7:12 ` Joel Brobecker
2009-01-10 13:31 ` Kai Tietz
2009-01-10 13:34 ` Kai Tietz
2009-01-10 13:58 ` Mark Kettenis
2009-01-10 14:04 ` Mark Kettenis
2009-01-10 14:15 ` Kai Tietz
2009-01-10 14:22 ` Mark Kettenis
2009-01-10 14:25 ` Kai Tietz
2009-01-11 13:31 ` Joel Brobecker
2009-01-11 13:53 ` Mark Kettenis
2009-01-13 12:09 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090109131227.GL24105@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox