From: Simon Marchi <simark@simark.ca>
To: Luis Machado <luis.machado@linaro.org>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Fix build failure for 32-bit targets
Date: Fri, 1 Oct 2021 12:08:38 -0400 [thread overview]
Message-ID: <c1c21fce-6bde-c64d-0777-8c7c2d20c509@simark.ca> (raw)
In-Reply-To: <46f0c972-d009-d066-bc4f-689660124b63@linaro.org>
On 2021-10-01 11:53 a.m., Luis Machado via Gdb-patches wrote:
> On 10/1/21 12:25 PM, Mike Frysinger wrote:
>> On 01 Oct 2021 08:50, Luis Machado via Gdb-patches wrote:
>>> When building master GDB, I ran into the following:
>>>
>>> binutils-gdb/gdb/bt-utils.c: In function ‘int libbacktrace_print(void*, uintptr_t, const char*, int, const char*)’:
>>> binutils-gdb/gdb/bt-utils.c:93:44: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘uintptr_t {aka unsigned int}’ [-Werror=format=]
>>> snprintf (buf, sizeof (buf), "0x%lx ", pc);
>>>
>>> Fix this by using phex and %s as opposed to 0x%lx.
>>
>> wouldn't PRIxPTR fix it and be simpler ?
>> -mike
>>
>
> I'm happy either way, but GDB uses phex/phex_nz/pulongest much more often.
>
> grep "phex" gdb -R | wc -l
> 143
>
> grep "PRIx" gdb -R | wc -l
> 25
That's probably because GDB (for historical reasons I suppose) uses
these LONGEST/ULONGEST types, so we can't use standard things like
PRIx64 directly. Although we could also define, say, PRIxLONGEST and
PRIxULONGEST and use them in format strings.
But here, since we want to print a uintptr_t, I would also go for
PRIxPTR, it's standard after all:
https://en.cppreference.com/w/cpp/types/integer
Simon
next prev parent reply other threads:[~2021-10-01 16:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-01 11:50 Luis Machado via Gdb-patches
2021-10-01 15:25 ` Mike Frysinger via Gdb-patches
2021-10-01 15:53 ` Luis Machado via Gdb-patches
2021-10-01 16:08 ` Simon Marchi [this message]
2021-10-01 16:11 ` Simon Marchi
2021-10-01 16:32 ` Luis Machado via Gdb-patches
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=c1c21fce-6bde-c64d-0777-8c7c2d20c509@simark.ca \
--to=simark@simark.ca \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@linaro.org \
/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