(Added Ian Jackson to Cc:, if you have a moment please take a look at the two questions toward the bottom)
[email protected] said: > On 12/12/14 17:48, Martin Lucina wrote: > > Hi, > > > > Due to historical reasons, the rumprun-xen build was part of the > > (bastardized) Mini-OS Makefile. After much battle I have managed to > > separate the two. > > The hero of the day! Thanks :-) > > > One bizarre thing is that I had to make an additional change to Mini-OS > > adding monotonic_clock to the global minios_ namespace (commit > > https://github.com/rumpkernel/rumprun-xen/commit/1dcf10a5220c30b0c301238b66bb0948c4c0c85d). > > I have no idea how the build could have worked before without this > > change... > > well, dunno, the final rump-kernel binary under the old system has: > pooka@watou:~/rumpkernel/rumprun-xen$ nm -a rump-kernel | grep > monotonic_clock > 000000000006a60e t monotonic_clock > 0000000000072d53 T monotonic_clock > > not sure where the global one is coming from. I tried obvious places > like the user level libs, but couldn't find anything. Not sure I want > to start investigating this, though I'm afraid it will come back to > haunt us later if left unchecked. > > At any rate, that symbol belongs in the minios namespace (at least the > one provided by minios ;) I think it may be some subtle change to the order in which -isystem / -I are passed to the compiler when building. Will investigate. > > > Anyhow, feel free to review if you are feeling brave; I will merge this at > > some point once I've slept on it and fixed up some of the loose ends. > > I think this is the right direction and I would just merge once things > build and work. Or do you think the diffs need review? I will clean things up a bit more on Monday and if everything looks OK will merge ASAP. Review, not so much, but there are a couple of things I'm unsure about. I suspect Ian would be best in answering these, have added him to Cc. 1) Previously we built the startfile for linking the application + minios separately (i.e. x86_{32|64).o) and specified that as startfile in the app-tools gcc specs. So the components got linked as (roughly): startfile app objects minios.o rumprun.o libs I wanted to get rid of the need for the toplevel / app-tools makefiles to know where startfile is, plus the additional dependency on the minios arch-specific lib in the final link. So I changed the build to add x86_(32|64).o directly into the minios.o when linking it with ld -r and specified that (minios.o) as the startfile. So the new link order is: startfile (minios.o) app objects rumprun.o libs What I'm unsure about is if there are any downsides to this change, and whether or not it is "bad practice" to stuff all of minios in the linker's startfile. Also, due to the link order change the resulting order in memory in the final image also changes appropriately. 2) Which parts of the code *must* be compiled with the arch-specific CFLAGS, i.e. this bit at the top of the (new) Makefile: ifeq ($(TARGET_ARCH),i386) CFLAGS += -m32 -march=i686 endif ifeq ($(TARGET_ARCH),x86_64) CFLAGS += -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables endif I initially missed this and everything was unstable; Ian explained the -mno-red-zone stuff while I was in London but I don't know which modules need it? Regarding future direction, I would like to move as much of buildxen.sh as is practical into the Makefile-driven parts, specifically in the beginning at least the parts built in the "makekernlib" steps. Perhaps you could take a look at doing that if you have time? Thanks, Martin ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ rumpkernel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
