Message ID | 20150107173634.GA13295@host2.jankratochvil.net |
---|---|
State | New, archived |
Headers |
Received: (qmail 8124 invoked by alias); 7 Jan 2015 17:36:41 -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 8040 invoked by uid 89); 7 Jan 2015 17:36:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 07 Jan 2015 17:36:39 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t07HacqI023795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <gdb-patches@sourceware.org>; Wed, 7 Jan 2015 12:36:38 -0500 Received: from host2.jankratochvil.net (ovpn-116-60.ams2.redhat.com [10.36.116.60]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t07HaY4Y007683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <gdb-patches@sourceware.org>; Wed, 7 Jan 2015 12:36:37 -0500 Date: Wed, 7 Jan 2015 18:36:34 +0100 From: Jan Kratochvil <jan.kratochvil@redhat.com> To: gdb-patches@sourceware.org Subject: [patch] Fix jit-reader.h for multilib Message-ID: <20150107173634.GA13295@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes |
Commit Message
Jan Kratochvil
Jan. 7, 2015, 5:36 p.m. UTC
Hi, I got reported jit-reader.h is not multi-lib safe: multi-lib safety means that files with the same pathname (which is /usr/include, contrary to /usr/lib vs. /usr/lib64 for example). The patch will make it on x86_64 also 'unsigned long long'. OK for check-in? Thanks, Jan gdb/ChangeLog 2015-01-07 Jan Kratochvil <jan.kratochvil@redhat.com> * configure: Regenerate. * configure.ac (TARGET_PTR): Try "unsigned long long" first. diff --git a/gdb/configure.ac b/gdb/configure.ac index ec776d7..c02ace9 100644 --- a/gdb/configure.ac +++ b/gdb/configure.ac @@ -648,10 +648,12 @@ AC_CHECK_SIZEOF(unsigned long long) AC_CHECK_SIZEOF(unsigned long) AC_CHECK_SIZEOF(unsigned __int128) -if test "x${ac_cv_sizeof_unsigned_long}" = "x8"; then - TARGET_PTR="unsigned long" -elif test "x${ac_cv_sizeof_unsigned_long_long}" = "x8"; then +# Try to keep TARGET_PTR the same across archs so that jit-reader.h file +# content is the same for multilib distributions. +if test "x${ac_cv_sizeof_unsigned_long_long}" = "x8"; then TARGET_PTR="unsigned long long" +elif test "x${ac_cv_sizeof_unsigned_long}" = "x8"; then + TARGET_PTR="unsigned long" elif test "x${ac_cv_sizeof_unsigned___int128}" = "x16"; then TARGET_PTR="unsigned __int128" else
Comments
Jan Kratochvil <jan.kratochvil@redhat.com> writes: > I got reported jit-reader.h is not multi-lib safe: > > --- /usr/include/gdb/jit-reader.h on x86_64 2015-01-07 11:54:27.705802129 -0500 > +++ /usr/include/gdb/jit-reader.h on i686 2015-01-07 11:54:46.853774165 -0500 > @@ -56,7 +56,7 @@ extern "C" { > > /* Represents an address on the target system. */ > > -typedef unsigned long GDB_CORE_ADDR; > +typedef unsigned long long GDB_CORE_ADDR; > > /* Return status codes. */ > > > multi-lib safety means that files with the same pathname (which is > /usr/include, contrary to /usr/lib vs. /usr/lib64 for example). Hi Jan, I am sorry I can't understand what you mean here, can you elaborate? Do you mean sizeof (GDB_CORE_ADDR) should be the same on different multi-lib (i686 vs x86_64)?
On Sun, 11 Jan 2015 13:02:55 +0100, Yao Qi wrote: > Jan Kratochvil <jan.kratochvil@redhat.com> writes: > > > I got reported jit-reader.h is not multi-lib safe: > > > > --- /usr/include/gdb/jit-reader.h on x86_64 2015-01-07 11:54:27.705802129 -0500 > > +++ /usr/include/gdb/jit-reader.h on i686 2015-01-07 11:54:46.853774165 -0500 > > @@ -56,7 +56,7 @@ extern "C" { > > > > /* Represents an address on the target system. */ > > > > -typedef unsigned long GDB_CORE_ADDR; > > +typedef unsigned long long GDB_CORE_ADDR; > > > > /* Return status codes. */ > > > > > > multi-lib safety means that files with the same pathname (which is > > /usr/include, contrary to /usr/lib vs. /usr/lib64 for example). > > I am sorry I can't understand what you mean here, can you elaborate? Sorry I see I haven't finished the sentence, it should have been: # multi-lib safety means that files with the same pathname (which is # /usr/include, contrary to /usr/lib vs. /usr/lib64 for example) # contain exactly the same content. See also: https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#File_conflicts When we discuss it personally I do not think multilib should be applied to the GDB package as there is nothing like /usr/lib{,64}/libgdb.so. There is only /usr/bin/gdb and that has always just one arch on one system. So installing gdb.i686 and gdb.x86_64 simultaneously does not have any benefits / makes sense. But despites this I need it for Red Hat packaging so I am fine to also keep it just as a downstream patch. OTOH I guess other OS packagers may also face it so it may be easier for everyone to do it upstream. > Do you mean sizeof (GDB_CORE_ADDR) should be the same on different > multi-lib (i686 vs x86_64)? For multilib it does not matter what is the runtime GDB_CORE_ADDR type but the text defining it (in /usr/include/gdb/jit-reader.h) has to be the same for archs sharing multilib. IIUC GDB requires for GDB_CORE_ADDR: * sizeof (GDB_CORE_ADDR) >= sizeof (CORE_ADDR) * sizeof (GDB_CORE_ADDR) is preferrably the smallest available size Jan
Jan Kratochvil <jan.kratochvil@redhat.com> writes: > # multi-lib safety means that files with the same pathname (which is > # /usr/include, contrary to /usr/lib vs. /usr/lib64 for example) > # contain exactly the same content. > Thanks, that is clear to me now. > See also: > https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks#File_conflicts > > > When we discuss it personally I do not think multilib should be applied to the > GDB package as there is nothing like /usr/lib{,64}/libgdb.so. There is only > /usr/bin/gdb and that has always just one arch on one system. So installing > gdb.i686 and gdb.x86_64 simultaneously does not have any benefits / makes > sense. But despites this I need it for Red Hat packaging so I am fine to also > keep it just as a downstream patch. OTOH I guess other OS packagers may also > face it so it may be easier for everyone to do it upstream. Is multi-lib safety a Fedora/Red Hat specific packaging rule? or do other distributions need this too? If answer is yes, I don't object to your patch as it adjusts the order of looking for desired types.
On Mon, 12 Jan 2015 03:33:37 +0100, Yao Qi wrote: > Jan Kratochvil <jan.kratochvil@redhat.com> writes: > > When we discuss it personally I do not think multilib should be applied to the > > GDB package as there is nothing like /usr/lib{,64}/libgdb.so. There is only > > /usr/bin/gdb and that has always just one arch on one system. So installing > > gdb.i686 and gdb.x86_64 simultaneously does not have any benefits / makes > > sense. But despites this I need it for Red Hat packaging so I am fine to also > > keep it just as a downstream patch. OTOH I guess other OS packagers may also > > face it so it may be easier for everyone to do it upstream. > > Is multi-lib safety a Fedora/Red Hat specific packaging rule? or do > other distributions need this too? I do not know how other distributions do that. Debian 'gdb' does not seem to ship jit-reader.h at all if I read Debian package listing correctly. For other libraries Debian ships the file like Fedora does: https://packages.debian.org/sid/amd64/libgpm-dev/filelist /usr/include/gpm.h /usr/lib/x86_64-linux-gnu/libgpm.so https://packages.debian.org/sid/i386/libgpm-dev/filelist /usr/include/gpm.h /usr/lib/i386-linux-gnu/libgpm.so What would happen if /usr/include/gpm.h content differs between amd64 and i386 build? Fedora would refuse to install the second package due to conflicting file content (sure unless forced to do so). As I said this patch may not affect much/any other distros because * at least Debian does not ship jit-reader.h at all * other distros may not consider GDB as a multilib package Jan
> As I said this patch may not affect much/any other distros because > * at least Debian does not ship jit-reader.h at all > * other distros may not consider GDB as a multilib package I don't think the problem would be specific to Fedora - it is possible that other distros might benefit from the fix as well. The only thing that gave me pause was the relatively strange fix, and the fact that I didn't really understand the issue, and therefore didn't understand the fix. I don't know much about jit-reader.h, and the impact of the fix, but I have a feeling that it would beneficial to others and therefore should be considered for inclusion.
--- /usr/include/gdb/jit-reader.h on x86_64 2015-01-07 11:54:27.705802129 -0500 +++ /usr/include/gdb/jit-reader.h on i686 2015-01-07 11:54:46.853774165 -0500 @@ -56,7 +56,7 @@ extern "C" { /* Represents an address on the target system. */ -typedef unsigned long GDB_CORE_ADDR; +typedef unsigned long long GDB_CORE_ADDR; /* Return status codes. */