On Tue, 2004-04-27 at 21:42, Jason Thorpe wrote:
> On Apr 27, 2004, at 11:28 AM, Richard Earnshaw wrote:
> 
> > Yet again I've been bitten by the objcopy bug that causes the a.out
> > version of the kernel image to have the .data and .bss sections at the
> > wrong vma.
> 
> Ack.  I thought I fixed that in the a.out back-end a while ago.

Nope.  A brief foray into aoutx.h in the BFD last night showed that
there were probably several problems.  The principal one is that the
size of the output sections is determined before we even know that we
have sections to merge.  A principal tenet of the BFD is that no changes
are made to the output sections once file writing has begun.

If I were the binutils maintainer (you might think it fortunate that I'm
not :-), I think I'd want to see the existing hack expunged and replaced
with some command-line mechanism that merged sections explicitly. 
Something like

	foo-elf-objcopy -O a.out-foo-netbsd ... --merge-sections \
	 .text+=link_set_pools,link_set_sysctl_funcs,...

etc.

It would then be fairly easy to implement this in the front end of
objcopy in a manner similar to the way it manages the removal of
sections and symbols.  The front-end parts of the tools would then
create mega .text sections which the back-end would then process in the
normal way.  That would work for any object file formats not just for
a.out.

However, that means you'd still need to list the sections being merged
somewhere, only now it would be a makefile fragment rather than a linker
script.

> 
> > Can you think of any reason (other than the fact that it make the 
> > script
> > more complex) why we can't just work around the problem by using the
> > following in link scripts for affected platforms?
> 
> Yes.  Because explicitly listing the link sets in the linker script 
> defeats the purpose of them.  Any arbitrary code can define additional 
> link sets, which would then have to be listed here in the linker 
> script.
> 

It's hardly that bad.  The list is almost certainly more static than the
list of header files that we maintain set information for in the
distribution system.  If we can manage that, I don't really see why we
can't cope with a couple of linker scripts that need a list of
additional symbols.

> We really need to figure out how to make the a.out back-end copy them 
> reliably.

How long is that going to take?  Can you guarantee to have a solution
before 2.0 ships?  As it stands there is about a 1 in 10 chance of any
particular kernel being unable to boot (the added sections come to about
490 bytes -- if that pushes the .text section into the next 4k page your
binary won't boot).  That means that there's about a 1 in 5 chance that
somebody trying to use INSTALL will either be unable to, or will end up
with a non-bootable system afterwards.

My suggestion would be to check in my suggested change on SHARK and CATS
until such time as the objcopy problem is solved.  At least then we
wouldn't be persistently ending up with dead systems.

R.