IRC logs for #openrisc Friday, 2012-12-28

stekernblueCmd: 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
stekernhow are the different __libc_multiple_libcs defined?04:43
juliusbolofk: mine was a simple hack, basically just getting every C file in the gcc C torture testsuite dir and compiling and running it06:33
stekernthe "right" way to do it would probably be to just make a dejagnu board desc for it06:49
stekernblueCmd: by my clueless grepping it looks like it has attribute_hidden, could it be related to that?08:04
stekernwhat do you get if you do or1k-linux-readelf --syms on the .os and .a?08:10
stekernhow do you build it btw?08:17
stekernnm, I figured it out08:31
stekern.. or then not09:26
stekernI'm getting loads of undefined references09:26
stekernyou can get most of dl-machine.c from btw09:49
blueCmdstekern: ah, must have missed that one - I try to compare against uClibc every now and then12:22
blueCmdstekern: thanks12:22
blueCmdstekern: 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 correct12:23
blueCmdstekern: ah, --syms showed the visibility - paste comming right up12:25
blueCmdthe visibility looks OK, only one that has visibility DEFAULT, the others are hidden12:28
blueCmdstekern: as how I'm building it:
blueCmdbuild the target or1k-eglibc12:35
stekernthat's how I did it, except the --disable-profile --without-gd --without-cvs --enable-add-ons12:38
blueCmdprofile might want to include stuff12:38
stekerntrying again now12:38
blueCmdI just grabbed that line from somewhere and started working through the errors, but that should get you to libc-linking12:38
blueCmdthanks for taking time :)12:39
stekernbut that's good, at least that attribute trickles down into the object12:39
blueCmdI compared the sections between ref and or1k12:40
blueCmdeh_frame is missing from the or1k but is present in ref12:40
blueCmdbut I don't know if that is any big dea12:40
stekerncould still be that we are not handling it correctly when linking the objects together12:40
blueCmdyes, is there a lot of arch dependent linking code?12:41
blueCmdor is most of it shared?12:41
stekernthat's most of the arch linking stuff12:43
stekern"rtld.c:644: first defined here" is a bit weird, there's no __libc_multiple_libcs there, right?12:44
blueCmdnope - not after preprocessor either12:45
blueCmdthe thing that exports the symbol is dl-sysdep and init-first12:46
blueCmdor should be at least12:46
blueCmdI 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-first12:47
stekernI'm still not getting that error12:53
stekernI'm getting undefined reference to _start12:53
blueCmdhm? you're not getting the multiple_libcs-thing?12:54
stekernwhich is natural, since it's not defined12:54
blueCmdhm, perhaps my patches are making stuff break :P12:54
blueCmdin or1k-src12:54
stekernI'm using your trees12:55
stekernor1k-src and or1k-gcc12:55
blueCmdyes you would have to now that I think about it12:55
stekernyup ;)12:55
blueCmdat what stage?12:55
blueCmdas in how far does your compilation progress before hitting this error?12:55
* blueCmd isn't that verbose..12:56
stekernthat's what it's trying to do before it fails12:57
blueCmddo you have ?12:58
blueCmdI'm rebuilding everything now13:00
blueCmdwill take some 5 min or something.13:00
blueCmddid you build binutils and gcc with the same flags?13:00
blueCmdas my makefile13:00
blueCmd(it should be more or less a copy from your instructions)13:01
stekernfrom what I can see, yes13:03
blueCmdnope, clean rebuild and still gets to that point :(13:06
stekernbut where do you get your _start from?13:08
blueCmdI don't think I do13:09
blueCmdso it should really fail13:09
blueCmdbut I think you're further than me13:09
blueCmdi don't have rtld-libc.a13:10
stekernah, ok, I thought it was the other way around, that you're further than me13:13
stekernyou can have mine rtld-libc.a if you want, I don't need it ;)13:14
blueCmdunfair! ;)13:14
blueCmdargh! what can this be?13:14
blueCmdare you sure you're using my compiler and my linker etc?13:14
blueCmdno PATH mixup or anything like that?13:14
stekernit shouldn't build at all if I weren't13:15
stekernbut I'm using it built as stage 213:15
blueCmdmaybe that is something?13:16
blueCmdI will try to build uclibc and gcc and see what happens13:16
stekernperhaps, but it seems odd, surely the boot gcc should be able to build eglibc13:17
blueCmdit should13:17
blueCmdbut maybe there is a bug which fixes itself13:17
blueCmdor hides13:17
stekernotoh, we're not exactly using a production ready setup here ;)13:17
blueCmdI 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 this13:18
blueCmdbut not stage 1 or1k13:18
blueCmdhehe, no we're not :)13:18
blueCmdstekern: hah, I wonder if this will produce glibc binaries dependent on uclibc13:24
blueCmdthat would be a looker13:24
blueCmdstekern: works13:26
stekernit _shouldn't_ pull in anything from uclibc with the -nostdlib13:27
blueCmdyeah I know. but now I get to the same place as you13:27
stekernok, at least that makes sense13:29
stekernmaybe we are missing something that is needed in the stage 1 gcc config13:30
blueCmdwell the sections don't differ what I can see so my .eh_frame gnu stack idea won't hold13:30
blueCmdbuilt my reference x86-64 with the same flags though13:30
blueCmdwell except  --disable-decimal-float13:31
blueCmdbut i'll be damned if that is the reason :)13:31
stekernsounds unlikely13:32
blueCmdoh well, I'll just continue with a stage two gcc for now and add this to my todo13:32
stekernwould have been interesting to see that thing that failed with -v option13:33
stekernon the gcc stage 1 compared to stage 213:33
blueCmdI can get that to you if you want to13:33
blueCmdmy 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 the working one13:35
blueCmd the broken one13:38
stekernI remember builing the kernel on a p1 90 MHz ;)13:38
blueCmdbuilt openssh on one of those, but never the kernel13:38
stekerninteresting, the sysroot paths are -L'ed even if -nostdlb is given13:39
blueCmdyes, seems to me that those are the only differences as well13:41
stekernwhat happens if you manually run that command line with the stage 1 gcc?13:41
blueCmd2 sec13:44
* blueCmd borrowed stekern's _start13:47
blueCmdstekern: nope, running collect doesn't work - same issue13:51
blueCmdI will strace and see how ld is invoked13:51
blueCmd broken one13:53
stekernborrowed, as in?
blueCmdnot that one, I used your _start in dl-machines rtld code13:54
blueCmdI will cred you for it, don't worry ;)13:54
stekernah, that one, right13:56
stekernno worries, I stole most of it from microblaze anyways ;)13:56
blueCmdld is invoked in the same way when it's working13:58
blueCmdthe 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
blueCmdstrace-ing file accesses shows that it doesn't use anything from sys-root though14:00
stekernyeah, I wouldn't expect it to14:00
blueCmdit does like to /srv/compilers/openrisc-devel/lib/gcc/or1k-linux/4.8.0/libgcc.a14:00
blueCmdwhich could be different14:01
blueCmdor most likely is14:01
stekerncan't imagine that that would have anything to do with the problem though14:03
blueCmdthat's the only difference I can spot :S14:03
blueCmd output of strace14:05
blueCmdthere 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 effect14:06
blueCmdbbi 1514:06
blueCmdstekern: it is libgcc.a (
blueCmdnow breakfast!14:20
stekernhmm, odd, wonder what's (or not) in that stage 1 libgcc14:23
stekernI tried with as libgcc.a14:23
stekernand that worked14:24
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
blueCmdwhen I read that I seem to recall from The Good Old Days that one did something like that14:37
stekernhmm, yeah, but isn't that what we are kind of trying to do?14:40
blueCmdI suppose, but I'm not using --disable-shared14:40
blueCmdyes, with --disable-shared I think I get further with stage114:41
blueCmdbut I really think it should be possible to just one run14:43
blueCmdseems like such a small thing to justify multi-staged glibc14:44
blueCmd*sigh* bin/ld: cannot find -lgcc_eh14:50
blueCmdapparently needs two stage for static aswell14:50
stekernwhat does a diff between or1k-linux-objdump -rd libgcc_stage1.a and libgcc_stage2.a tell us?14:51
blueCmdloads :P14:51
stekernstill don't get how something in there can generate that error though...14:52
blueCmdseems weird to me aswell, if the linker doesn't somehow use it as a link script or something14:52
blueCmdin stage2 you have less stuff14:53
blueCmdyou lack emutls.o, unwind-c.o and nwind-sjlj.o:14:53
blueCmdunwind-sjlj.o *14:53
blueCmderr, and unwind-dw2-fde-dip.o, unwind-dw2.o:14:54
blueCmdthe only thing new is _eprintf, GLOBAL_OFFSET_TABLE, and stuff like that14:56
stekernyeah, I think they are somewhere else there14:56
blueCmdwe probably want to add get_thread_pointer to gcc/config/or1k/or1k.md15:44
blueCmdnew thing in 4.8.0, it would be nice to use it in glibc (more things common with other archs)15:45
stekernwhat does it do?16:43
stekernlinux is using r10 for some thread pointer, but can't say I have a full understanding of what it's for16:45
blueCmdaha, we don't have any support for thread local storage in gcc yet, do we?16:55
blueCmdI didn't scroll down on IRC16:55
blueCmdif we use r10 for thread pointer that would probably be a good start16:56
blueCmdapparently TLS (thread local storage) is used for having thread local, well, storage :P16:56
blueCmdas opposed to thread sharing the same memory as it is by default16:56
blueCmdstekern: or do you mean in the kernel?16:58
stekernin the kernel, yes16:59
blueCmdI see.16:59
stekernmmm, we don't support tls (yet)17:00
blueCmdarm 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 that17:00
stekernthat's why we need those emu_tls stuff (afaik)17:00
blueCmdwell then, implement TLS - how hard could that be? sounds like fun ;)17:02
blueCmdi 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 syntax17:06
blueCmdhah, eglibc successfully built with the three TLS things defined as NULL :P17:11
stekernnice ;)17:51
blueCmdmaking progress, got eglibc to compile staticily and install, trying to build gcc stage2 against that to build eglibc dynamic18:01
blueCmd/srv/compilers/openrisc-devel/or1k-linux/bin/ld: BFD (GNU Binutils) assertion fail ../../or1k-src/bfd/elf32-or1k.c:89218: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 value18:01
blueCmdtime for beer, good days work :)18:02

Generated by 2.15.2 by Marius Gedminas - find it at!