From: Eli Zaretskii <eliz@gnu.org>
To: gdb-patches@sourceware.org
Cc: tom@tromey.com, brobecker@adacore.com
Subject: Re: Building today's snapshot of GDB with MinGW
Date: Fri, 03 Jul 2020 18:08:52 +0300 [thread overview]
Message-ID: <83v9j4vdob.fsf@gnu.org> (raw)
In-Reply-To: <83tuyqvwdf.fsf@gnu.org> (message from Eli Zaretskii on Thu, 02 Jul 2020 17:12:44 +0300)
> Date: Thu, 02 Jul 2020 17:12:44 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: Joel Brobecker <brobecker@adacore.com>
>
> (top-gdb) p pieces.m_pieces._M_impl._M_start[1]
> $5 = {string = 0x178c5ad8 "%d", argclass = int_arg, n_int_args = 0}
> (top-gdb) p pieces.m_pieces._M_impl._M_start[2]
> $6 = {string = 0x178c5adc "%I64x", argclass = long_long_arg, n_int_args = 0}
>
> As you see, we replace "%llx" with "%I64x", and the comparison then
> fails. Would it be okay to fix this by providing a different
> expected_pieces when USE_PRINTF_I64 is non-zero?
Actually, USE_PRINTF_I64 seems to be zero in my build, so I don't
really see why does format.cc replace "%llx" with "%I64x". Could
someone please help me see that which I'm missing here?
prev parent reply other threads:[~2020-07-03 15:08 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-29 18:27 Eli Zaretskii
2020-06-29 20:36 ` Christian Biesinger
2020-06-30 14:09 ` Eli Zaretskii
2020-06-30 22:24 ` Simon Marchi
2020-07-01 15:09 ` Eli Zaretskii
2020-07-02 13:50 ` Eli Zaretskii
2020-07-02 14:25 ` Simon Marchi
2020-07-02 14:30 ` Simon Marchi
2020-07-02 17:47 ` Eli Zaretskii
2020-07-02 14:40 ` Pedro Alves
2020-07-02 17:46 ` Eli Zaretskii
2020-07-02 18:21 ` Pedro Alves
2020-07-02 18:33 ` Eli Zaretskii
2020-07-02 18:34 ` Pedro Alves
2020-07-01 15:20 ` Eli Zaretskii
2020-07-01 19:25 ` Christian Biesinger
2020-07-02 2:29 ` Eli Zaretskii
2020-07-02 10:18 ` Hannes Domani
2020-07-02 13:20 ` Eli Zaretskii
2020-07-06 10:39 ` Hannes Domani
2020-07-06 16:35 ` Eli Zaretskii
2020-07-01 19:25 ` Joel Brobecker
2020-07-02 13:46 ` Eli Zaretskii
2020-06-30 16:18 ` Eli Zaretskii
2020-06-30 18:21 ` Christian Biesinger
2020-06-30 18:28 ` Eli Zaretskii
2020-07-01 19:29 ` Joel Brobecker
2020-07-02 2:31 ` Eli Zaretskii
2020-07-01 19:30 ` Joel Brobecker
2020-07-02 13:39 ` Eli Zaretskii
2020-07-03 15:25 ` Joel Brobecker
2020-07-27 9:49 ` Tom de Vries
2020-07-27 10:05 ` Tom de Vries
2020-07-27 10:26 ` Tom de Vries
2020-07-27 11:48 ` [committed][gdb/build] Fix typo sys/sockets.h -> sys/socket.h Tom de Vries
2020-07-27 12:51 ` Joel Brobecker
2020-07-27 14:18 ` Building today's snapshot of GDB with MinGW Eli Zaretskii
2020-07-02 14:12 ` Eli Zaretskii
2020-07-03 15:08 ` Eli Zaretskii [this message]
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=83v9j4vdob.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/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