| --- Log opened Fri Jul 12 00:00:23 2013 | ||
| stekern | poke53281: certainly, let me just refresh my own memory first. but you're timing is excellent, I was just about to run the testsuite myself to test this 4.8.1 gcc I just built | 02:19 |
|---|---|---|
| stekern | first you need this: https://github.com/openrisc/or1k-dejagnu | 02:20 |
| stekern | then you need a .exp file for the linux toolchain, here is the one I am using, it's a slightly modified version of jeremybennetts version that is somewhere in svn | 02:31 |
| stekern | http://oompa.chokladfabriken.org/tmp/or1k-linux-uclibc-sim.exp | 02:31 |
| stekern | (yes, I know, I should put that in the or1k-dejagnu repo :/) | 02:32 |
| stekern | put that file to the place where or1k-dejagnu was installed (/usr/local/share/dejagnu/baseboards on my machine) | 02:33 |
| stekern | then you need an or1k linux machine running with telnet and ftp enabled | 02:36 |
| stekern | and then in the build dir of gcc, run: make check RUNTESTFLAGS="--target_board=or1k-linux-uclibc-sim --target_triplet=or1k-unknown-linux-gnu" OR1K_IP="192.168.255.122" | 02:39 |
| stekern | with OR1K_IP substituted with the ip of your or1k machine | 02:40 |
| stekern | the results/logs will then be produced in gcc/testsuite/ | 02:45 |
| stekern | oh, I almost forgot, you need to edit the or1k-linux-uclibc-sim.exp to set the path to your gcc and g++ too | 02:49 |
| poke53282 | Ok, thanks. I will try it when I have time. | 03:40 |
| poke53282 | I have also send a mail to the mailing with some disturbing behavior of DirectFB which makes it almost impossible to compile correctly on openrisc. It awaits moderator approval. | 03:41 |
| poke53282 | to the mailing list ... | 03:43 |
| stekern | aha, what kind of behaviour? | 03:49 |
| poke53282 | ------------------------- | 03:51 |
| poke53282 | void f(int a, int b, int c){/*Do something with a,b and c*/} | 03:51 |
| poke53282 | typedef void (*Genericf)(int a, ....); | 03:51 |
| poke53282 | Genericf g = (Genericf)f; | 03:51 |
| poke53282 | g(1, 2, 3); // <- Crash on OpenRISC because of different calling conventions for variadic functions. | 03:51 |
| poke53282 | ------------------------- | 03:51 |
| poke53282 | DirectFB uses a interface which works like this code. | 03:51 |
| poke53282 | x86 ABI and ARMs ABI work with this kind of bad code. | 03:52 |
| poke53282 | It's not an error of OpenRISC. It is an error of DirectFB and maybe other libraries. | 03:52 |
| stekern | aha, so exectly the same problem as in gcc | 04:00 |
| poke53282 | what do you mean. This code works on the big architectures, but not on openrisc. | 04:01 |
| stekern | i.e. the bug that prevented us from using native gcc | 04:01 |
| stekern | casting a static arg function to a var arg function | 04:03 |
| stekern | http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00400.html | 04:03 |
| poke53282 | Oh, actually I didn't read your patch notes so thoroughly | 04:03 |
| poke53282 | You are right. The same problem. | 04:05 |
| poke53282 | What the hell they are doing. Is there something written in a C specification that makes this possible? | 04:06 |
| stekern | no, it's crap code | 04:06 |
| stekern | it's just that it happens to work on about any ABI that people care about | 04:07 |
| stekern | I guess we will need to go on a finger slapping crusade to teach them ;) | 04:08 |
| poke53282 | DirectFB main site third setence: DirectFB adds graphical power to embedded systems | 04:09 |
| stekern | I still wonder why our var arg ABI looks like it does though, it's more efficient to use as much registers as possible instead of going straight to the stack | 04:10 |
| poke53282 | Ok, I should write a bad mail in their mailing list. | 04:10 |
| stekern | and implementation wise it's not any harder to do | 04:11 |
| poke53282 | Let's see what the others in the mailing list will say. | 04:12 |
| poke53282 | Maybe we can change it. | 04:12 |
| poke53282 | Mhh, what would be the correct search command to search for this crappy code. | 04:12 |
| poke53282 | grep "...)" * | 04:12 |
| poke53282 | but this would give me too much results. | 04:13 |
| stekern | finding the optimal search command would be good, because those bugs are subtle when they happen | 04:14 |
| stekern | you probably have to resort to some static code analyzer to search for them | 04:22 |
| poke53282 | http://gcc.gnu.org/bugzilla//show_bug.cgi?id=44586 | 04:22 |
| poke53282 | Seems to be easier to change the OpenRISC ABI :) | 04:23 |
| stekern | I wonder if you can make gcc warn about it^W^W^W^W that bug report answered that question ;) | 04:24 |
| poke53282 | find . -name "*.h" | xargs grep "\.\.\.)" --> 7098 results in around 100 packages | 04:28 |
| poke53282 | Ok, manually this will be a hard job. | 04:31 |
| poke53282 | -Wbad-function-cast (C and Objective-C only) | 04:41 |
| poke53282 | Warn whenever a function call is cast to a non-matching type. For example, warn if int malloc() is cast to anything *. | 04:41 |
| poke53282 | Let's try | 04:41 |
| poke53282 | Nope | 04:44 |
| poke53282 | Ok, one question. Where is the ABI implemented. Only in gcc? | 04:46 |
| poke53282 | Or let's say the ABI for variadic functions | 04:47 |
| stekern | gcc and llvm | 04:50 |
| stekern | https://github.com/openrisc/or1k-gcc/blob/or1k/gcc/config/or1k/or1k.c#L2062 | 05:04 |
| stekern | the 'named' parameter will be 0 for ... args | 05:04 |
| stekern | https://github.com/openrisc/llvm-or1k/blob/master/lib/Target/OR1K/OR1KISelLowering.cpp#L570 | 05:07 |
| poke53282 | I don't use llvm right now | 05:12 |
| poke53282 | https://github.com/openrisc/or1k-gcc/blob/or1k/gcc/config/or1k/or1k.h#L654 | 05:12 |
| poke53282 | This one seems to be the line | 05:12 |
| stekern | yeah, that's where the 'named' argument is evaluated | 05:13 |
| poke53282 | I would just remove the "(named) &&" from this code and then compile the toolchain again and see how it crashes. | 05:16 |
| poke53282 | or set it always to true | 05:17 |
| poke53282 | Not sure | 05:17 |
| poke53282 | Trial and Error :) | 05:17 |
| stekern | there's a TARGET_SETUP_INCOMING_VARARGS define that other archs uses | 05:23 |
| poke53282 | but not in the or1k folder | 05:31 |
| stekern | http://gcc.gnu.org/onlinedocs/gccint/Varargs.html | 05:32 |
| stekern | no, because obviously picking the varargs from stack is default in gcc | 05:33 |
| stekern | so, that's probably the reason why we have that ABI in or1k | 05:34 |
| poke53282 | I understand | 05:34 |
| poke53282 | Not that easy | 05:34 |
| stekern | in llvm, it's actually more 'default' to do it the other way around, I had to do some extra work to get the or1k vararg abi to work there | 05:35 |
| poke53282 | Ok, so the simplest "solution" for testing would be to disable args in registers and then compile. Or have only one argument in registers. #define GP_ARG_MAX_REG 3 should do it | 05:41 |
| stekern | right | 05:41 |
| poke53282 | First I want just test if this a problem right now for the other libraries or not. | 05:41 |
| stekern | but, that will probably not work, because you have assembler code relying on the calling convention | 05:42 |
| poke53282 | I know you would say that .... | 05:42 |
| stekern | i.e. it'll put arguments in registers and call c functions | 05:42 |
| poke53282 | especially the linux kernel I suppose | 05:45 |
| stekern | uClibc too, e.g. crt1.S | 05:46 |
| poke53282 | Ok, both solutions are not simple. But maybe I will try to implement the varargs. Can't be so complicated ... | 05:58 |
| stekern | if you want to go back to searching, the vararg function will probably be typedefed, so you can do: grep -rI "typedef .* \.\.\.)" | 06:02 |
| poke53282 | Already tried | 06:08 |
| -!- enghong_ is now known as enghong | 07:27 | |
| --- Log closed Sat Jul 13 00:00:24 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!