From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18893 invoked by alias); 17 Mar 2014 08:49:34 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 18883 invoked by uid 89); 17 Mar 2014 08:49:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: moutng.kundenserver.de Received: from moutng.kundenserver.de (HELO moutng.kundenserver.de) (212.227.126.130) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 17 Mar 2014 08:49:31 +0000 Received: from smtp.ascolab.com ([213.95.4.182]) by mrelayeu.kundenserver.de (node=mreue006) with ESMTP (Nemesis) id 0MPvIk-1WTIiY0SuI-0051v8; Mon, 17 Mar 2014 09:49:28 +0100 Received: from localhost (localhost [127.0.0.1]) by smtp.ascolab.com (Postfix) with ESMTP id 2644EE0B65 for ; Mon, 17 Mar 2014 09:49:27 +0100 (CET) Received: from smtp.ascolab.com ([127.0.0.1]) by localhost (smtp.ascolab.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fcP1C6tObNKo for ; Mon, 17 Mar 2014 09:49:24 +0100 (CET) Received: from ws-gergap.localnet (unknown [213.95.4.186]) by smtp.ascolab.com (Postfix) with ESMTPA id 841F0E0B60 for ; Mon, 17 Mar 2014 09:49:24 +0100 (CET) From: Gerhard Gappmeier To: gdb-patches Subject: Re: New feature "source-id" Date: Mon, 17 Mar 2014 08:49:00 -0000 Message-ID: <10414444.6eOdp1cvY6@ws-gergap> User-Agent: KMail/4.11.5 (Linux/3.11.6-gentoo; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <7365721.BnaR1nHazz@lt-gergap> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3966851.Z61WAgRCZu"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00357.txt.bz2 --nextPart3966851.Z61WAgRCZu Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Content-length: 2530 On Sunday, March 16, 2014 09:22:17 AM Doug Evans wrote: > On Sat, Mar 15, 2014 at 7:34 PM, Doug Evans wrote: > > Note that one concern I have is that it may be that some sites will > > want to have some of gdb's state updated when source files are > > automagically fetched. E.g., maybe one would want to update the > > source search path. Maybe not, but at any rate I don't want this > > feature to preclude doing things like that, and one can't do that if > > the feature works by running an external program via popen. >=20 > As a data point, > another way to go is to just have a convention for some global > variables in the binary. > With the debug info gdb can access them, and they could contain > everything that would be in the .note section. >=20 > I don't have a preference, per se. > I just mention it as a possibility, and if one went that route then > doing this in Python/Guile would be while perhaps not required > certainly easy. That's an interesting idea. When I first read this comment I thought it wou= ld=20 require code changes what would not be what I want. But indeed we can simpl= y=20 generate an own 'vcsinfo.c' file which gets compiled and linked with the=20 executable. I think its even simpler to add a new C file than requiring GNU= as=20 to generate a new section. example vcsinfo.c: /* this file was genarated, bla bla, don't modifiy */ static const char vcs_type[] =3D "git"; static const char vcs_url[] =3D "git@github.com:gergap/source-id.git" static const char vcs_version[] =3D "c2ec66e6a36451ba47422d186fd97311989ef2= 78" I just have to investigate how to access this debug info in GDB, as I'm sti= ll=20 new to this code. I hope it is as easy as it was to access the ELF info ;-) Do you see any problem with declaring the variables static? Doing so we can= =20 avoid name clashes. How can we avoid that these variables get dropped by the linker if they are= =20 not referenced by any code? declaring them volatile? --=20 mit freundlichen Gr=C3=BC=C3=9Fen / best regards Gerhard Gappmeier ascolab GmbH - automation systems communication laboratory Tel.: +49 9131 691 123 Fax: +49 9131 691 128 Web: http://www.ascolab.com GPG-KeyId: 5AAC50C4 GPG-Fingerprint: 967A 15F1 2788 164D CCA3 6C46 07CD 6F82 5AAC 50C4 -- ascolab GmbH Gesch=C3=A4ftsf=C3=BChrer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrau= =C3=9F Sitz der Gesellschaft: Am Weichselgarten 7 =E2=80=A2 91058 Erlangen =E2=80= =A2 Germany Registernummer: HRB 9360 Registergericht: Amtsgericht F=C3=BCrth= --nextPart3966851.Z61WAgRCZu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit Content-length: 198 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlMmtxQACgkQB81vglqsUMRgwgCdHSsdYJXBEwOSMCEQPmUffmPV FVEAmwQGNFsIH67y2FmgZvPvBv/FyWhU =Ozt6 -----END PGP SIGNATURE----- --nextPart3966851.Z61WAgRCZu--