From: Pedro Alves <palves@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 2/3] relocate the entry point addess when used
Date: Wed, 08 Jan 2014 13:22:00 -0000 [thread overview]
Message-ID: <52CD5129.7090003@redhat.com> (raw)
In-Reply-To: <1389040247-2620-3-git-send-email-tromey@redhat.com>
On 01/06/2014 08:30 PM, Tom Tromey wrote:
> This changes the entry point to be unrelocated in the objfile, and
> instead applies the relocation when it is used.
>
> I think the existing code here is wrong. It computes the entry point
> address directly from the BFD, not applying any runtime offsets.
> However, then objfile_relocate1 passes this address to find_pc_section
> -- which does use the offsets . So, it seems to me that the current
> code can only find the correct address by luck.
It's twisted, but I don't think it's luck. You can convince yourself
it works by debugging a PIE, and trying a backtrace past main
("set backtrace past-main" will then trigger the code to stop the
backtrace at the entry point), or doing "info files" (shows the entry).
Thing is, find_pc_section uses obj_section_addr/obj_section_endaddr
for comparison:
/* Bsearch comparison function. */
static int
bsearch_cmp (const void *key, const void *elt)
{
const CORE_ADDR pc = *(CORE_ADDR *) key;
const struct obj_section *section = *(const struct obj_section **) elt;
if (pc < obj_section_addr (section))
return -1;
if (pc < obj_section_endaddr (section))
return 0;
return 1;
}
And obj_section_addr indeed applies the offsets:
/* Relocation offset applied to S. */
#define obj_section_offset(s) \
(((s)->objfile->section_offsets)->offsets[gdb_bfd_section_index ((s)->objfile->obfd, (s)->the_bfd_section)])
/* The memory address of section S (vma + offset). */
#define obj_section_addr(s) \
(bfd_get_section_vma ((s)->objfile->obfd, s->the_bfd_section) \
+ obj_section_offset (s))
/* The one-passed-the-end memory address of section S
(vma + size + offset). */
#define obj_section_endaddr(s) \
(bfd_get_section_vma ((s)->objfile->obfd, s->the_bfd_section) \
+ bfd_get_section_size ((s)->the_bfd_section) \
+ obj_section_offset (s))
But, objfile_relocate1 only sets the offsets to the obj_sections
_after_ looking up the entry point:
if (objfile->ei.entry_point_p)
{
/* Relocate ei.entry_point with its section offset, use SECT_OFF_TEXT
only as a fallback. */
struct obj_section *s;
s = find_pc_section (objfile->ei.entry_point);
if (s)
{
int idx = gdb_bfd_section_index (objfile->obfd, s->the_bfd_section);
objfile->ei.entry_point += ANOFFSET (delta, idx);
}
else
objfile->ei.entry_point += ANOFFSET (delta, SECT_OFF_TEXT (objfile));
}
{
int i;
for (i = 0; i < objfile->num_sections; ++i)
(objfile->section_offsets)->offsets[i] = ANOFFSET (new_offsets, i);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
}
So find_pc_section is still using the unrelocated section addresses
when looking up the entry point's unrelocated address.
> +
> + ALL_OBJFILE_OSECTIONS (objfile, osect)
> + {
> + struct bfd_section *sect = osect->the_bfd_section;
> +
> + if (entry_point >= bfd_get_section_vma (objfile->obfd, sect)
> + && entry_point < (bfd_get_section_vma (objfile->obfd, sect)
> + + bfd_get_section_size (sect)))
> + {
> + objfile->ei.the_bfd_section_index
> + = gdb_bfd_section_index (objfile->obfd, sect);
> + break;
> + }
> + }
> +
> + if (osect == NULL)
This is assuming osect ends up NULL after iterating over all.
It's violating the abstraction of the macro. And, actually,
it's wrong, showing exactly why such assumptions are a bad idea:
#define ALL_OBJFILE_OSECTIONS(objfile, osect) \
for (osect = objfile->sections; osect < objfile->sections_end; osect++) \
if (osect->the_bfd_section == NULL) \
{ \
/* Nothing. */ \
} \
else
OSECT doesn't end up NULL at the end of the iteration at all.
It's better to, make the "break" above when the section is found
be a return instead.
> + objfile->ei.the_bfd_section_index = SECT_OFF_TEXT (objfile);
> }
> }
>
>
--
Pedro Alves
next prev parent reply other threads:[~2014-01-08 13:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-06 20:30 [PATCH 0/3] move entry point info to the per-BFD object Tom Tromey
2014-01-06 20:30 ` [PATCH 1/3] change solib-frv to use entry_point_address_query Tom Tromey
2014-01-08 13:23 ` Pedro Alves
2014-01-06 20:30 ` [PATCH 2/3] relocate the entry point addess when used Tom Tromey
2014-01-08 13:22 ` Pedro Alves [this message]
2014-01-13 20:46 ` Tom Tromey
2014-01-15 11:42 ` Pedro Alves
2014-01-15 17:59 ` Tom Tromey
2014-01-15 18:02 ` Pedro Alves
2014-01-06 20:30 ` [PATCH 3/3] move the entry point info into the per-bfd object Tom Tromey
2014-01-08 13:30 ` Pedro Alves
2014-01-13 20:51 ` Tom Tromey
2014-01-15 18:01 ` [PATCH 0/3] move entry point info to the per-BFD object Tom Tromey
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=52CD5129.7090003@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).