From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31930 invoked by alias); 20 Feb 2015 08:01:52 -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 31876 invoked by uid 89); 20 Feb 2015 08:01:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=unavailable version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients 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; Fri, 20 Feb 2015 08:01:49 +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 t1K81fTv000984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 20 Feb 2015 03:01:42 -0500 Received: from blokker.wildebeest.org (ovpn-116-21.ams2.redhat.com [10.36.116.21]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1K81d4T006480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 20 Feb 2015 03:01:41 -0500 Received: by blokker.wildebeest.org (Postfix, from userid 1000) id 8861320461; Fri, 20 Feb 2015 09:01:39 +0100 (CET) Date: Fri, 20 Feb 2015 08:01:00 -0000 From: Mark Wielaard To: "H.J. Lu" Cc: Joel Brobecker , GCC Patches , Binutils , GDB Subject: Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4 Message-ID: <20150220080139.GB2484@blokker.redhat.com> References: <20150218165457.GU544@vapier> <20150218194443.GW544@vapier> <1424291541.23458.28.camel@bordewijk.wildebeest.org> <1424295643.23458.30.camel@bordewijk.wildebeest.org> <20150219071735.GA2484@blokker.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-02/txt/msg00588.txt.bz2 On Thu, Feb 19, 2015 at 05:52:26AM -0800, H.J. Lu wrote: > On Wed, Feb 18, 2015 at 11:17 PM, Mark Wielaard wrote: > >> >> Now it becomes a monthly topic: > >> >> > >> >> https://sourceware.org/ml/binutils/2015-01/msg00089.html > >> > > >> > Thanks, I hadn't seen that before. Alan Modra makes some good points in > >> > that thread why it is not a good change: > >> > https://sourceware.org/ml/binutils/2015-01/msg00135.html > >> > Do people agree with that? And/Or can the change be reverted for now > >> > till there is agreement it is a desirable default? > >> > > >> > >> It may not be a good idea for all targets. If you find an issue > >> on Linux/x86, please file a bug binutils report. > > > > The issue is that this is not something that is target architecture > > specific. As others have pointed out this isn't something that is > > target architecture-dependent. So please first get agreement on whether > > or not to default for the OS (or for all ELF targets or the GNU targets). > > As I said before, I don't think it will happen any time soon. You will have to convince a global maintainer or the other architecture maintainers this is a good default. > > Otherwise distros will have to revert on a target by target basis to get > > something consistent. Secondly the bug is not directly in binutils (but > > there might be an issue between versions compiled with/without zlib > > support). If .zdebug sections are left in on disk ET_REL files, like > > kernel modules, there is a problem for programs that don't deal with > > Please stop spreading your FUD about kernel modules. If you find a problem > with kernel modules, please open a binutils bug report. I think you misunderstand. Although a quick search indicates there are issues in binutils dealing with .zdebug sections (e.g. #11819 and #15989) I wasn't talking about binutils. Other utilities that might have problems with ET_REL files containing .zdebug sections. I know that is the case for kernel modules. But as you point out below there are other issues/bugs in tools dealing with .zdebug ET_REL files too. The point was that Alan mentions a couple of issues that I didn't see you address yet. You might run into difficulty with other tools or older binutils that deal with relocatable object files that are important to consider before making this the default. You might just want to reply to his message if you feel I am misrepresenting things: https://sourceware.org/ml/binutils/2015-01/msg00135.html > > .zdebug sections (and/or relocations against them) in ET_REL files > > like elfutils, systemtap, debugedit, dwz, etc. > > I opened a bug against elfutils: > > https://bugzilla.redhat.com/show_bug.cgi?id=807053 > > It shouldn't be be too hard to fix. Thanks. Patches welcome of course. It is slightly tricky because in elfutils the code that deals with .[z]debug DWARF data (libdw) is separate from the code that deals with loading of ELF data and applying relocations (libdwfl). The relocations are applied early by code that doesn't know about .zdebug compression and so relies on the section headers to know data offsets and sizes. The bug report has some hints how to maybe handle this. Cheers, Mark