From: Pedro Alves <palves@redhat.com>
To: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Change gdbserver to use existing gdbsupport
Date: Wed, 19 Feb 2020 17:42:00 -0000 [thread overview]
Message-ID: <48984f7d-f851-84c8-1145-95fbfbbade23@redhat.com> (raw)
In-Reply-To: <20200219170643.10725-1-tom@tromey.com>
On 2/19/20 5:06 PM, Tom Tromey wrote:
> This changes the gdbserver build to use the gdbsupport that was built
> for gdb.
>
> The most notable change here is that CORE_ADDR is always a 64-bit
> type. This makes it so that gdb acts as if it were always built in
> 64-bit mode.
>
> I tested this locally, and I tried it with a few crosses using
> AdaCore's internal test suite (including a 32-bit build). However, I
> don't have a very clear idea of what code might break due to the
> switch from a 32- to 64-bit CORE_ADDR.
I'm surprised you didn't hit any problem, because last time we chatted
about it, I quickly tried it, and ran into a small number of places
that needed adjustment.
I just tried it again, and I get, for example, with
a i686-pc-linux-gnu build:
$ make V=1 remote.o
g++ -m32 -x c++ -g3 -O0 (....) -c -o remote.o -MT remote.o -MMD -MP -MF ./.deps/remote.Tpo /home/pedro/gdb/binutils-gdb/src/gdb/remote.c
In file included from /home/pedro/gdb/binutils-gdb/src/gdb/defs.h:37:0,
from /home/pedro/gdb/binutils-gdb/src/gdb/remote.c:22:
/home/pedro/gdb/binutils-gdb/src/gdb/remote.c: In member function ‘virtual void remote_target::download_tracepoint(bp_location*)’:
../bfd/bfd.h:198:62: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘CORE_ADDR {aka long long unsigned int}’ [-Werror=format=]
#define sprintf_vma(s,x) sprintf (s, "%08" BFD_VMA_FMT "x", x)
^
/home/pedro/brno/pedro/gdb/binutils-gdb/src/gdb/remote.c:12817:3: note: in expansion of macro ‘sprintf_vma’
sprintf_vma (addrbuf, tpaddr);
^~~~~~~~~~~
/home/pedro/gdb/binutils-gdb/src/gdb/remote.c: In member function ‘virtual void remote_target::enable_tracepoint(bp_location*)’:
../bfd/bfd.h:198:62: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘CORE_ADDR {aka long long unsigned int}’ [-Werror=format=]
#define sprintf_vma(s,x) sprintf (s, "%08" BFD_VMA_FMT "x", x)
...
If I use "make -k", I run into a few more like the above in two or three
more files.
I'd prefer to see this conversion in two separate patches. One (or more) that
removes the bfd dependency from gdb's gdbsupport, which potentially is a material
change for making GDB always use 64-bit types, and then a separate change
to make gdbserver use top level gdbsupport.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2020-02-19 17:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-19 17:06 Tom Tromey
2020-02-19 17:42 ` Pedro Alves [this message]
2020-02-19 19:18 ` Tom Tromey
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=48984f7d-f851-84c8-1145-95fbfbbade23@redhat.com \
--to=palves@redhat.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