IRC logs for #openrisc Tuesday, 2013-07-09

--- Log opened Tue Jul 09 00:00:19 2013
poke53282after a few hours If have nailed down the problem of compiling directfb. The gcc attribute  __attribute__((constructor))   does not work for shared libraries.00:37
poke53282sorry, the problem is not compiling but running.00:37
poke53282I am not sure whether the problem is in uClibc or gcc or a combination of both.00:38
poke53282I have summarized it01:49
poke53282with gcc I mean or1k-linux-gcc of course01:50
stekernpoke53282: excellent work pinning that down02:17
stekernI promise I'll take a closer look at it, if no-one beats me to it02:18
stekern...hopefully sooner than what it took me last I promised you to look at something =P02:19
stekernoh, I found one bitbanged read that's not 0x1102:37
stekernand it's 0x1002:38
stekernso bit 0 is obviously still TDO, but bit4 is still an unknown02:38
stekern(bit 0 matches the corresponding meassage in ub1 communication)02:39
stekernthis is perhaps more lightweight to experiment with than openocd:
poke53282stekern: would be nice if this problem would be solved.04:20
poke53282At the moment I am a little bit stucked. X works but it crashes04:20
poke53282very very often. And I think this problem is reason.04:20
stekernpoke53282: ok04:23
stekernat least we have a nice trimmed down test case thanks to you now, just a matter of figuring out what makes that go boom04:24
stekerngetting to the point of a trimmed down test case is usually the hard part04:24
stekernperhaps it's in the uclibc lib loader, gut feel tells me that would be the one responsible for running the Init code04:28
stekernpoke53282: umm, running that test case on x86_64 gives the same result04:33
stekernahh, I know why, nothing is used in the dynamic lib, so it's not loaded04:52
stekerndoes that fail on or1k too?04:52
poke53282On my x86-64 system I get ping pong for the shared case.  I will try it again. and then on or1k.05:35
poke53282Ok, on my x86-x64 system I get always a Ping for my and your version. It is executed everytime.05:40
poke53282on or1k definitely no Ping. I get "Pong from Lib\n Pong from Main\n" No Ping06:01
stekernok, I'll continue digging then06:05
poke53282"Support global constructors and destructors" are activated in uClibc menuconfig.06:06
poke53282I have tried or1k-linux-gcc and native gcc.06:08
poke53282Maybe you can check it in your build environment.06:10
stekernyeah, I will06:19
stekernjust comparing the gcc outputs right now to spot differences06:21
stekerngreping through uclibc, the support for DT_INIT looked generic enough (if I looked at the right place)06:22
stekernactually, it should probably be ran by __do_global_ctors_aux... I think06:26
stekerndo we get a Ping from this?
stekernI don't have a or1ksim around atm, I'll check myself if you're not up to it :)06:47
poke53282Pong from lib07:02
poke53282Pong from main07:02
poke53282or1k: The same. This seems to work.07:06
stekernok, the only difference that I can spot with a quick glance is that the constructor ends up in the __CTOR_LIST__ of the executable (pong) instead of libping.so07:09
poke53282I am not sure if g++ uses the same technique for this type of execution.07:09
stekernlet's try this then:
stekern(the difference is that now "ping" is declared in libping)07:10
poke53282Ok, understood07:10
poke53282x86_64: Ping, Pong from lib, Pong from main07:13
poke53282or1k: no Ping07:18
stekernok, so ctors inside shared libs is somewhat borken...07:19
poke53282Ok, this is really a problem right now.07:19
poke53282Almost no real big c++ application should work07:19
stekernI think I'll put my jtag hacking aside for a while and spend some on this now then ;)07:22
poke53282Hehe, you can try to do both. Reduce sleeping time. By the way. Have to sleep now. It is late.07:23
stekernunfortunately, I use the "Reduce sleeping time" hack already ;)07:24
stekernanyways, good night07:24
-!- Netsplit *.net <-> *.split quits: simoncook09:05
-!- Netsplit *.net <-> *.split quits: jonmasters, heroux, Guest45696, Logxen, Amadiro, hle_, blueCmd, LoneTech, olofk, jakob_, (+7 more, use /NETSPLIT to show all of them)09:11
-!- Netsplit over, joins: simoncook, O01eg, heroux, jakob_, forkG_, enghong, hno, LoneTech, Guest45696, olofk (+8 more)09:14
stekernlooks like we are not inserting DT_INIT at all...09:46
stekern... and I know why09:49
stekernour _init in uclibc is called __init for some reason09:50
stekernand binutils inserts DT_INIT on functions named _init09:50
stekernwhere's jeremy?09:50
stekernno, I think I'm off track here...10:13
stekernthose are not used10:13
stekernthe ones from gcc are10:13
stekern__init and __fini that is10:13
stekernso, that's the ones that need to change10:16
stekernmost archs seems to use _init and _fini10:36
stekernor1k, microblaze and bfin + some others are the ones sticking out with __init10:37
stekernwonder how those other "odd" archs handles this10:46
stekernI don't want to change __init if not absolutely necessary10:47
stekernerr.. my prebuilt microblaze toolchain add an _init...10:54
stekernah, when building the stage 2 gcc, crti and crtn is not installed from libgcc11:40
stekernI guess when building stage 1 they are11:41
stekernand they of course stay there when the stage 2 is built, so they are used instead of the uclibc crti and crtn11:42
stekernpoke53282: FWIW renaming __init to _init makes things go 'Ping'11:42
stekernnot sure how this should be fixed properly...11:43
poke53282Thanks stekern16:40
poke53282Crazy stuff this linking process.16:43
poke53282crti.S looks the same for gcc and uClibc instead of an odd l.nop16:54
poke53282Ok, found the code you meant.17:08
poke53282Ok, compiling the last stage of the toolchain. Then I will test.17:15
stekernpoke53282: yeah, I know... that's why I'm not sure if we really need to change the gcc crti.S17:15
stekernbut it'd be good to be consistent I think17:16
stekernanother option would be to set link_info.init_function to "__init", but no-one else seems to be doing that17:18
stekernI'm thinking if renaming would cause incompatibility between different programs/libs built with different gcc/uclibc, but I don't think it actually does17:20
stekernit's only referenced from the program/lib itself from what I can think of17:22
poke53282Yes it is something used only inside a program lib. No external program should directly link to these functions.17:24
poke53282So if it works fine. Anyway I will test this change with the big programs out there.17:25
poke53282I am wondering why the testsuites didn't find this error. They don't test shared libraries?17:29
stekernI'm not sure, there are still a couple of fails when running the testsuite, maybe some are caused by this17:32
stekernI think I'm leaning towards the full __init/__fini => _init/_fini name changes, I'll prepare a "project wide" patch and send to the mailing lists and see if someone screams about it ;)17:35
poke53282Every big architecture seems to do it this way.17:40
poke53282You can also wait until I have checked it at least for one program.17:42
stekernyeah, I will not have time to prepare them tonight anyway, tomorrow maybe17:42
stekernI need to send that native gcc bugfix to gcc-patches too, better do that now when I'm context switched to toolchain ;)17:44
stekernit quickly bitrots, I had to update it now even though it was only about a month ago I made it17:44
stekernthat's why I pushed it to a seperate branch, to keep it seperated when syncing with upstream17:46
poke53282I understand.18:00
poke53282Did you change both crti.S files in uClibc and gcc?18:25
poke53282I have changed both and now the stage2 gcc compilation does not work.18:27
poke53282Ahh, found an error. Have to redo everything18:31
poke53282works :)18:45
poke53282DirectFB does not crash anymore.18:52
stekernpoke53282: great! and thanks for reporting back (and also doing the grunt work finding the bug)20:50
poke53282You are welcome. And Thanks for correcting the bug.21:10
poke53282But my X Server still crashes. :(21:12
poke53282But maybe it is better to start from scratch compiling everything21:13
--- Log closed Wed Jul 10 00:00:20 2013

Generated by 2.15.2 by Marius Gedminas - find it at!