Subject: Re: modified crunchgen
To: David Laight <david@l8s.co.uk>
From: Simon Burge <simonb@wasabisystems.com>
List: tech-userlevel
Date: 11/14/2003 08:11:43
On Thu, Nov 13, 2003 at 08:55:25PM +0000, David Laight wrote:
> On Fri, Nov 14, 2003 at 05:58:52AM +1100, Simon Burge wrote:
> > On Thu, Nov 13, 2003 at 01:45:33PM -0500, Rafal Boni wrote:
> > > In message <20031113134236.C1838@snowdrop.l8s.co.uk>, you write: 
> > > 
> > > -> I've modified crunchgen so that it no longer needs to parse each program's
> > > -> Makefile to find the list of objects to build.  Instead it relies on the
> > > -> program's Makefile having a ${PROG}.ro: ld -r ${OBJS} ${.TARGET} rule.
> > 
> > I'm not sure I understand this - does each program's normal Makefile
> > that is part of a ramdisk (or any other crunchgen'd program) need to
> > have an entry like you mention above (${PROG}.ro)?
> 
> It is in bsd.prog.mk just below the one that generates ${PROG}.
> So none of the usual netbsd makefiles need to be changed.

Good!

> > > -> Also changed:
> > > -> - Delete code for RENAME_SYMS - all getting too hard!
> > > 
> > > Hmm, I think this was necessary for MIPS with 2.95.3 and the 2.95.3-era
> > > binutils, otherwise we'd overflow the GOT building large crunched binaries
> > > (this is why the 1.6-branch MIPS installers don't have dhcp support; linking
> > > in dhclient tipped the crunched binary used by the installer over the edge).
> > > 
> > > I haven't looked at the state of all this after the integraton of the new
> > > gcc & binutils, but you should probably verify that it won't kill MIPS ports
> > > before ripping it out (making sure rescue builds is a start; I think it 
> > > didn't on MIPS platforms before Simon added the renaming code).
> > 
> > Same as Rafal, I haven't looked to see if we still require the
> > rename-syms hack with new gcc/bintuils.  I'll be a bit unhappy
> > if you manage to break all the MIPS ports that have a ramdisk :-)
> 
> I've actually removed the code for not RENAME_SYMS - the source had a hard
> #define RENAME_SYMS, so it wasn't a build option.
> I thought there was a problem with different types of fixups for local
> and global symbols, so changing a symbol to local was non-trivial.

Oh, so rename-names is staying and converting to local is going away?
If so, that's sorta okay...

I still think the best option is for binutils to support making symbols
local on all architectures, but I didn't have the knowledge to fix
MIPS to do this.  I made the RENAME_SYMS #define hardcoded because it
worked on all architectures and seemed nicer than just #ifdef'ing on a
MIPS target.  If binutils is fixed so that making symbols local on MIPS
works, I'd prefer we switch back to making local symbols.  Maybe add a
comment to this effect if there is #ifdef hell leaving support for both
in?

> I don't actually fancy cross building ALL the mips ports!
> I haven't got that much disk space - might do some of one though,

If rename-syms if staying, this isn't necessary.

Simon.
--
Simon Burge                                   <simonb@wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/