Message ID | 8736bd3jt2.fsf@redhat.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 91699 invoked by alias); 14 Feb 2020 03:54:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 91689 invoked by uid 89); 14 Feb 2020 03:54:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=237A, 0287, 31F4, UD:sergiodj.net X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Feb 2020 03:54:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581652483; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HOh1MiqVeCHFl2TflqRWt5ieXiAkiZTBFVrnp3cbjVk=; b=ST4xpeOEwbjXedOWzct/sWntMEpg3lmgWu+tb49yL06EEnL8fkC5CEEmx6PyuR6l+iV1vL fHhs3mxmc0uzY19VTXjq6bf+ONdeqp75zjizfaZas0CWgbpnmtiZao33QAbBknPtXx108K m5QjyOMxv1V9+ZhwjS+a3EdpOFovUKg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-240-eTzMF27gNvSCwK3Q1WSFCQ-1; Thu, 13 Feb 2020 22:54:35 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9A04E1005512; Fri, 14 Feb 2020 03:54:34 +0000 (UTC) Received: from localhost (unused-10-15-17-196.yyz.redhat.com [10.15.17.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9BA1A26E7C; Fri, 14 Feb 2020 03:54:33 +0000 (UTC) From: Sergio Durigan Junior <sergiodj@redhat.com> To: Tom Tromey <tom@tromey.com> Cc: Tom de Vries <tdevries@suse.de>, Pedro Alves <palves@redhat.com>, gdb-patches@sourceware.org Subject: Re: [PATCH] Move gdbserver to top level References: <87d0bf45up.fsf@tromey.com> <7ceebbb7-b2f7-3d4a-1d8a-f31310badbe8@redhat.com> <874kwk8nz9.fsf@tromey.com> <171a3144-af37-1c29-a2a4-c4cd7eaa14c0@redhat.com> <87r1zm6x8s.fsf@tromey.com> <01b4b5ca-a802-54b5-3135-428b7c9faa84@redhat.com> <87o8uo4mj0.fsf@tromey.com> <87blqfn0d6.fsf@tromey.com> <0b6b4f24-f5c8-b236-c249-737e70395667@suse.de> <4d5a1276-91aa-7197-5f90-854767987f73@suse.de> <c58efeda-0be9-ef0d-86f1-cff89393a947@suse.de> <87imkeh1za.fsf@redhat.com> <87eev0bp4s.fsf@tromey.com> Date: Thu, 13 Feb 2020 22:54:33 -0500 In-Reply-To: <87eev0bp4s.fsf@tromey.com> (Tom Tromey's message of "Tue, 11 Feb 2020 17:55:31 -0700") Message-ID: <8736bd3jt2.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes |
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
>>>>> "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.