IRC logs for #openrisc Friday, 2013-07-12

--- Log opened Fri Jul 12 00:00:23 2013
stekernpoke53281: 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 built02:19
stekernfirst you need this:
stekernthen 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 svn02:31
stekern(yes, I know, I should put that in the or1k-dejagnu repo :/)02:32
stekernput that file to the place where or1k-dejagnu was installed (/usr/local/share/dejagnu/baseboards on my machine)02:33
stekernthen you need an or1k linux machine running with telnet and ftp enabled02:36
stekernand 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=""02:39
stekernwith OR1K_IP substituted with the ip of your or1k machine02:40
stekernthe results/logs will then be produced in gcc/testsuite/02:45
stekernoh, I almost forgot, you need to edit the or1k-linux-uclibc-sim.exp to set the path to your gcc and g++ too02:49
poke53282Ok, thanks. I will try it when I have time.03:40
poke53282I 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
poke53282to the mailing list ...03:43
stekernaha, what kind of behaviour?03:49
poke53282void f(int a, int b, int c){/*Do something with a,b and c*/}03:51
poke53282typedef void (*Genericf)(int a, ....);03:51
poke53282Genericf g = (Genericf)f;03:51
poke53282g(1, 2, 3); // <- Crash on OpenRISC because of different calling conventions for variadic functions.03:51
poke53282DirectFB uses a interface which works like this code.03:51
poke53282x86 ABI and ARMs ABI work with this kind of bad code.03:52
poke53282It's not an error of OpenRISC. It is an error of DirectFB and maybe other libraries.03:52
stekernaha, so exectly the same problem as in gcc04:00
poke53282what do you mean. This code works on the big architectures, but not on openrisc.04:01
stekerni.e. the bug that prevented us from using native gcc04:01
stekerncasting a static arg function to a var arg function04:03
poke53282Oh, actually I didn't read your patch notes so thoroughly04:03
poke53282You are right. The same problem.04:05
poke53282What the hell they are doing. Is there something written in a C specification that makes this possible?04:06
stekernno, it's crap code04:06
stekernit's just that it happens to work on about any ABI that people care about04:07
stekernI guess we will need to go on a finger slapping crusade to teach them ;)04:08
poke53282DirectFB main site third setence: DirectFB adds graphical power to embedded systems04:09
stekernI 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 stack04:10
poke53282Ok, I should write a bad mail in their mailing list.04:10
stekernand implementation wise it's not any harder to do04:11
poke53282Let's see what the others in the mailing list will say.04:12
poke53282Maybe we can change it.04:12
poke53282Mhh, what would be the correct search command to search for this crappy code.04:12
poke53282grep "...)" *04:12
poke53282but this would give me too much results.04:13
stekernfinding the optimal search command would be good, because those bugs are subtle when they happen04:14
stekernyou probably have to resort to some static code analyzer to search for them04:22
poke53282Seems to be easier to change the OpenRISC ABI :)04:23
stekernI wonder if you can make gcc warn about it^W^W^W^W that bug report answered that question ;)04:24
poke53282find . -name "*.h" | xargs grep "\.\.\.)"   --> 7098 results in around 100 packages04:28
poke53282Ok, 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
poke53282Let's try04:41
poke53282Ok, one question. Where is the ABI implemented. Only in gcc?04:46
poke53282Or let's say the ABI for variadic functions04:47
stekerngcc and llvm04:50
stekernthe 'named' parameter will be 0 for ... args05:04
poke53282I don't use llvm right now05:12
poke53282This one seems to be the line05:12
stekernyeah, that's where the 'named' argument is evaluated05:13
poke53282I would just remove the "(named) &&" from this code and then compile the toolchain again and see how it crashes.05:16
poke53282or set it always to true05:17
poke53282Not sure05:17
poke53282Trial and Error :)05:17
stekernthere's a TARGET_SETUP_INCOMING_VARARGS define that other archs uses05:23
poke53282but not in the or1k folder05:31
stekernno, because obviously picking the varargs from stack is default in gcc05:33
stekernso, that's probably the reason why we have that ABI in or1k05:34
poke53282I understand05:34
poke53282Not that easy05:34
stekernin 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 there05:35
poke53282Ok, 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 it05:41
poke53282First I want just test if this a problem right now for the other libraries or not.05:41
stekernbut, that will probably not work, because you have assembler code relying on the calling convention05:42
poke53282I know you would say that ....05:42
stekerni.e. it'll put arguments in registers and call c functions05:42
poke53282especially the linux kernel I suppose05:45
stekernuClibc too, e.g. crt1.S05:46
poke53282Ok, both solutions are not simple.  But maybe I will try to implement the varargs. Can't be so complicated  ...05:58
stekernif you want to go back to searching, the vararg function will probably be typedefed, so you can do: grep -rI "typedef .* \.\.\.)"06:02
poke53282Already tried06:08
-!- enghong_ is now known as enghong07:27
--- Log closed Sat Jul 13 00:00:24 2013

Generated by 2.15.2 by Marius Gedminas - find it at!