| stekern | blueCmd: I can't come up with what's wrong from the top of my head, but I suspect you're right. It's probably not the compiler, but the linker ;) | 04:41 |
|---|---|---|
| stekern | how are the different __libc_multiple_libcs defined? | 04:43 |
| juliusb | olofk: mine was a simple hack, basically just getting every C file in the gcc C torture testsuite dir and compiling and running it | 06:33 |
| juliusb | olofk: https://github.com/juliusbaxter/mor1kx-dev-env/blob/master/scripts/make/Makefile-gccregression.inc | 06:34 |
| stekern | the "right" way to do it would probably be to just make a dejagnu board desc for it | 06:49 |
| stekern | blueCmd: by my clueless grepping it looks like it has attribute_hidden, could it be related to that? | 08:04 |
| stekern | what do you get if you do or1k-linux-readelf --syms on the .os and .a? | 08:10 |
| stekern | how do you build it btw? | 08:17 |
| stekern | nm, I figured it out | 08:31 |
| stekern | .. or then not | 09:26 |
| stekern | I'm getting loads of undefined references | 09:26 |
| stekern | you can get most of dl-machine.c from https://github.com/openrisc/uClibc-or1k/blob/master/ldso/ldso/or1k/dl-sysdep.h btw | 09:49 |
| stekern | *dl-machine.h | 09:50 |
| blueCmd | stekern: ah, must have missed that one - I try to compare against uClibc every now and then | 12:22 |
| blueCmd | stekern: thanks | 12:22 |
| blueCmd | stekern: yes, I thought about that attribute as well, but I don't know how it's supposed to work. I figured that if nm said the same for both files then it would be correct | 12:23 |
| blueCmd | stekern: ah, --syms showed the visibility - paste comming right up | 12:25 |
| blueCmd | stekern: http://pastie.org/5587983 | 12:27 |
| blueCmd | the visibility looks OK, only one that has visibility DEFAULT, the others are hidden | 12:28 |
| blueCmd | stekern: as how I'm building it: https://github.com/blueCommand/or1k-devel/blob/master/Makefile | 12:35 |
| blueCmd | build the target or1k-eglibc | 12:35 |
| stekern | that's how I did it, except the --disable-profile --without-gd --without-cvs --enable-add-ons | 12:38 |
| blueCmd | profile might want to include stuff | 12:38 |
| stekern | trying again now | 12:38 |
| blueCmd | I just grabbed that line from somewhere and started working through the errors, but that should get you to libc-linking | 12:38 |
| blueCmd | thanks for taking time :) | 12:39 |
| stekern | but that's good, at least that attribute trickles down into the object | 12:39 |
| blueCmd | I compared the sections between ref and or1k | 12:40 |
| blueCmd | eh_frame is missing from the or1k but is present in ref | 12:40 |
| blueCmd | but I don't know if that is any big dea | 12:40 |
| blueCmd | deal* | 12:40 |
| stekern | could still be that we are not handling it correctly when linking the objects together | 12:40 |
| blueCmd | yes, is there a lot of arch dependent linking code? | 12:41 |
| blueCmd | or is most of it shared? | 12:41 |
| stekern | https://github.com/openrisc/or1k-src/blob/or1k/bfd/elf32-or1k.c | 12:42 |
| stekern | that's most of the arch linking stuff | 12:43 |
| stekern | "rtld.c:644: first defined here" is a bit weird, there's no __libc_multiple_libcs there, right? | 12:44 |
| blueCmd | nope - not after preprocessor either | 12:45 |
| blueCmd | IIRC | 12:45 |
| blueCmd | the thing that exports the symbol is dl-sysdep and init-first | 12:46 |
| blueCmd | or should be at least | 12:46 |
| stekern | mmm | 12:46 |
| blueCmd | I tried linking to every object that is in dl-allobjs instead of the blob and that cause it to say the same but on dl-sysdep and init-first | 12:47 |
| stekern | I'm still not getting that error | 12:53 |
| stekern | I'm getting undefined reference to _start | 12:53 |
| blueCmd | hm? you're not getting the multiple_libcs-thing? | 12:54 |
| stekern | which is natural, since it's not defined | 12:54 |
| stekern | nope | 12:54 |
| blueCmd | hm, perhaps my patches are making stuff break :P | 12:54 |
| blueCmd | in or1k-src | 12:54 |
| stekern | I'm using your trees | 12:55 |
| blueCmd | ah | 12:55 |
| stekern | or1k-src and or1k-gcc | 12:55 |
| blueCmd | yes you would have to now that I think about it | 12:55 |
| stekern | yup ;) | 12:55 |
| blueCmd | at what stage? | 12:55 |
| blueCmd | libc_pic-stage? | 12:55 |
| blueCmd | as in how far does your compilation progress before hitting this error? | 12:55 |
| * blueCmd isn't that verbose.. | 12:56 | |
| stekern | http://pastie.org/5588068 | 12:56 |
| stekern | that's what it's trying to do before it fails | 12:57 |
| blueCmd | do you have ld.so ? | 12:58 |
| stekern | no | 12:59 |
| blueCmd | I'm rebuilding everything now | 13:00 |
| blueCmd | will take some 5 min or something. | 13:00 |
| blueCmd | did you build binutils and gcc with the same flags? | 13:00 |
| blueCmd | as my makefile | 13:00 |
| blueCmd | (it should be more or less a copy from your instructions) | 13:01 |
| stekern | from what I can see, yes | 13:03 |
| blueCmd | nope, clean rebuild and still gets to that point :( | 13:06 |
| stekern | but where do you get your _start from? | 13:08 |
| blueCmd | I don't think I do | 13:09 |
| blueCmd | :P | 13:09 |
| blueCmd | so it should really fail | 13:09 |
| blueCmd | but I think you're further than me | 13:09 |
| blueCmd | i don't have rtld-libc.a | 13:10 |
| stekern | ah, ok, I thought it was the other way around, that you're further than me | 13:13 |
| stekern | you can have mine rtld-libc.a if you want, I don't need it ;) | 13:14 |
| blueCmd | haha | 13:14 |
| blueCmd | unfair! ;) | 13:14 |
| blueCmd | argh! what can this be? | 13:14 |
| blueCmd | are you sure you're using my compiler and my linker etc? | 13:14 |
| blueCmd | no PATH mixup or anything like that? | 13:14 |
| stekern | it shouldn't build at all if I weren't | 13:15 |
| stekern | but I'm using it built as stage 2 | 13:15 |
| blueCmd | ah | 13:16 |
| blueCmd | maybe that is something? | 13:16 |
| blueCmd | I will try to build uclibc and gcc and see what happens | 13:16 |
| stekern | perhaps, but it seems odd, surely the boot gcc should be able to build eglibc | 13:17 |
| blueCmd | yes | 13:17 |
| blueCmd | it should | 13:17 |
| blueCmd | but maybe there is a bug which fixes itself | 13:17 |
| blueCmd | or hides | 13:17 |
| stekern | otoh, we're not exactly using a production ready setup here ;) | 13:17 |
| blueCmd | I noticed that the bootstrapped x86_64 uses both GNU STACK and EH_FRAMES on the .os things, and I know stage 2 with uclibc does this | 13:18 |
| blueCmd | but not stage 1 or1k | 13:18 |
| blueCmd | hehe, no we're not :) | 13:18 |
| blueCmd | stekern: hah, I wonder if this will produce glibc binaries dependent on uclibc | 13:24 |
| blueCmd | that would be a looker | 13:24 |
| stekern | :) | 13:26 |
| blueCmd | stekern: works | 13:26 |
| stekern | it _shouldn't_ pull in anything from uclibc with the -nostdlib | 13:27 |
| blueCmd | yeah I know. but now I get to the same place as you | 13:27 |
| stekern | ok, at least that makes sense | 13:29 |
| stekern | maybe we are missing something that is needed in the stage 1 gcc config | 13:30 |
| blueCmd | well the sections don't differ what I can see so my .eh_frame gnu stack idea won't hold | 13:30 |
| blueCmd | possibly | 13:30 |
| blueCmd | built my reference x86-64 with the same flags though | 13:30 |
| stekern | true... | 13:30 |
| blueCmd | well except --disable-decimal-float | 13:31 |
| blueCmd | but i'll be damned if that is the reason :) | 13:31 |
| stekern | sounds unlikely | 13:32 |
| blueCmd | oh well, I'll just continue with a stage two gcc for now and add this to my todo | 13:32 |
| stekern | would have been interesting to see that thing that failed with -v option | 13:33 |
| stekern | on the gcc stage 1 compared to stage 2 | 13:33 |
| blueCmd | I can get that to you if you want to | 13:33 |
| blueCmd | my uber computer build these things in no time, no problem ;) | 13:33 |
| blueCmd | (i remember building these things on P3 and P4 CPUs.. took a tad bit longer) | 13:34 |
| blueCmd | http://pastie.org/5588163 the working one | 13:35 |
| blueCmd | http://pastie.org/5588169 the broken one | 13:38 |
| stekern | I remember builing the kernel on a p1 90 MHz ;) | 13:38 |
| blueCmd | :D | 13:38 |
| blueCmd | built openssh on one of those, but never the kernel | 13:38 |
| stekern | interesting, the sysroot paths are -L'ed even if -nostdlb is given | 13:39 |
| blueCmd | yes, seems to me that those are the only differences as well | 13:41 |
| stekern | what happens if you manually run that command line with the stage 1 gcc? | 13:41 |
| blueCmd | 2 sec | 13:44 |
| * blueCmd borrowed stekern's _start | 13:47 | |
| blueCmd | stekern: nope, running collect doesn't work - same issue | 13:51 |
| blueCmd | I will strace and see how ld is invoked | 13:51 |
| blueCmd | http://pastie.org/5588223 broken one | 13:53 |
| stekern | borrowed, as in? https://github.com/openrisc/uClibc-or1k/blob/master/libc/sysdeps/linux/or1k/crt0.S | 13:54 |
| blueCmd | not that one, I used your _start in dl-machines rtld code | 13:54 |
| blueCmd | I will cred you for it, don't worry ;) | 13:54 |
| stekern | ah, that one, right | 13:56 |
| stekern | no worries, I stole most of it from microblaze anyways ;) | 13:56 |
| blueCmd | ld is invoked in the same way when it's working | 13:58 |
| blueCmd | the only difference is that the folders it wants to look in are actually there (i cleaned when building my stage 1, didn't think about it) | 13:58 |
| blueCmd | strace-ing file accesses shows that it doesn't use anything from sys-root though | 14:00 |
| stekern | yeah, I wouldn't expect it to | 14:00 |
| blueCmd | it does like to /srv/compilers/openrisc-devel/lib/gcc/or1k-linux/4.8.0/libgcc.a | 14:00 |
| blueCmd | which could be different | 14:01 |
| blueCmd | or most likely is | 14:01 |
| stekern | can't imagine that that would have anything to do with the problem though | 14:03 |
| blueCmd | that's the only difference I can spot :S | 14:03 |
| blueCmd | http://pastie.org/5588277 output of strace | 14:05 |
| blueCmd | there are some more accesses link unlinking and stuff like that before ld exiting 1, but nothing I would say that it is the cause - only effect | 14:06 |
| blueCmd | bbi 15 | 14:06 |
| blueCmd | stekern: it is libgcc.a (http://pastie.org/5588363) | 14:20 |
| blueCmd | now breakfast! | 14:20 |
| stekern | hmm, odd, wonder what's (or not) in that stage 1 libgcc | 14:23 |
| stekern | I tried with https://github.com/skristiansson/compiler-rt-or1k as libgcc.a | 14:23 |
| stekern | and that worked | 14:24 |
| blueCmd | hm | 14:36 |
| blueCmd | "Build stage1 glibc using the stage1 gcc compiler; this uses the binutils from (1) and the stage1 gcc from (2). This version of glibc is built with only static libraries and without any of the helper programs of glibc, because the stage1 gcc cannot build shared libraries or executables." | 14:36 |
| blueCmd | when I read that I seem to recall from The Good Old Days that one did something like that | 14:37 |
| stekern | hmm, yeah, but isn't that what we are kind of trying to do? | 14:40 |
| blueCmd | I suppose, but I'm not using --disable-shared | 14:40 |
| blueCmd | yes, with --disable-shared I think I get further with stage1 | 14:41 |
| blueCmd | but I really think it should be possible to just one run | 14:43 |
| blueCmd | seems like such a small thing to justify multi-staged glibc | 14:44 |
| blueCmd | *sigh* bin/ld: cannot find -lgcc_eh | 14:50 |
| blueCmd | apparently needs two stage for static aswell | 14:50 |
| stekern | what does a diff between or1k-linux-objdump -rd libgcc_stage1.a and libgcc_stage2.a tell us? | 14:51 |
| blueCmd | loads :P | 14:51 |
| stekern | still don't get how something in there can generate that error though... | 14:52 |
| blueCmd | seems weird to me aswell, if the linker doesn't somehow use it as a link script or something | 14:52 |
| blueCmd | weird | 14:53 |
| blueCmd | in stage2 you have less stuff | 14:53 |
| blueCmd | you lack emutls.o, unwind-c.o and nwind-sjlj.o: | 14:53 |
| blueCmd | unwind-sjlj.o * | 14:53 |
| blueCmd | err, and unwind-dw2-fde-dip.o, unwind-dw2.o: | 14:54 |
| blueCmd | the only thing new is _eprintf, GLOBAL_OFFSET_TABLE, and stuff like that | 14:56 |
| stekern | yeah, I think they are somewhere else there | 14:56 |
| blueCmd | we probably want to add get_thread_pointer to gcc/config/or1k/or1k.md | 15:44 |
| blueCmd | new thing in 4.8.0, it would be nice to use it in glibc (more things common with other archs) | 15:45 |
| stekern | what does it do? | 16:43 |
| stekern | linux is using r10 for some thread pointer, but can't say I have a full understanding of what it's for | 16:45 |
| blueCmd | aha, we don't have any support for thread local storage in gcc yet, do we? | 16:55 |
| blueCmd | ah | 16:55 |
| blueCmd | right | 16:55 |
| blueCmd | sorry | 16:55 |
| blueCmd | I didn't scroll down on IRC | 16:55 |
| blueCmd | if we use r10 for thread pointer that would probably be a good start | 16:56 |
| blueCmd | apparently TLS (thread local storage) is used for having thread local, well, storage :P | 16:56 |
| blueCmd | as opposed to thread sharing the same memory as it is by default | 16:56 |
| blueCmd | stekern: or do you mean in the kernel? | 16:58 |
| stekern | in the kernel, yes | 16:59 |
| blueCmd | I see. | 16:59 |
| stekern | mmm, we don't support tls (yet) | 17:00 |
| blueCmd | arm uses a syscall they call set_tls, a quick search in unistd.h said we don't have it so we probably want to do something like that | 17:00 |
| stekern | that's why we need those emu_tls stuff (afaik) | 17:00 |
| blueCmd | well then, implement TLS - how hard could that be? sounds like fun ;) | 17:02 |
| blueCmd | i tried adding support for get_thread_pointer in gcc by looking at aarch64 and arm, but I can't make heads or tails from the syntax | 17:06 |
| blueCmd | hah, eglibc successfully built with the three TLS things defined as NULL :P | 17:11 |
| stekern | nice ;) | 17:51 |
| blueCmd | making progress, got eglibc to compile staticily and install, trying to build gcc stage2 against that to build eglibc dynamic | 18:01 |
| blueCmd | /srv/compilers/openrisc-devel/or1k-linux/bin/ld: BFD (GNU Binutils) 2.23.51.20121129 assertion fail ../../or1k-src/bfd/elf32-or1k.c:892 | 18:01 |
| blueCmd | /srv/compilers/openrisc-devel/or1k-linux/bin/ld: /srv/compilers/openrisc-devel/or1k-linux/sys-root/usr/lib/libc.a(findlocale.o): probably compiled without -fPIC? | 18:01 |
| blueCmd | /srv/compilers/openrisc-devel/or1k-linux/bin/ld: final link failed: Bad value | 18:01 |
| blueCmd | time for beer, good days work :) | 18:02 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!