Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Wielaard <mjw@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Joel Brobecker <brobecker@adacore.com>,
	       GCC Patches <gcc-patches@gcc.gnu.org>,
	       Binutils <binutils@sourceware.org>,
	GDB <gdb-patches@sourceware.org>
Subject: Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4
Date: Fri, 20 Feb 2015 08:01:00 -0000	[thread overview]
Message-ID: <20150220080139.GB2484@blokker.redhat.com> (raw)
In-Reply-To: <CAMe9rOozMP_cW447N0eTpaME02SJ4KLm9QOq1MRa6U0tZ7sVng@mail.gmail.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 <mjw@redhat.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:
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


  reply	other threads:[~2015-02-20  8:01 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-07 14:46 Joel Brobecker
2015-01-07 16:01 ` Tristan Gingold
2015-01-07 17:02   ` Joel Brobecker
2015-02-19  7:55   ` Thomas Schwinge
2015-02-19  7:58     ` Thomas Schwinge
2015-01-21  7:49 ` ping: " Joel Brobecker
2015-01-21  8:22   ` Tristan Gingold
2015-01-21  8:33     ` Joel Brobecker
2015-02-04  3:57 ` ping^2: " Joel Brobecker
2015-02-18 12:09 ` ping #3: " Joel Brobecker
2015-02-18 12:56   ` H.J. Lu
2015-02-18 16:55     ` Mike Frysinger
2015-02-18 16:58       ` H.J. Lu
2015-02-18 19:44         ` Mike Frysinger
2015-02-18 19:52           ` H.J. Lu
2015-02-18 20:32             ` Mark Wielaard
2015-02-18 20:42               ` Jakub Jelinek
2015-02-18 20:53               ` H.J. Lu
2015-02-18 21:54                 ` Mark Wielaard
2015-02-18 22:03                   ` H.J. Lu
2015-02-18 22:21                     ` Mike Frysinger
2015-02-18 22:24                       ` H.J. Lu
2015-02-18 23:10                         ` Mike Frysinger
2015-02-19  7:17                     ` Mark Wielaard
2015-02-19 13:52                       ` H.J. Lu
2015-02-20  8:01                         ` Mark Wielaard [this message]
2015-02-18 17:00       ` Joel Sherrill
2015-02-19  2:42     ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150220080139.GB2484@blokker.redhat.com \
    --to=mjw@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=brobecker@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=hjl.tools@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox