This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding crti.o and crtn.o to the newlib directory

On Thu, Oct 16, 2008 at 1:15 AM, Jeff Johnston <> wrote:
> Thomas Epperson wrote:
>> Is this something that would violate the way newlib operates with
>> libgloss?
>> For the configuration I have, I need to have my
>> newlib/libc/sys/(system) generate crti.o and crtn.o (which it does)
>> and then have those object files installed along with crt0.o.
>> Can I get any pointers to adding this to the config files in a way
>> that doesn't break other configurations?
>> Once I am done I will post my results so that others might benefit from
>> it.
> You're going to have to elaborate your particular situation.  If you have a
> crti.S and/or crtn.S for a particular
> platform or a set of particular platforms, then they belong in libgloss in
> the various platform directories along
> with their crt0.S counterparts.
> -- Jeff J.

It took me a while to figure it out, but I got it working the way I
wanted. I added crti.o and crtn.o to a libgloss directory for my
system (which I added). I also had to modify my gcc configuration so
that it would actually use the object files. Now I just have to figure
out a clean way of getting two versions of the syscalls. The kernel
would directly call the appropriate functions, while user code would
go through a syscall. I have a few solutions in mind, but neither of
them are as elegant as I would like for them to be.
I can put the syscalls in libgloss and not link in the libgloss
library for the kernel, but this would require explicit linking with
user mode programs. I read somewhere that you can do this with a
linker script, but I would prefer to not have to do this.
I can comment out the code in the newlib directory to create a kernel
version of the library and then uncomment it for user code, but again
this is messy. This works because I define the syscalls within other
objects in the kernel.
Maybe I could find a way to modify the default linker script that gcc
uses (so that it would add the libgloss library) for user programs
(since my kernel uses its own linker script) and add the libgloss
library to it. Then I won't have to do trickery anywhere for
compiling. I would have no need for anything in the newlib directory
anymore if I did this right?
Also, doing it this way will allow me to user other C libraries if I
so choose right?
The current method I am using for initialization routines is like
this. When the kernel boots up it does some initialization first
(depending on hardware of course), then it goes to the "normal" entry
point (_start). User programs will start out right at the _start entry
point. So the init code that newlib and libgloss should theoretically
be platform independent if I use C code right? The kernel will have
the environment setup before usermode _start gets executed. I don't
really know enough about other architectures to know for sure.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]