This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4

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:
> >> >>
> >> >>
> >> >
> >> > Thanks, I hadn't seen that before. Alan Modra makes some good points in
> >> > that thread why it is not a good change:
> >> >
> >> > 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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]