[ Accidentally-dropped cc to tech-kern restored with jhawk's permission. ]

On Sat, 18 Aug 2001, John Hawkinson wrote:

> There we have it, then. Slow, sloppy, and imprecise :-(

Well, you were right about the .stab problem, at least.

> It was my recollection that the SYSV ABI spec specified that you were
> supposed to find tables by looking them up in .shstrtab. However,
> reading the copy I have in
> "http://web.mit.edu/afs/sipb/contrib/doc/specs/protocol/sysv-abi",
> that does not seem to be the case.
>
> In fact, I don't see any reference to shstrtab.

It's mentioned by name in the list of special section (p. 4-20), and
indirectly in the description of sh_name (p. 4-12) and e_shstrndx
(p. 4-6).

> > >It seems to me that there are two ways to solve this problem -- one is to
> > >have loadfile and ddb and so-on "cheat" and make the presumption.
> >
> > What presumption?  I don't see it as cheating to use something (sh_link)
> > that's defined in the ELF spec.
>
> Frankly, I can't seem to find sh_link either.

It's on pp. 4-16--4-17.

> How is it defined?

It varies depending on the section it's in, but for SYMTABs, it's "The
section header index of the associated string table."  Incidentally, it
also seems to be used to link .stab and .stabstr sections together.

> > By "debugging symbols", do you mean the .stab and .stabstr sections?
> > Looking at a sample executable with them present here, it's true that
> > loading them will require loading .shstrtab, which is a pity.
>
> I do.
>
> I was hoping we could have some solution that would deal with this case
> as well as the regular case (no debugging symbols), without having to
> jump through hopps.

Sadly, some hoops are going to be necessary for this.  If nothing else,
ld seems to put the .stab and .stabstr sections before the section
headers, so a backward seek is going to be hard to avoid.  Also, I can't
see an obvious way to find the .stab section other than by looking it up
by name.

I think the best we can hope to do (without serious linker hackery, which
I'm not about to try) is to load non-debug kernels as we currently do,
heuristically spot ones which might have debugging information (>2 STRTABs
might be a start, or a PROGBITS with a non-zero sh_entsize), and go back
and grovel through .shstrtab on those ones only.

*sigh*  Why can't .stab have its own sh_type, like .symtab does?  That
would make life so much easier.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>