From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89081 invoked by alias); 30 May 2019 07:14:49 -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 89060 invoked by uid 89); 30 May 2019 07:14:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.22) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 May 2019 07:14:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1559200484; bh=Qh84VNxE4REw0Q6Ig+FgoyC2j3pEmLaW1GcLyu9x0ks=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=EF1fJhavOzmvo4ExAy0M0wjqgGVKwbChGd/uPvgYTX8aLqAKt7GM5V6SQC64KzIZN 2+6ucN+ADFsjVkD+iZThBPHzoym5vn25S/DiO+KoXZHYqXnLNLuOk1zFgt+tQ+IcFV LYAYzPmF85tibXZ7pPSt8iFhZjFKzj88OTBsgkBo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.0.241] ([89.71.135.231]) by mail.gmx.com (mrgmx102 [212.227.17.174]) with ESMTPSA (Nemesis) id 0LlXnX-1guzMA2u2x-00bOL6; Thu, 30 May 2019 09:09:09 +0200 Subject: Re: [PATCH] Fix a number of build problems found on Solaris and NetBSD (was Re: Oh dear. I regret to inform you that commit 0e65dfbaf3a0299e4837216a103c28625d4b4f1d might be unfortunate) To: Nick Alcock Cc: Rainer Orth , Simon Marchi , Nick Clifton , gdb-patches@sourceware.org, binutils@sourceware.org References: <0e65dfbaf3a0299e4837216a103c28625d4b4f1d-master-breakage@gdb-build> <87r28h5sz0.fsf@esperi.org.uk> <87lfyp43w8.fsf_-_@esperi.org.uk> <07f014db-d2ff-f2ec-9217-ca672d07cafb@gmx.com> <87d0k13pf4.fsf@esperi.org.uk> From: Kamil Rytarowski Openpgp: preference=signencrypt Message-ID: <60d87039-3084-6d56-3de6-8a29a3d8591f@gmx.com> Date: Thu, 30 May 2019 07:14:00 -0000 User-Agent: Mozilla/5.0 (X11; NetBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <87d0k13pf4.fsf@esperi.org.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hH0WkJqc5xeiIS71eaKqjJq7q5t1QzimV" X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00677.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hH0WkJqc5xeiIS71eaKqjJq7q5t1QzimV Content-Type: multipart/mixed; boundary="NoLPP3wT0uz1PTC83qJNbuOcfufVYvjwx"; protected-headers="v1" From: Kamil Rytarowski To: Nick Alcock Cc: Rainer Orth , Simon Marchi , Nick Clifton , gdb-patches@sourceware.org, binutils@sourceware.org Message-ID: <60d87039-3084-6d56-3de6-8a29a3d8591f@gmx.com> Subject: Re: [PATCH] Fix a number of build problems found on Solaris and NetBSD (was Re: Oh dear. I regret to inform you that commit 0e65dfbaf3a0299e4837216a103c28625d4b4f1d might be unfortunate) References: <0e65dfbaf3a0299e4837216a103c28625d4b4f1d-master-breakage@gdb-build> <87r28h5sz0.fsf@esperi.org.uk> <87lfyp43w8.fsf_-_@esperi.org.uk> <07f014db-d2ff-f2ec-9217-ca672d07cafb@gmx.com> <87d0k13pf4.fsf@esperi.org.uk> In-Reply-To: <87d0k13pf4.fsf@esperi.org.uk> --NoLPP3wT0uz1PTC83qJNbuOcfufVYvjwx Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 3274 On 29.05.2019 23:45, Nick Alcock wrote: > [Do we want to Cc: the gdb buildbot on this? I presume not: dropped from = Cc:.] >=20 > On 29 May 2019, Kamil Rytarowski uttered the following: >=20 >> On 29.05.2019 18:33, Nick Alcock wrote: >>> On 29 May 2019, Rainer Orth stated: >>> >>>> Nix writes: >>>>> I stripped almost all of these out, but it looks like one single one >>>>> survived. It is gone now. >>>> >>>> Thanks. >>> >>> If you'd like to try the entirely unreviewed patch I'm trying out (works >>> for me on x86_64-pc-linux-gnu, i686-pc-linux-gnu, mingw, Solaris), here >>> it is: >>> >> >> I wanted to check this patch on NetBSD but it does not apply for me for >> some reason (I've used the original source of the mail as a patch). >=20 > It is based on commit 9698cf9b1c485edbbeabc9f65bfd0fdef92e3854, for what > it's worth. >=20 >> Is it safe to use this off64_t define? Won't there be issues with off_t >> that is 64-bit on NetBSD and 32-bit on some other OSs? >=20 > Unlikely. This definition is only used for platforms that don't have an > off64_t already, and is only used for the size of ctf_sect_t.offset. > Platforms on which off_t is 32-bit and without a 64-bit off_t will > presumably have a 32-bit limit on the size of their binaries, too, so it > is not a limitation to restrict section offsets to 32-bit. >=20 > (However... we don't *use* the offset field in any case. If we don't > mind losing things from the ctf_sect_t, we *could* just entirely drop > that field, and the cts_type and cts_flags as well. None are used since > the old ELF reading code was dropped.) >=20 > ... yeah, I'll rejig things that way. It's easier. There's no point > going through portability trouble for a field we're not even *using*. >=20 > ... found an outright bug in the process: we were sometimes failing to > set the section size when opening associated string and symbol tables. > Fixed at the same time (it was right next to a line we were removing). >=20 >> NetBSD uses the >> libctf stack from FreeBSD/SunOS for DTrace, will that be compatible with >> this GDB code? >=20 > As previously noted, the formats are incompatible (and will get more so: > there are a number of huge size reductions that can be made, all of > which are of course format changes). >=20 > I can, however, add backward-compatibility code to dynamically upgrade > the old CTF format to the new one at open time, if this seems to be > useful. (It's not too different from our format v1). I'm just skeptical > that it *is* useful, since CTF info is mostly found in OS kernels so > far, and is in a differently-named section. >=20 We build every binary on NetBSD with CTF and it is used by DTrace. FreeBSD additionally ported mdb from SunOS. However there is still DWARF available always so it's not a big problem, at least in the default environment. > ... new patch (though I'm not sure you'll be able to apply it any more > than you could apply the last one). Observe lack of dependence on > off64_t :) >=20 > Still builds on Solaris. :) >=20 After an attempt to apply the patch and manual fixups of rejected chunks (patch seems to be malformed in the inlined form), gdb builds again on NetBSD/amd64 8.99.41. --NoLPP3wT0uz1PTC83qJNbuOcfufVYvjwx-- --hH0WkJqc5xeiIS71eaKqjJq7q5t1QzimV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEELaxVpweEzw+lMDwuS7MI6bAudmwFAlzvgcYACgkQS7MI6bAu dmw/aBAAwSDPm/n9eUEs45eoz/0Jcz46M46SuWN6tDu6DCT5YLicIFFYOhpHGYKS dkr5NnFwnVQbFfMr2pBZbRiZZCOXzLfjDBv7i8TTj21Wum9zizjV5/CGDPrue0iM wRnMqqUvSBBvTrIKwSP1Aru5UUk98yzptjcRWbRf5YgPXBQ/Lbecai1y7zXa0wjW 2jB7efpqslaKylr/gKr+5B6qKBM6X8FDukQgnQXYclo7HsU+2yj/TE0B0HYNQGbq VrfiyLFS50xRtQCmr6wAL8mtPskykqiqR5KELAcjxryiVArIhr2OipqH1ihcr8mr d/CiwoqRgiL4Ay8MgtlVtnryMkgQ1USqoMG6BSc/i9k6QkT5EMjE8sA9kOTGjhWs CXJADRSuoDtV6Dc2YChBEljOG4mn6mxyvMQvpUHLb24auHVnZQO4GF1Ujl9bQ/wC pOQJGMo6fXmoj+LqfzzacuIBw7TLhm29/dFFjnNGZA1MN7Sn5FJmY4IpEstotW1c 2o6H412GSUyNdYBkt8zAA8QPTuXI0QWzR1Y85PUUp5mX2LhBqPgvCqrt70i1CkZX I7GcdhGErraQh6+a/Ij7Ev6n4WU2wOTrIXXTvoGW3ED4INP5HrMN1SwC3FF7ZN7j 7lqcLxRcEW/A4j4heB5Avg6B8wyOVvL0QQc3ZfBQBUoVly+b6zg= =3hEE -----END PGP SIGNATURE----- --hH0WkJqc5xeiIS71eaKqjJq7q5t1QzimV--