This is the mail archive of the
mailing list for the GCC project.
Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
- From: Mark Wielaard <mjw at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>, GDB <gdb-patches at sourceware dot org>
- Date: Fri, 20 Feb 2015 09:01:39 +0100
- Subject: Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
- Authentication-results: sourceware.org; auth=none
- References: <20150218165457 dot GU544 at vapier> <CAMe9rOqVim3=-RCuWE6GnMKoQ1v9WKaDqfaS2k8MpDz7rA_y3g at mail dot gmail dot com> <20150218194443 dot GW544 at vapier> <CAMe9rOqB=zd21_q_C3OGVveza8-y44L2_VntsBZ=C=iBQaaDEA at mail dot gmail dot com> <1424291541 dot 23458 dot 28 dot camel at bordewijk dot wildebeest dot org> <CAMe9rOow3D--tayrR6y_qxoZqXZAZh4g0f9qo8Jd+hYdORRMJQ at mail dot gmail dot com> <1424295643 dot 23458 dot 30 dot camel at bordewijk dot wildebeest dot org> <CAMe9rOqwOa-kzOhaH_D84eGgYE0wV7k-J4jsxXUmHak4On_=aQ at mail dot gmail dot com> <20150219071735 dot GA2484 at blokker dot redhat dot com> <CAMe9rOozMP_cW447N0eTpaME02SJ4KLm9QOq1MRa6U0tZ7sVng at mail dot gmail dot com>
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 <email@example.com> 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:
> > .zdebug sections (and/or relocations against them) in ET_REL files
> > like elfutils, systemtap, debugedit, dwz, etc.
> I opened a bug against elfutils:
> 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.