From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] Fix false warning: section .gnu.liblist not found in ... [rediffed]
Date: Mon, 08 Mar 2010 07:57:00 -0000 [thread overview]
Message-ID: <20100308075631.GA8106@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <20100308072317.GE3081@adacore.com>
On Mon, 08 Mar 2010 08:23:17 +0100, Joel Brobecker wrote:
> > 2010-03-01 Jan Kratochvil <jan.kratochvil@redhat.com>
> >
> > * symfile.c (addr_info_make_relative): New variable sect_name, use it.
> > Do not warn on ".gnu.liblist" and ".gnu.conflict".
>
> This looks reasonable. We can go with that at least for now,
> but I am wondering whether we might want to consider using a complaint
> instead if more sections like these keep popping up.
I have checked prelink sources and IIUC there are no other sections than
".gnu.liblist" and ".gnu.conflict" with this behavior/problem. I do not agree
with this one sentence but I believe it is offtopic for this patch/thread.
> I have a small request:
>
> > + /* These two sections are intentionally loaded into memory from
> > + the DYNAMIC segment and so they have both SEC_ALLOC and SEC_LOAD
> > + set in the main executable (not in the library files). They
> > + are not present in the separate debug info file, though. */
> > +
> > + if (!(strcmp (sect_name, ".gnu.liblist") == 0
> > + || strcmp (sect_name, ".gnu.conflict") == 0))
> > + warning (_("section %s not found in %s"), sect_name,
> > + bfd_get_filename (abfd));
> > +
>
> I was a little confused at first by the comment, because it immediately
> mentioned "these two sections" without giving an idea of what these
> sections were. May I suggest maybe something more detailed like so?
>
> /* This section does not exist in ABFD, which is normally
> unexpected and we want to issue a warning.
>
> However, the ELF prelinker does create a couple of sections
> (".gnu.liblist" and ".gnu.conflict") which are marked as
> loadable (they are loaded in memory from the DYNAMIC segment)
> and yet are not present in separate debug info files. This
> is fine, and should not cause a warning. */
OK, thanks.
Just the main executable vs. shared library files difference was omitted there.
This difference was IIRC the main cost while investigating this problem
therefore I would like to keep the note there:
/* This section does not exist in ABFD, which is normally
unexpected and we want to issue a warning.
However, the ELF prelinker does create a couple of sections
(".gnu.liblist" and ".gnu.conflict") which are marked in the main
executable as loadable (they are loaded in memory from the
DYNAMIC segment) and yet are not present in separate debug info
files. This is fine, and should not cause a warning. Shared
libraries contain just the section ".gnu.liblist" but it is not
marked as loadable there. */
As the comment is already being discusses is approved even this variant?
Thanks for the review,
Jan
next prev parent reply other threads:[~2010-03-08 7:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-13 22:49 [patch] Fix false warning: section .gnu.liblist not found in Jan Kratochvil
2010-02-28 23:14 ` [patch] Fix false warning: section .gnu.liblist not found in ... [rediffed] Jan Kratochvil
2010-03-08 7:23 ` Joel Brobecker
2010-03-08 7:57 ` Jan Kratochvil [this message]
2010-03-08 8:17 ` Joel Brobecker
2010-03-08 8:37 ` Jan Kratochvil
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=20100308075631.GA8106@host0.dyn.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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