| stekern | dtlbs are starting to fall into place | 07:55 |
|---|---|---|
| stekern | they are still not connected to anything though | 07:56 |
| stekern | and code is ugly, unoptimised and with hardcoded numbers ;) | 07:57 |
| blueCmd | cool! | 12:46 |
| blueCmd | stekern: I added -fPIC as default to my branch of gcc, I'm unsure if it's a good idea | 14:37 |
| blueCmd | i don't see why linking to a static library would require pic code from the beginning - assuming we require MMU | 14:43 |
| blueCmd | /srv/compilers/openrisc-devel/or1k-linux/sys-root/lib/ld-2.16.90.so: ELF 32-bit MSB shared object, version 1 (SYSV), dynamically linked, not stripped | 15:39 |
| blueCmd | that's nice :) | 15:39 |
| blueCmd | what's the status on gdb? the wiki says that it is nice and stable but I can't find any reference to where I can get it. or1k-src contains gdb, but it doesn't like my or1k-linux target (grep or32 -R gdb says almost nothing, same thing with or1k) | 16:21 |
| blueCmd | just removing "--disable-gdb" makes it spit saying that the or1k target is not supported (is it trying to compile for or1k then?) | 16:21 |
| blueCmd | not ported to gdb 7.5 I suppose, CGEN and stuff | 17:44 |
| stekern | you should only need a to have the "static" libraries compiled with -fPIC when you are linking them statically into a dynamic library | 19:08 |
| stekern | yes, we are missing a more up to date gdb, iirc peter gavin was working on something, but haven't seen anything public in that regard | 19:10 |
| stekern | the old stable toolchain (or32) has gdb | 19:10 |
| blueCmd | yes, I managed to build the old 7.2 GDB | 19:11 |
| blueCmd | it is quite buggy with qemu-user sadly | 19:11 |
| stekern | ok, we should ping peter and see if he has something laying around, even something halfbaked would be better than someone starting over from scratch | 19:12 |
| blueCmd | ah yeah | 19:12 |
| blueCmd | atm I'm figuring crt0 and crt1 out. uclibc is using crt0 and glibc crt1, which means that STARTFILE_SPEC needs to reflect if it's uclibc or glibc. | 19:12 |
| blueCmd | hacking it is no problem, but I'm a bit cautious since I can't find that any other arch have done this | 19:13 |
| stekern | I never figured that out, when crt0 vs crt1 should be used | 19:13 |
| blueCmd | and uclibc should really produce crt1.o if I understand things corretly | 19:13 |
| stekern | seems pretty common in uclibc to use crt1 as well | 19:14 |
| blueCmd | uclibc should (I read somewhere) produce crt0 if CTOR_DTOR is not used, crt1 otherwise. we use ctor_dtor afaik | 19:14 |
| blueCmd | yes, it would be very nice indeed if we could use crt1 in both libcs | 19:14 |
| blueCmd | (apparently moving crt0 to crt1 and changing Makeconfig to build crt1 seems to work, no regression testing done though) | 22:09 |
| blueCmd | stekern: would you approve of merging the patch for target based -m uclibc/glibc? | 23:53 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!