Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tristan Gingold <gingold@adacore.com>
To: tromey@redhat.com
Cc: Tristan Gingold <gingold@ACT-Europe.FR>,
	 gdb-patches@sourceware.org,  kevinb@redhat.com
Subject: Re: [RFA] Fix has_section_at_zero for separate debug files
Date: Tue, 12 Jan 2010 08:55:00 -0000	[thread overview]
Message-ID: <3250D752-12F1-4FE9-ADFF-E046B4DCF7DE@adacore.com> (raw)
In-Reply-To: <m3tyusnxf3.fsf@fleche.redhat.com>


On Jan 11, 2010, at 10:28 PM, Tom Tromey wrote:

>>>>>> "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.

That's correct.

>  To me this implies that on Darwin
> you ought to relocate the separate debug objects.

Currently we don't relocate it (ie we don't apply relocs), we simply set offsets.  But the code doesn't
tests offsets.
Of course not relocating is somewhat wrong, because of common symbols.  But that's how it works now, and
I am working on using relocations.

> 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.

Argh, you're right.  I thought it was also used to check wether variables exists or not.

> Tristan> No regression on GNU Linux i386.
> 
> I wonder whether this code path is tested there.
> I don't know.

I think so.  I tested the little example with gdb unpatched, with the code removed in the patch (failure)
and with the full patch.

Tristan.


  parent reply	other threads:[~2010-01-12  8:55 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
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 [this message]
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=3250D752-12F1-4FE9-ADFF-E046B4DCF7DE@adacore.com \
    --to=gingold@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=gingold@ACT-Europe.FR \
    --cc=kevinb@redhat.com \
    --cc=tromey@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