diff mbox

Move gdbserver to top level

Message ID 8736bd3jt2.fsf@redhat.com
State New, archived
Headers

Commit Message

Sergio Durigan Junior Feb. 14, 2020, 3:54 a.m. UTC 
  On Tuesday, February 11 2020, Tom Tromey wrote:

>>>>>> "Sergio" == Sergio Durigan Junior <sergiodj@redhat.com> writes:
>
> Sergio> I wonder why...  We build GDB from scratch on every build.  Is there
> Sergio> anything special that needs to be done to run the gdbserver tests now?
>
> No, I just neglected to update the gdb test suite to find gdbserver in
> the new spot.
>
> I will send a patch momentarily.

I'm attaching a patch that works OK for me here.  WDYT?

Comments

Tom Tromey Feb. 14, 2020, 6:37 p.m. UTC | #1 
>>>>> "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 Tromey Feb. 14, 2020, 9:14 p.m. UTC | #2 
>>>>> "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
Luis Machado Feb. 17, 2020, 1:58 p.m. UTC | #3 
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)?
Maciej W. Rozycki Feb. 17, 2020, 2:21 p.m. UTC | #4 
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
Luis Machado Feb. 17, 2020, 2:29 p.m. UTC | #5 
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
>
Luis Machado Feb. 17, 2020, 4:57 p.m. UTC | #6 
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.
Tom Tromey Feb. 17, 2020, 4:59 p.m. UTC | #7 
>>>>> "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
Tankut Baris Aktemur Feb. 17, 2020, 5:27 p.m. UTC | #8 
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
Tom Tromey Feb. 17, 2020, 6:46 p.m. UTC | #9 
>>>>> ">" == 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 mbox

Patch

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.