| Message ID | 8736bd3jt2.fsf@redhat.com |
|---|---|
| State | New |
| Headers | show |
>>>>> "Sergio" == Sergio Durigan Junior <sergiodj@redhat.com> writes:
Sergio> I'm attaching a patch that works OK for me here. WDYT?
This one includes that:
https://sourceware.org/ml/gdb-patches/2020-02/msg00426.html
I see that Luis responded. I'll read that and see what's up.
Tom
>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes: >>>>> "Sergio" == Sergio Durigan Junior <sergiodj@redhat.com> writes: Sergio> I'm attaching a patch that works OK for me here. WDYT? Tom> This one includes that: Tom> https://sourceware.org/ml/gdb-patches/2020-02/msg00426.html Tom> I see that Luis responded. I'll read that and see what's up. I'm going to check it in now. Tom
Hi Tom, On 2/14/20 6:14 PM, Tom Tromey wrote: >>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes: > >>>>>> "Sergio" == Sergio Durigan Junior <sergiodj@redhat.com> writes: > Sergio> I'm attaching a patch that works OK for me here. WDYT? > > Tom> This one includes that: > > Tom> https://sourceware.org/ml/gdb-patches/2020-02/msg00426.html > > Tom> I see that Luis responded. I'll read that and see what's up. > > I'm going to check it in now. > > Tom > I ran into the following this morning... make[2]: Entering directory '/home/luis.machado/work/tcwg/build/binutils-gdb-master/gdbserver' make[2]: *** No rule to make target '../gnulib/import/libgnu.a', needed by 'gdbserver'. Stop. This was with a build using a configure line containing "--disable-gdb" but no "--disable-gdbserver". Should --disable-gdb also imply --disable-gdbserver? Or should we be able to build gdbserver without building gdb (sounds a bit more complex)?
On Mon, 17 Feb 2020, Luis Machado wrote: > Should --disable-gdb also imply --disable-gdbserver? Or should we be > able to build gdbserver without building gdb (sounds a bit more complex)? Nope, `--disable-gdb --enable-gdbserver' is typical for a cross-debug environment, where you want to configure and build cross-GDB with `--host=foo --target=bar' and `gdbserver' with `--host=bar'. Sometimes your build environment may not even be capable to build native GDB with `--host=bar', or your target system to run it, and in any case building GDB takes a lot of processing time compared to `gdbserver'. So it would be a waste of resources if we forced people to do that. I build `gdbserver' by itself routinely, although I only did the minimum to convert from the old layout, that is rather than calling `configure' from gdb/gdbserver/ I now call it from gdbserver/. So far it has worked, although with the new arrangement it probably qualifies as a hack, and may stop working sometime. Maciej
On 2/17/20 11:21 AM, Maciej W. Rozycki wrote: > On Mon, 17 Feb 2020, Luis Machado wrote: > >> Should --disable-gdb also imply --disable-gdbserver? Or should we be >> able to build gdbserver without building gdb (sounds a bit more complex)? > > Nope, `--disable-gdb --enable-gdbserver' is typical for a cross-debug > environment, where you want to configure and build cross-GDB with > `--host=foo --target=bar' and `gdbserver' with `--host=bar'. Sometimes > your build environment may not even be capable to build native GDB with > `--host=bar', or your target system to run it, and in any case building > GDB takes a lot of processing time compared to `gdbserver'. So it would > be a waste of resources if we forced people to do that. Well, that is a fair point. In which case i think we have a bug in our hands. > > I build `gdbserver' by itself routinely, although I only did the minimum > to convert from the old layout, that is rather than calling `configure' > from gdb/gdbserver/ I now call it from gdbserver/. So far it has worked, > although with the new arrangement it probably qualifies as a hack, and may > stop working sometime. > > Maciej >
On 2/17/20 10:58 AM, Luis Machado wrote: > Hi Tom, > > On 2/14/20 6:14 PM, Tom Tromey wrote: >>>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes: >> >>>>>>> "Sergio" == Sergio Durigan Junior <sergiodj@redhat.com> writes: >> Sergio> I'm attaching a patch that works OK for me here. WDYT? >> >> Tom> This one includes that: >> >> Tom> https://sourceware.org/ml/gdb-patches/2020-02/msg00426.html >> >> Tom> I see that Luis responded. I'll read that and see what's up. >> >> I'm going to check it in now. >> >> Tom >> > > I ran into the following this morning... > > make[2]: Entering directory > '/home/luis.machado/work/tcwg/build/binutils-gdb-master/gdbserver' > make[2]: *** No rule to make target '../gnulib/import/libgnu.a', needed > by 'gdbserver'. Stop. > > This was with a build using a configure line containing "--disable-gdb" > but no "--disable-gdbserver". > > Should --disable-gdb also imply --disable-gdbserver? Or should we be > able to build gdbserver without building gdb (sounds a bit more complex)? Meanwhile, thanks to Christian, i've confirmed that adding a similar block to configure.ac, like this one: # gdb depends on gnulib and gdbsupport, but as nothing else does, only # include them if gdb is built. if echo " ${configdirs} " | grep " gdb " > /dev/null 2>&1 ; then # The Makefile provides the ordering, so it's enough here to add to # the list. configdirs="${configdirs} gnulib gdbsupport" fi ... fixes the problem for gdbserver as well.
>>>>> "Luis" == Luis Machado <luis.machado@linaro.org> writes:
Luis> Should --disable-gdb also imply --disable-gdbserver? Or should we be
Luis> able to build gdbserver without building gdb (sounds a bit more
Luis> complex)?
We should, it was historically supported and preserving this ability is
one of the goals of the series.
Thanks for the report. I missed a spot in configure.ac and I will be
pushing a fix shortly.
Tom
On Monday, February 17, 2020 6:00 PM, Tom Tromey wrote: > >>>>> "Luis" == Luis Machado <luis.machado@linaro.org> writes: > > Luis> Should --disable-gdb also imply --disable-gdbserver? Or should we be > Luis> able to build gdbserver without building gdb (sounds a bit more > Luis> complex)? > > We should, it was historically supported and preserving this ability is > one of the goals of the series. > > Thanks for the report. I missed a spot in configure.ac and I will be > pushing a fix shortly. > > Tom It used to be possible to build gdbserver by directly using its configure. E.g.: path/to/gdbserver/configure, as shown here: https://sourceware.org/gdb/wiki/BuildingCrossGDBandGDBserver Is this not a use-case anymore? Thanks. -Baris Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
>>>>> ">" == Aktemur, Tankut Baris <tankut.baris.aktemur@intel.com> writes: >> It used to be possible to build gdbserver by directly using its configure. >> E.g.: path/to/gdbserver/configure, as shown here: >> https://sourceware.org/gdb/wiki/BuildingCrossGDBandGDBserver >> Is this not a use-case anymore? It is still possible to build just gdbserver, but the approach is different now. The documentation was updated as part of this switch. The new approach is to configure as usual, possibly disabling gdb as well, and then use "make all-gdbserver". I do it like: ../binutils-gdb/configure --disable-{binutils,gas,gold,gprof,ld,gdb} make all-gdbserver Plain "make" can also be used, but some unnecessary libraries will still be built -- that's why we recommend all-gdbserver. It might be good to also disable these libraries if no "deliverable" depends on them, but as that's a top-level change, it requires some more thought. Tom
diff --git a/gdb/testsuite/boards/gdbserver-base.exp b/gdb/testsuite/boards/gdbserver-base.exp index 4db834dd84..f27a2fdf91 100644 --- a/gdb/testsuite/boards/gdbserver-base.exp +++ b/gdb/testsuite/boards/gdbserver-base.exp @@ -22,7 +22,7 @@ process_multilib_options "" set_board_info compiler "[find_gcc]" # Test the copy of gdbserver in the build directory. -set_board_info gdb_server_prog "[pwd]/../gdbserver/gdbserver" +set_board_info gdb_server_prog "[pwd]/../../gdbserver/gdbserver" # gdbserver does not intercept target file operations and perform them # on the host.