* [RFA] symtab.c: Search section table when fixing up a symbol'ssection
@ 2004-05-17 19:02 Kevin Buettner
2004-05-17 21:01 ` [RFA] symtab.c: Search section table when fixing up a symbol's section Jim Blandy
0 siblings, 1 reply; 6+ messages in thread
From: Kevin Buettner @ 2004-05-17 19:02 UTC (permalink / raw)
To: gdb-patches
The patch below fixes all scope.exp failures for the frv-uclinux target.
I believe that fixup_section() was broken for many other targets too,
but innocuously so, since most targets relocate all sections (for a
particular objfile) by a single constant. Thus, for those targets, it
doesn't matter that fixup_section() incorrectly computes (or fails to
compute) a symbol's section index. OTOH, the frv-uclinux target
requires that the section index be accurately computed since read-only
and read/write sections are relocated by different amounts. Other
targets with this property (such as AIX) avoid the problem by making
sure that the section value is set correctly by the symbol reader itself.
Other details are included in a comment in the patch itself. (See
below.)
Thanks to Jim Blandy for suggesting the section table search. My
first attempt at fixing this problem used a much less efficient
search of the minimal symbols.
Okay to commit?
* symtab.c (fixup_section): Search section table when lookup by
name fails.
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.129
diff -u -p -r1.129 symtab.c
--- symtab.c 8 Apr 2004 21:18:13 -0000 1.129
+++ symtab.c 17 May 2004 18:57:34 -0000
@@ -868,6 +868,62 @@ fixup_section (struct general_symbol_inf
ginfo->bfd_section = SYMBOL_BFD_SECTION (msym);
ginfo->section = SYMBOL_SECTION (msym);
}
+ else if (objfile)
+ {
+ /* Static, function-local variables do appear in the linker
+ (minimal) symbols, but are frequently given names that won't
+ be found via lookup_minimal_symbol(). E.g., it has been
+ observed in frv-uclinux (ELF) executables that a static,
+ function-local variable named "foo" might appear in the
+ linker symbols as "foo.6" or "foo.3". Thus, there is no
+ point in attempting to extend the lookup-by-name mechanism to
+ handle this case due to the fact that there can be multiple
+ names.
+
+ So, instead, search the section table when lookup by name has
+ failed. The ``addr'' and ``endaddr'' fields may have already
+ been relocated. If so, the relocation offset (i.e. the
+ ANOFFSET value) needs to be subtracted from these values when
+ performing the comparison. We unconditionally subtract it,
+ because, when no relocation has been performed, the ANOFFSET
+ value will simply be zero.
+
+ The address of the symbol whose section we're fixing up HAS NOT
+ BEEN adjusted (relocated) yet. It can't have been since the
+ section isn't yet known and knowing the section is necessary
+ in order to add the correct relocation value. In other
+ words, we wouldn't even be in this function (attempting to
+ compute the section) if it were already known.
+
+ Note that it is possible to search the minimal symbols
+ (subtracting the relocation value if necessary) to find the
+ matching minimal symbol, but this is overkill and much less
+ efficient. It is not necessary to find the matching minimal
+ symbol, only its section.
+
+ Note that this technique (of doing a section table search)
+ can fail when unrelocated section addresses overlap. For
+ this reason, we still attempt a lookup by name prior to doing
+ a search of the section table. */
+
+ CORE_ADDR addr;
+ struct obj_section *s;
+
+ addr = ginfo->value.address;
+
+ ALL_OBJFILE_OSECTIONS (objfile, s)
+ {
+ int idx = s->the_bfd_section->index;
+ CORE_ADDR offset = ANOFFSET (objfile->section_offsets, idx);
+
+ if (s->addr - offset <= addr && addr <= s->endaddr - offset)
+ {
+ ginfo->bfd_section = s->the_bfd_section;
+ ginfo->section = idx;
+ return;
+ }
+ }
+ }
}
struct symbol *
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RFA] symtab.c: Search section table when fixing up a symbol's section
2004-05-17 19:02 [RFA] symtab.c: Search section table when fixing up a symbol'ssection Kevin Buettner
@ 2004-05-17 21:01 ` Jim Blandy
2004-05-17 21:23 ` [RFA] symtab.c: Search section table when fixing up a symbol'ssection Kevin Buettner
0 siblings, 1 reply; 6+ messages in thread
From: Jim Blandy @ 2004-05-17 21:01 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
Kevin Buettner <kevinb@redhat.com> writes:
> The patch below fixes all scope.exp failures for the frv-uclinux target.
>
> I believe that fixup_section() was broken for many other targets too,
> but innocuously so, since most targets relocate all sections (for a
> particular objfile) by a single constant. Thus, for those targets, it
> doesn't matter that fixup_section() incorrectly computes (or fails to
> compute) a symbol's section index. OTOH, the frv-uclinux target
> requires that the section index be accurately computed since read-only
> and read/write sections are relocated by different amounts. Other
> targets with this property (such as AIX) avoid the problem by making
> sure that the section value is set correctly by the symbol reader itself.
>
> Other details are included in a comment in the patch itself. (See
> below.)
>
> Thanks to Jim Blandy for suggesting the section table search. My
> first attempt at fixing this problem used a much less efficient
> search of the minimal symbols.
>
> Okay to commit?
Oh, endaddr *is* inclusive. Well done.
I'm going to leave this for others' comments for a few days, but other
than that, it looks good to me.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFA] symtab.c: Search section table when fixing up a symbol'ssection
2004-05-17 21:01 ` [RFA] symtab.c: Search section table when fixing up a symbol's section Jim Blandy
@ 2004-05-17 21:23 ` Kevin Buettner
2004-05-18 6:15 ` [RFA] symtab.c: Search section table when fixing up a symbol's section Jim Blandy
2004-05-18 17:00 ` Jim Blandy
0 siblings, 2 replies; 6+ messages in thread
From: Kevin Buettner @ 2004-05-17 21:23 UTC (permalink / raw)
To: Jim Blandy; +Cc: gdb-patches
On 17 May 2004 15:57:20 -0500
Jim Blandy <jimb@redhat.com> wrote:
> Oh, endaddr *is* inclusive. Well done.
Actually, I don't think it is:
CORE_ADDR endaddr; /* 1+highest address in section */
I'm appending a revised patch.
> I'm going to leave this for others' comments for a few days, but other
> than that, it looks good to me.
Thanks for looking it over.
* symtab.c (fixup_section): Search section table when lookup by
name fails.
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.129
diff -u -p -r1.129 symtab.c
--- symtab.c 8 Apr 2004 21:18:13 -0000 1.129
+++ symtab.c 17 May 2004 21:13:13 -0000
@@ -868,6 +868,62 @@ fixup_section (struct general_symbol_inf
ginfo->bfd_section = SYMBOL_BFD_SECTION (msym);
ginfo->section = SYMBOL_SECTION (msym);
}
+ else if (objfile)
+ {
+ /* Static, function-local variables do appear in the linker
+ (minimal) symbols, but are frequently given names that won't
+ be found via lookup_minimal_symbol(). E.g., it has been
+ observed in frv-uclinux (ELF) executables that a static,
+ function-local variable named "foo" might appear in the
+ linker symbols as "foo.6" or "foo.3". Thus, there is no
+ point in attempting to extend the lookup-by-name mechanism to
+ handle this case due to the fact that there can be multiple
+ names.
+
+ So, instead, search the section table when lookup by name has
+ failed. The ``addr'' and ``endaddr'' fields may have already
+ been relocated. If so, the relocation offset (i.e. the
+ ANOFFSET value) needs to be subtracted from these values when
+ performing the comparison. We unconditionally subtract it,
+ because, when no relocation has been performed, the ANOFFSET
+ value will simply be zero.
+
+ The address of the symbol whose section we're fixing up HAS
+ NOT BEEN adjusted (relocated) yet. It can't have been since
+ the section isn't yet known and knowing the section is
+ necessary in order to add the correct relocation value. In
+ other words, we wouldn't even be in this function (attempting
+ to compute the section) if it were already known.
+
+ Note that it is possible to search the minimal symbols
+ (subtracting the relocation value if necessary) to find the
+ matching minimal symbol, but this is overkill and much less
+ efficient. It is not necessary to find the matching minimal
+ symbol, only its section.
+
+ Note that this technique (of doing a section table search)
+ can fail when unrelocated section addresses overlap. For
+ this reason, we still attempt a lookup by name prior to doing
+ a search of the section table. */
+
+ CORE_ADDR addr;
+ struct obj_section *s;
+
+ addr = ginfo->value.address;
+
+ ALL_OBJFILE_OSECTIONS (objfile, s)
+ {
+ int idx = s->the_bfd_section->index;
+ CORE_ADDR offset = ANOFFSET (objfile->section_offsets, idx);
+
+ if (s->addr - offset <= addr && addr < s->endaddr - offset)
+ {
+ ginfo->bfd_section = s->the_bfd_section;
+ ginfo->section = idx;
+ return;
+ }
+ }
+ }
}
struct symbol *
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RFA] symtab.c: Search section table when fixing up a symbol's section
2004-05-17 21:23 ` [RFA] symtab.c: Search section table when fixing up a symbol'ssection Kevin Buettner
@ 2004-05-18 6:15 ` Jim Blandy
2004-05-18 17:00 ` Jim Blandy
1 sibling, 0 replies; 6+ messages in thread
From: Jim Blandy @ 2004-05-18 6:15 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
Kevin Buettner <kevinb@redhat.com> writes:
> On 17 May 2004 15:57:20 -0500
> Jim Blandy <jimb@redhat.com> wrote:
>
> > Oh, endaddr *is* inclusive. Well done.
>
> Actually, I don't think it is:
>
> CORE_ADDR endaddr; /* 1+highest address in section */
>
> I'm appending a revised patch.
Damn. It *should* be inclusive; otherwise you can't really represent
ranges that abut the top of the address space when CORE_ADDR is no
larger than a target address.
Well, I'm glad we caught it.
> > I'm going to leave this for others' comments for a few days, but other
> > than that, it looks good to me.
>
> Thanks for looking it over.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFA] symtab.c: Search section table when fixing up a symbol's section
2004-05-17 21:23 ` [RFA] symtab.c: Search section table when fixing up a symbol'ssection Kevin Buettner
2004-05-18 6:15 ` [RFA] symtab.c: Search section table when fixing up a symbol's section Jim Blandy
@ 2004-05-18 17:00 ` Jim Blandy
2004-05-24 16:12 ` [RFA] symtab.c: Search section table when fixing up a symbol'ssection Kevin Buettner
1 sibling, 1 reply; 6+ messages in thread
From: Jim Blandy @ 2004-05-18 17:00 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
Just to make this explicit: if there are no further comments on this
by the end of Friday, feel free to commit this.
Kevin Buettner <kevinb@redhat.com> writes:
> Thanks for looking it over.
>
> * symtab.c (fixup_section): Search section table when lookup by
> name fails.
>
> Index: symtab.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.c,v
> retrieving revision 1.129
> diff -u -p -r1.129 symtab.c
> --- symtab.c 8 Apr 2004 21:18:13 -0000 1.129
> +++ symtab.c 17 May 2004 21:13:13 -0000
> @@ -868,6 +868,62 @@ fixup_section (struct general_symbol_inf
> ginfo->bfd_section = SYMBOL_BFD_SECTION (msym);
> ginfo->section = SYMBOL_SECTION (msym);
> }
> + else if (objfile)
> + {
> + /* Static, function-local variables do appear in the linker
> + (minimal) symbols, but are frequently given names that won't
> + be found via lookup_minimal_symbol(). E.g., it has been
> + observed in frv-uclinux (ELF) executables that a static,
> + function-local variable named "foo" might appear in the
> + linker symbols as "foo.6" or "foo.3". Thus, there is no
> + point in attempting to extend the lookup-by-name mechanism to
> + handle this case due to the fact that there can be multiple
> + names.
> +
> + So, instead, search the section table when lookup by name has
> + failed. The ``addr'' and ``endaddr'' fields may have already
> + been relocated. If so, the relocation offset (i.e. the
> + ANOFFSET value) needs to be subtracted from these values when
> + performing the comparison. We unconditionally subtract it,
> + because, when no relocation has been performed, the ANOFFSET
> + value will simply be zero.
> +
> + The address of the symbol whose section we're fixing up HAS
> + NOT BEEN adjusted (relocated) yet. It can't have been since
> + the section isn't yet known and knowing the section is
> + necessary in order to add the correct relocation value. In
> + other words, we wouldn't even be in this function (attempting
> + to compute the section) if it were already known.
> +
> + Note that it is possible to search the minimal symbols
> + (subtracting the relocation value if necessary) to find the
> + matching minimal symbol, but this is overkill and much less
> + efficient. It is not necessary to find the matching minimal
> + symbol, only its section.
> +
> + Note that this technique (of doing a section table search)
> + can fail when unrelocated section addresses overlap. For
> + this reason, we still attempt a lookup by name prior to doing
> + a search of the section table. */
> +
> + CORE_ADDR addr;
> + struct obj_section *s;
> +
> + addr = ginfo->value.address;
> +
> + ALL_OBJFILE_OSECTIONS (objfile, s)
> + {
> + int idx = s->the_bfd_section->index;
> + CORE_ADDR offset = ANOFFSET (objfile->section_offsets, idx);
> +
> + if (s->addr - offset <= addr && addr < s->endaddr - offset)
> + {
> + ginfo->bfd_section = s->the_bfd_section;
> + ginfo->section = idx;
> + return;
> + }
> + }
> + }
> }
>
> struct symbol *
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RFA] symtab.c: Search section table when fixing up a symbol'ssection
2004-05-18 17:00 ` Jim Blandy
@ 2004-05-24 16:12 ` Kevin Buettner
0 siblings, 0 replies; 6+ messages in thread
From: Kevin Buettner @ 2004-05-24 16:12 UTC (permalink / raw)
To: Jim Blandy; +Cc: gdb-patches
On 18 May 2004 11:55:49 -0500
Jim Blandy <jimb@redhat.com> wrote:
> Just to make this explicit: if there are no further comments on this
> by the end of Friday, feel free to commit this.
>
> Kevin Buettner <kevinb@redhat.com> writes:
> > Thanks for looking it over.
> >
> > * symtab.c (fixup_section): Search section table when lookup by
> > name fails.
Committed.
Kevin
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-05-24 16:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-05-17 19:02 [RFA] symtab.c: Search section table when fixing up a symbol'ssection Kevin Buettner
2004-05-17 21:01 ` [RFA] symtab.c: Search section table when fixing up a symbol's section Jim Blandy
2004-05-17 21:23 ` [RFA] symtab.c: Search section table when fixing up a symbol'ssection Kevin Buettner
2004-05-18 6:15 ` [RFA] symtab.c: Search section table when fixing up a symbol's section Jim Blandy
2004-05-18 17:00 ` Jim Blandy
2004-05-24 16:12 ` [RFA] symtab.c: Search section table when fixing up a symbol'ssection Kevin Buettner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox