Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Tristan Gingold <gingold@ACT-Europe.FR>
Cc: gdb-patches@sourceware.org, kevinb@redhat.com
Subject: Re: [RFA] Fix has_section_at_zero for separate debug files
Date: Mon, 11 Jan 2010 21:29:00 -0000	[thread overview]
Message-ID: <m3tyusnxf3.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20100107130918.GA11037@chinon.act-europe.fr> (Tristan Gingold's 	message of "Thu, 7 Jan 2010 14:09:18 +0100")

>>>>> "Tristan" == Tristan Gingold <gingold@ACT-Europe.FR> writes:

Tristan> this patch reconsiders the approach taken in
Tristan> http://sourceware.org/ml/gdb-patches/2009-06/msg00116.html

Tristan> The new problem is that has_section_at_zero is now wrongly
Tristan> cleared.  This happens when the separate debug file is a
Tristan> relocatable file (such as on Darwin) which may have a function
Tristan> at address 0.  If its backlink (ie the executable) has no
Tristan> section at 0 (which is the rule), one or more symbols disappear
Tristan> in the symtab.

This seems strange to me.  My mental model is that the separate debug
objfile describes the parent objfile.  To me this implies that on Darwin
you ought to relocate the separate debug objects.

Tristan> Because a separate debug file may be completely unrelated (in
Tristan> terms of mapping) from its backlink, we shouldn't try to copy
Tristan> the has_section_at_zero.  Instead, we also consider SEC_ALLOC
Tristan> sections to set has_section_at_zero.  This makes sense because
Tristan> you may perfectly have the bss at zero.

This also seems a little weird, given that has_section_at_zero is only
used to determine whether PC ranges are valid in some situations.

Tristan> No regression on GNU Linux i386.

I wonder whether this code path is tested there.
I don't know.

Tom


  reply	other threads:[~2010-01-11 21:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-07 13:09 Tristan Gingold
2010-01-11 21:29 ` Tom Tromey [this message]
2010-01-12  5:01   ` Kevin Buettner
2010-01-12  8:56     ` Tristan Gingold
2010-04-19 20:27     ` Joel Brobecker
2010-01-12  8:55   ` Tristan Gingold
2010-04-28 22:40 ` Kevin Buettner
2010-05-05 18:43   ` 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=m3tyusnxf3.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=gingold@ACT-Europe.FR \
    --cc=kevinb@redhat.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