Subject: Re: loadfile/ELF fixes, take 2
To: Ben Harris <bjh21@netbsd.org>
From: John Hawkinson <jhawk@MIT.EDU>
List: tech-kern
Date: 08/18/2001 17:29:00
Ben Harris <bjh21@netbsd.org> wrote on Sat, 18 Aug 2001
at 21:13:39 +0100 in <E15YCTT-0003Af-00@chiark.greenend.org.uk>:

> In that case, you missed loadfile.c 1.14 and db_elf.c 1.15 (both
> 2001-07-31).

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

> >So, is it not the case that this violates the ABI?
> 
> Can you be more precise?  It changes the interface between the loader and
> DDB slightly, such that old kernels won't be able to find the symbols passed
> by new loaders.  It doesn't stop them working otherwise, though.  I'm not
> sure there is a defined ABI for this area.

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 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.
How is it defined?

> >The other is to change the way the linker works so that the .shstrtab
> >is earlier in the executable. I'm not sure how tough this is.
> 
> That isn't what would be needed either.  The problem was that .shstrtab was
> before the section headers, i.e. that it was too early and needed to appear
> later.

> >At the moment, on the i386 port,
> 
> Is that before or after my changes?

Both, I presume.

> > we have the broken state where
> >ddb cannot read netbsd.gdb debugging symbols. I last thought
> >about this in July of last year and didn't really finish up, so
> >my memory is a bit tough, but I worry that not using shstrtab
> >means we won't be able to load that table properly.
> 
> 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.

--jhawk