IRC logs for #openrisc Monday, 2012-05-07

jonibo|laptopstekern: i sw09:01
jonibo|laptopstekern: i saw bits and pieces of the relocation discussion above... I missed the original question though09:01
stekernjonibo|laptop: I got curious to know how it works when I noticed a (by fault) l.ori r3, r0, globaladdress got turned into a l.ori r0, r0, globaladdress09:03
jonibo|laptopyeah, ok, that doesn't really look like a relocation!09:04
jonibo|laptopdo you understand it now?09:04
jonibo|laptopelf file has a table of addresses and "relocation types"... the address tells you where to make a modification, and the type tells you what modification to make09:05
stekernyeah, I took a peek at what pgavin pointed me too, I think I about grasp how it works09:05
jonibo|laptoplinker just walks through the table and fixes up the locations in the table09:05
stekernanother question: does the ABI for variable function arguments makes sense in gcc?09:07
jonibo|laptopyes, I think so09:07
jonibo|laptoplast argument is number of variadic args and the args on the stack, right?09:07
jonibo|laptopi know this was terribly broken earlier and jb put a bandaid on it09:08
stekernin llvm, there is no clear notion of the argument being variable, only functions are marked as having variable arguments09:08
jonibo|laptopyeah, that's fine, though09:08
jonibo|laptopif a function is variadic, you just need to know where to find the args and how many there are09:09
stekernour ABI says: variable arguments on the stack, otherones in registers (if they fit)09:09
jonibo|laptopok, I see your dilemma09:09
stekerni.e. printf(char *fmt, ...) => fmt in r3 and ... on stack09:10
jonibo|laptopyeah, fixed args go in regs and rest on stack09:10
jonibo|laptopGCC separates out these two classes09:10
jonibo|laptopLLVM _must_ be able to tell you,, too,, because other arches do it thisway09:10
stekernyeah, probably, but not trivially09:11
stekernI'm trying to figure out how to do it atm09:11
stekerntrivially, all arguments to a function containing variable arguments end up in stack09:11
jonibo|laptopuse VariadicFunctionN instead of VariadicFunction09:13
jonibo|laptopit's kind of described there, no?09:13
jonibo|laptopreplace N by number of fixed args09:16
jonibo|laptopi.e. VariadicFuntion3 for 3 fixed args09:16
stekernhmm, I have to take a closer look, but I'm not sure that's related to my problem09:20
jonibo|laptopLLVM IR has a va_arg instruction... essentially intrinsics for handling this stuff09:25
stekernyes, but thats for _creating_ functions with variable args, not calling09:26
stekernwhen calling a function with variable args, it will get lowered by LowerCall with isVarArg set, but I haven't figured out how I can determine which of the arguments actually was part of the variable argument09:27
stekernyes, calling is what I have problems with (atm)09:28
jonibo|laptopif fn->isVarArg is true, then you have variable args09:32
jonibo|laptopthen fn->getFunctionType->getNumParams will tell you how many _fixed_ args you have09:33
jonibo|laptopthe 'rest' will be variadic09:33
jonibo|laptopthose go on the stack09:33
stekernah, yeah, that might actually work09:34
jonibo|laptopthat's pretty much how GCC does it, too09:35
jonibo|laptop(strangely enough)09:35
stekernI somehow presumed fn->getFunctionType->getNumParams would be the same as ArgLocs.size()09:35
stekernwill test that, thanks alot for the input!09:35
jonibo|laptopsure... good luck with that09:38
jonibo|laptopman, I wish had time to work on that LLVM stuff, too... great fun, it is!09:40
stekernsure is :)09:40
michaelliuhello, when I was buidling openrisc toolchain by hand, gcc stop and said requisites "mpc,mpfr,gmp"11:32
Jiaapt-get install libmpc-dev11:32
jeremybennettmichaelliu: These are the standard pre-requisites for building GCC.
michaelliubut, "Building the Easy Way!" not these requisites11:35
jeremybennettWhere are you getting your build instructions from?11:36
jeremybennettTry using this instead:11:39
michaelliuhi,<jeremybennett>,according to the web pages buiding ,have any problem?11:39
jeremybennett"./" is pretty simple.11:40
michaelliuHow Can using   i686-mingw32 cross compiler building openrisc toolchain ?11:42
jeremybennettIt is harder. For this you should use the instructions, but it is not the "Easy Way". The script only works on Linux systems11:44
jeremybennettThe MinGW system has known differences which always cause trouble, in particular in the naming of directory hierarchies and handling of symbolic links.11:45
michaelliuaccording to the "" easy way . make -j3 is fine, make is fail. please why?11:52
jeremybennettI don't know. I don't use and I don't use MinGW. You might have to post an email to the forum or mailing list, showing your error message and asking for help.11:57
jeremybennettYou could try leaving of -j3 in case parallel make is not working.11:58
michaelliuthanks, I'm using i686-pc-mingw32-gcc compile gcc-svn12:01
michaelliuhi, OpenRISC GNU tool chain  Installation from source , The Or1ksim library is needed by GDB (as its simulator), so this should be installed first  ?14:11
michaelliubut configure or1ksim target is or32-linux , this is loop?14:12
michaelliuIn order building them from source, which one is first?14:13
jeremybennettYes, it is a loop, but not a one that causes problems. Or1ksim only needs the tool chain for running its tests. So you do 1) make/install Or1ksim, 2) make/test/install tool chain 3) test Or1ksim.14:14
michaelliuhi, I'm use i686-pc-mingw32 compile gcc-svn make all-gcc is fine then make install-gcc, after that make all-target-gcc is fail.15:12
michaelliuconfigure: error: cannot compute suffix of object files: cannot compile15:13
michaelliusee config.log detail. it's said #define PACKAGE_URL ""15:15
michaelliuconfigure: exit 115:15
pgavinI'm not sure if migw is supported15:37
pgavinhave you tried cygwin?15:37
afr1g11anyone seen nathan ???21:03

Generated by 2.15.2 by Marius Gedminas - find it at!