| --- Log opened Tue Jul 09 00:00:19 2013 | ||
| poke53282 | after 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 |
|---|---|---|
| poke53282 | sorry, the problem is not compiling but running. | 00:37 |
| poke53282 | I am not sure whether the problem is in uClibc or gcc or a combination of both. | 00:38 |
| poke53282 | http://pastie.org/8123014 | 01:49 |
| poke53282 | I have summarized it | 01:49 |
| poke53282 | with gcc I mean or1k-linux-gcc of course | 01:50 |
| stekern | poke53282: excellent work pinning that down | 02:17 |
| stekern | I promise I'll take a closer look at it, if no-one beats me to it | 02:18 |
| stekern | ...hopefully sooner than what it took me last I promised you to look at something =P | 02:19 |
| stekern | oh, I found one bitbanged read that's not 0x11 | 02:37 |
| stekern | and it's 0x10 | 02:38 |
| stekern | so bit 0 is obviously still TDO, but bit4 is still an unknown | 02:38 |
| stekern | (bit 0 matches the corresponding meassage in ub1 communication) | 02:39 |
| stekern | this is perhaps more lightweight to experiment with than openocd: https://github.com/swetland/jtag | 03:09 |
| poke53282 | stekern: would be nice if this problem would be solved. | 04:20 |
| poke53282 | At the moment I am a little bit stucked. X works but it crashes | 04:20 |
| poke53282 | very very often. And I think this problem is reason. | 04:20 |
| stekern | poke53282: ok | 04:23 |
| stekern | at least we have a nice trimmed down test case thanks to you now, just a matter of figuring out what makes that go boom | 04:24 |
| stekern | getting to the point of a trimmed down test case is usually the hard part | 04:24 |
| stekern | perhaps it's in the uclibc lib loader, gut feel tells me that would be the one responsible for running the Init code | 04:28 |
| stekern | poke53282: umm, running that test case on x86_64 gives the same result | 04:33 |
| stekern | ahh, I know why, nothing is used in the dynamic lib, so it's not loaded | 04:52 |
| stekern | http://pastie.org/8123391 | 04:52 |
| stekern | does that fail on or1k too? | 04:52 |
| poke53282 | On my x86-64 system I get ping pong for the shared case. I will try it again. and then on or1k. | 05:35 |
| poke53282 | Ok, on my x86-x64 system I get always a Ping for my and your version. It is executed everytime. | 05:40 |
| poke53282 | on or1k definitely no Ping. I get "Pong from Lib\n Pong from Main\n" No Ping | 06:01 |
| stekern | ok, I'll continue digging then | 06:05 |
| poke53282 | "Support global constructors and destructors" are activated in uClibc menuconfig. | 06:06 |
| poke53282 | I have tried or1k-linux-gcc and native gcc. | 06:08 |
| poke53282 | Maybe you can check it in your build environment. | 06:10 |
| stekern | yeah, I will | 06:19 |
| stekern | just comparing the gcc outputs right now to spot differences | 06:21 |
| stekern | greping through uclibc, the support for DT_INIT looked generic enough (if I looked at the right place) | 06:22 |
| stekern | actually, it should probably be ran by __do_global_ctors_aux... I think | 06:26 |
| stekern | do we get a Ping from this? http://pastie.org/8123574 | 06:46 |
| stekern | I don't have a or1ksim around atm, I'll check myself if you're not up to it :) | 06:47 |
| poke53282 | x86_64:Ping | 07:02 |
| poke53282 | Pong from lib | 07:02 |
| poke53282 | Pong from main | 07:02 |
| poke53282 | or1k: The same. This seems to work. | 07:06 |
| stekern | ok, 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.so | 07:09 |
| poke53282 | I am not sure if g++ uses the same technique for this type of execution. | 07:09 |
| stekern | let's try this then: http://pastie.org/8123635 | 07:09 |
| stekern | (the difference is that now "ping" is declared in libping) | 07:10 |
| poke53282 | Ok, understood | 07:10 |
| poke53282 | x86_64: Ping, Pong from lib, Pong from main | 07:13 |
| poke53282 | or1k: no Ping | 07:18 |
| stekern | ok, so ctors inside shared libs is somewhat borken... | 07:19 |
| poke53282 | Ok, this is really a problem right now. | 07:19 |
| poke53282 | Almost no real big c++ application should work | 07:19 |
| stekern | right | 07:19 |
| stekern | I think I'll put my jtag hacking aside for a while and spend some on this now then ;) | 07:22 |
| stekern | +time | 07:22 |
| poke53282 | Hehe, you can try to do both. Reduce sleeping time. By the way. Have to sleep now. It is late. | 07:23 |
| stekern | unfortunately, I use the "Reduce sleeping time" hack already ;) | 07:24 |
| stekern | anyways, good night | 07:24 |
| poke53282 | thanks | 07:25 |
| -!- Netsplit *.net <-> *.split quits: simoncook | 09: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 | |
| stekern | looks like we are not inserting DT_INIT at all... | 09:46 |
| stekern | ... and I know why | 09:49 |
| stekern | our _init in uclibc is called __init for some reason | 09:50 |
| stekern | and binutils inserts DT_INIT on functions named _init | 09:50 |
| stekern | where's jeremy? | 09:50 |
| stekern | no, I think I'm off track here... | 10:13 |
| stekern | those are not used | 10:13 |
| stekern | the ones from gcc are | 10:13 |
| stekern | __init and __fini that is | 10:13 |
| stekern | so, that's the ones that need to change | 10:16 |
| stekern | most archs seems to use _init and _fini | 10:36 |
| stekern | or1k, microblaze and bfin + some others are the ones sticking out with __init | 10:37 |
| stekern | wonder how those other "odd" archs handles this | 10:46 |
| stekern | I don't want to change __init if not absolutely necessary | 10:47 |
| stekern | err.. my prebuilt microblaze toolchain add an _init... | 10:54 |
| stekern | ah, when building the stage 2 gcc, crti and crtn is not installed from libgcc | 11:40 |
| stekern | I guess when building stage 1 they are | 11:41 |
| stekern | and they of course stay there when the stage 2 is built, so they are used instead of the uclibc crti and crtn | 11:42 |
| stekern | poke53282: FWIW renaming __init to _init makes things go 'Ping' | 11:42 |
| stekern | not sure how this should be fixed properly... | 11:43 |
| poke53282 | Thanks stekern | 16:40 |
| poke53282 | Crazy stuff this linking process. | 16:43 |
| poke53282 | crti.S looks the same for gcc and uClibc instead of an odd l.nop | 16:54 |
| poke53282 | Ok, found the code you meant. | 17:08 |
| poke53282 | Ok, compiling the last stage of the toolchain. Then I will test. | 17:15 |
| stekern | poke53282: yeah, I know... that's why I'm not sure if we really need to change the gcc crti.S | 17:15 |
| stekern | but it'd be good to be consistent I think | 17:16 |
| stekern | another option would be to set link_info.init_function to "__init", but no-one else seems to be doing that | 17:18 |
| stekern | I'm thinking if renaming would cause incompatibility between different programs/libs built with different gcc/uclibc, but I don't think it actually does | 17:20 |
| stekern | it's only referenced from the program/lib itself from what I can think of | 17:22 |
| poke53282 | Yes it is something used only inside a program lib. No external program should directly link to these functions. | 17:24 |
| poke53282 | So if it works fine. Anyway I will test this change with the big programs out there. | 17:25 |
| poke53282 | I am wondering why the testsuites didn't find this error. They don't test shared libraries? | 17:29 |
| stekern | I'm not sure, there are still a couple of fails when running the testsuite, maybe some are caused by this | 17:32 |
| stekern | I 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 |
| poke53282 | Every big architecture seems to do it this way. | 17:40 |
| poke53282 | You can also wait until I have checked it at least for one program. | 17:42 |
| stekern | yeah, I will not have time to prepare them tonight anyway, tomorrow maybe | 17:42 |
| stekern | I need to send that native gcc bugfix to gcc-patches too, better do that now when I'm context switched to toolchain ;) | 17:44 |
| stekern | it quickly bitrots, I had to update it now even though it was only about a month ago I made it | 17:44 |
| stekern | that's why I pushed it to a seperate branch, to keep it seperated when syncing with upstream | 17:46 |
| poke53282 | I understand. | 18:00 |
| poke53282 | Did you change both crti.S files in uClibc and gcc? | 18:25 |
| poke53282 | I have changed both and now the stage2 gcc compilation does not work. | 18:27 |
| poke53282 | Ahh, found an error. Have to redo everything | 18:31 |
| poke53282 | works :) | 18:45 |
| poke53282 | DirectFB does not crash anymore. | 18:52 |
| stekern | poke53282: great! and thanks for reporting back (and also doing the grunt work finding the bug) | 20:50 |
| poke53282 | You are welcome. And Thanks for correcting the bug. | 21:10 |
| poke53282 | But my X Server still crashes. :( | 21:12 |
| poke53282 | But maybe it is better to start from scratch compiling everything | 21:13 |
| --- Log closed Wed Jul 10 00:00:20 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!