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] |
Thanks, that helps a bit. I just had a look and found the read()/write() stuff in newlib-src/newlib/libc/sys/h8300hms. For some stupid reason, i can't remember seeing target systems in there. All along, i've been looking at the target directories in newlib-src/libgloss. Why are there two different directories of targets? Its the unexplained overall structure of the source trees and build steps that makes working-out problems difficult. So, if i just modify the read()/write()/sbrk() functions in newlib-src/newlib/libc/sys/h8300hms, then rebuild, would that work? Also, when configuring newlib says libgloss is not supported for the h8300-hms, what does that mean? The configure stops at that message too. Kai Ruottu wrote: > > 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 -- ******************************************* * Russell Shaw, B.Eng, M.Eng(Research) * * email: russell@webaxs.net * * Victoria, Australia * ******************************************* ------ 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] |