public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch] Fix regression on prelinked executables
Date: Fri, 30 Jul 2010 15:45:00 -0000	[thread overview]
Message-ID: <20100730154442.GA25162@host1.dyn.jankratochvil.net> (raw)
In-Reply-To: <20100729163648.GA13267@adacore.com>

On Thu, 29 Jul 2010 18:36:48 +0200, Joel Brobecker wrote:
> > Curiously GDB already uses at
> > many places
> > 	baseaddr = ANOFFSET (objfile->section_offsets, SECT_OFF_TEXT (objfile));
> > instead of using offset for the appropriate section at that place and nobody
> > complains.
> 
> It's something I actually noticed almost 10 years ago, now, while
> working on Tru64, I think. But I never really found a situation that
> required me to work on that, so...

OK, I will one day try to turn section_offsets array into a single variable.


> >  	  if (!(strcmp (sect_name, ".gnu.liblist") == 0
> >  		|| strcmp (sect_name, ".gnu.conflict") == 0
> > -		|| strcmp (sect_name, ".dynbss") == 0
> > -		|| strcmp (sect_name, ".sdynbss") == 0))
> > +		|| (strcmp (sect_name, ".bss") == 0
> > +		    && i > 0
> > +		    && strcmp (addrs->other[i - 1].name, ".dynbss") == 0
> > +		    && addrs_to_abfd_addrs[i - 1] != NULL)
> > +		|| (strcmp (sect_name, ".sbss") == 0
> > +		    && i > 0
> > +		    && strcmp (addrs->other[i - 1].name, ".sdynbss") == 0
> > +		    && addrs_to_abfd_addrs[i - 1] != NULL)))
            warning (_("section %s not found in %s"), sect_name,
                     bfd_get_filename (abfd));
> 
> I had to think over this for a while, and I think that the two new checks
> are correct.  However, I'm still trying to figure out why it's correct
> to also remove the simple check for .dynbss. In other words, if .dynbss
> is missing from the separate debug object file, shouldn't we emit a
> warning?

The meaning is reversed.  It is !(a || b || c).  Which I find more readable
than (!a && !b && !c).  But I will have to change my mind as it seems to not
everyone may consider my chosen format as more readable.

The code above says do NOT warn if section is either .gnu.liblist or
.gnu.conflict or etc.

That is it was very irresponsible from me to put .dynbss and .sdynbss there
before.  I should have examined what they really mean, when they appear etc.
I have seen them as added by prelink so I thought we can ignore them.  I did
not consider they contain the right address for .bss/.sbss as the real
.bss/.sbss address is invalid (from the GDB point of view) that time already.

That is the change above reducing the enumerated list in fact increases the
probability we give a warning.

Another issue is that we no longer suppress the warning for .dynbss/.sdynbss
as before and it works.  It is due to the new addr_section_name function,
originally .dynbss/.sdynbss got to this point while now .dynbss/.sdynbss get
processed but .bss/.sbss gets to this point instead.  Making the code
	  if (!(strcmp (sect_name, ".gnu.liblist") == 0
		|| strcmp (sect_name, ".gnu.conflict") == 0
		|| strcmp (sect_name, ".bss") == 0
		|| strcmp (sect_name, ".sbss") == 0))
is probably too obviously incorrect so we have to restrict the .bss/.sbss
entries warning suppression to the ones which only come exactly after the
prelink-generated .dynbss/.sdynbss sections.

I already got the approval but delaying it to resolving this issue.

OK to check-in?


Thanks,
Jan

  parent reply	other threads:[~2010-07-30 15:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-15  9:55 Jan Kratochvil
2010-07-27 19:22 ` ping: " Jan Kratochvil
2010-07-29 16:37 ` Joel Brobecker
2010-07-29 20:14   ` Tom Tromey
2010-07-29 21:38     ` Joel Brobecker
2010-07-29 22:14       ` Tom Tromey
2010-07-30 15:45   ` Jan Kratochvil [this message]
2010-07-30 15:55     ` Joel Brobecker
2010-07-30 16:06       ` Jan Kratochvil
2010-10-05 20:56   ` [7.2.x-checkin] " 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=20100730154442.GA25162@host1.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).