Date: Tue, 16 Jul 2002 11:15:01 -0700 From: Peter Wemm <peter@wemm.org> To: W Gerald Hicks <gehicks@gehicks.dyndns.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/release/picobsd/build write_mfs_in_kernel.c Message-ID: <20020716181501.C69CB3910@overcee.wemm.org> In-Reply-To: <5327CDCB-9867-11D6-9B14-0030657B5F1E@gehicks.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
W Gerald Hicks wrote: > > On Monday, July 15, 2002, at 09:28 PM, Peter Wemm wrote: > > > > > Yes, it is far far better to use objcopy --add-section, and then use > > &__start_<section> and &__stop_<section> symbols to find where it ended > > up. > > > > > > I've been doing it with a slightly different operation but yes it seems > to be a > better way than jumping in after linking and patching up the kernel > image. > > Even if one is concerned about toolchain portability something like this > exists > for every other (reasonable) toolchain I can think of. Whatever works. :-) I like the --add-section approach personally because it adapts automatically to the file format being used and seems to need less comamnd line args. However, it requires doing things a bit differently. I used to use it as a final pre-link stage on one file, but I suppose creating the .o file directly makes it easier from a Makefile perspective. I used to do things like this: mdroot.o: mdroot.dd mdroot_driver.o objcopy --add_section mdroot=mdroot.dd .... mdroot_driver.o: md.c ... etc And the build used the resulting mdroot.o with the binary embedded in it. Anyway, it is good to know that there is more than one way to do it and that the evil write_mfs_in_kernel can finally be laid to rest for good. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020716181501.C69CB3910>