This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more infromation.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Noah Aklilu wrote: > > I don't think you really have to mess with libgloss directories until > you have something definite in the way of libraries setup. Here are > snippets of my makefile and linker script for a 68306 system I was > working on recently: The 'h8300-hms' is a 'fully defined target', just like 'i586-linux' is. Ie. the produced C-library includes all the necessary functions for getting the first 'Hello World' compiled and linked just by writing: h8300-hms-gcc -o hello hello.c So the 'H8/300 with the HMS-monitor (or what the HMS then was) could be called a 'system' target like Linux. But the 'm68k-coff/elf' targets don't tell anything about the real target, only about the used object format. When trying the equivalent: m68k-coff-gcc -o hello hello.c all kind of undefined symbols (_write, _open, _sbrk) will be seen. Then we will see 'funny' ;-) questions from newbies why these functions are missing... Of course every embedded engineer should know why they are missing from the C-library ;-) Russell Shaw wrote: > When doing a newlib build for h8300-hms, it says something like libgloss > is not supported for h8300-hms, and so does not install any libgloss > stuff. Being the first micro i've used with gcc, i didn't know what > should happen. I traced thru all the configure(.in) and makefiles > to work out how to add libgloss for the h8300-hms, but it was all > too complicated, even after reading porting.texi which looks like > a rough first attempt. I looked at other libgloss directories so > i could put the same thing in a hitachi libgloss directory, but > all the other micros had different files to each other, and i > couldn't work out how/if a configure.in should be modified to > get the new entries. Its also not obvious from looking at the > other libgloss directories what files are really required and > what aren't. To compound all that, i tried to work out if the > existing functions would need to be modified/deleted. I'll > have another go in a months time. The 'libgloss' for the H8/300 is where all the other 'system' targets are, so it is in the 'newlib/libc/sys/h8300hms' (not in 'h8300' as I remembered earlier). It is not the only embedded target having its 'libgloss' there, the 'h8500hms', 'd10v' etc. seem to have their low-level routines there. The routines in the 'newlib/libc/sys/h8300hms' will be automatically included into the resulted 'libc.a'. The 'Makefile.in' there controls the object names, so splitting the 'syscalls.c' into separate files and replacing the 'syscalls.o' in the 'Makefile.in' with a list of the splitten routine names, would result into a more fine-grained library. Keeping them all in the 'syscalls.o' simply causes the whole 'syscalls.o' always being linked, not only '_write.o' and '_read.o', if only these are needed. The same has now been done in the 'libgcc.a' in newer GCC sources, so one can get several kilobytes smaller executables, when not the whole 'fp-bit.o' will be linked. The 'porting.texi' or something should have hinted about the modular structure in newlib, ie. the lowest-level routines are not splitted everywhere in the sources, but being in a subdirectory in 'libgloss' or in 'newlib/libc/sys'. So nobody should need to care (first) about anything else but these directories when building the self-made glue-library for the self-made target board. Only a small 'module' in the big system must be fixed in order to get the system to work. Adding a new target like 'h8300-shaw' with its own glue routines would happen simply by copying the stuff from 'newlib/libc/sys/h8300hms' into 'newlib/libc/sys/h8300shaw' and adding a new 'system-directory', 'h8300shaw', into the 'newlib/configure.in' (this may be changed in newlib-1.8.2, but grep'ing for the 'h8300hms' in the 'newlib' would tell where the definition now is...) for the new target template 'h8300-shaw'. The 'libc/machine/h8300' etc. should be selected only via the 'h8300' in the start of the target name... I have used this method for adding targets like 'i386-sysv4', using the existing 'sysvi386' (for SVR3.2) as the basement. This was done in order to get a 'glue library' for i386-elf, consisting of SVR4-syscalls, so that after linking against 'libc.a' and 'libsvr4.a', the executables would run under Linux with ibcs2 (or under a real SVR4/i386 like UnixWare). I haven't tried to create a new libgloss target... Ok, after making a new target and copied the h8300-hms stuff for it, modifying the copies wouldn't break anything in the original 'h8300-hms'... Unfortunately the low-level routines will be included to the 'libc.a' for 'h8300-shaw' in this scheme, but does it really matter? If you keep the built objects untouched and then modify something in the 'newlib/libc/sys/h8300shaw', and write the 'make', only the modified things will be replaced... When you do 'make install', the libs will go into '$prefix/h8300-shaw' and you can move them from there or do the install manually... For my 'i386-elf' case, I had first built for the 'i386-elf' and had no low-level stuff for anything, so I couldn't produce executables for anything. After adding the 'i386-sysv4', the startup and low-level I/O for a SVR4 system were produced and I could take the extra stuff from that build into the separate 'libsvr4.a'. For the h8300 there doesn't seem to be 'pure' h8300-target, like 'h8300-coff', for which only the target-independent routines would be built and put into the 'libc.a'. So getting a separate 'libc.a' (without the low-level stuff) and a 'libshaw.a' (with the low-level stuff) for your H8/300 target doesn't seem to be easy to automatize with this 'system' approach... Cheers, Kai ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |