| jonibo|laptop | stekern: i sw | 09:01 |
|---|---|---|
| jonibo|laptop | stekern: i saw bits and pieces of the relocation discussion above... I missed the original question though | 09:01 |
| stekern | jonibo|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, globaladdress | 09:03 |
| jonibo|laptop | yeah, ok, that doesn't really look like a relocation! | 09:04 |
| jonibo|laptop | do you understand it now? | 09:04 |
| jonibo|laptop | elf 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 make | 09:05 |
| stekern | yeah, I took a peek at what pgavin pointed me too, I think I about grasp how it works | 09:05 |
| jonibo|laptop | linker just walks through the table and fixes up the locations in the table | 09:05 |
| stekern | another question: does the ABI for variable function arguments makes sense in gcc? | 09:07 |
| jonibo|laptop | yes, I think so | 09:07 |
| jonibo|laptop | last argument is number of variadic args and the args on the stack, right? | 09:07 |
| jonibo|laptop | i know this was terribly broken earlier and jb put a bandaid on it | 09:08 |
| stekern | in llvm, there is no clear notion of the argument being variable, only functions are marked as having variable arguments | 09:08 |
| jonibo|laptop | yeah, that's fine, though | 09:08 |
| jonibo|laptop | if a function is variadic, you just need to know where to find the args and how many there are | 09:09 |
| stekern | our ABI says: variable arguments on the stack, otherones in registers (if they fit) | 09:09 |
| jonibo|laptop | ok, I see your dilemma | 09:09 |
| stekern | i.e. printf(char *fmt, ...) => fmt in r3 and ... on stack | 09:10 |
| jonibo|laptop | yeah, fixed args go in regs and rest on stack | 09:10 |
| jonibo|laptop | GCC separates out these two classes | 09:10 |
| jonibo|laptop | LLVM _must_ be able to tell you,, too,, because other arches do it thisway | 09:10 |
| stekern | yeah, probably, but not trivially | 09:11 |
| stekern | I'm trying to figure out how to do it atm | 09:11 |
| stekern | trivially, all arguments to a function containing variable arguments end up in stack | 09:11 |
| jonibo|laptop | use VariadicFunctionN instead of VariadicFunction | 09:13 |
| jonibo|laptop | http://llvm.org/docs/doxygen/html/structllvm_1_1VariadicFunction.html | 09:13 |
| jonibo|laptop | it's kind of described there, no? | 09:13 |
| jonibo|laptop | replace N by number of fixed args | 09:16 |
| jonibo|laptop | i.e. VariadicFuntion3 for 3 fixed args | 09:16 |
| stekern | hmm, I have to take a closer look, but I'm not sure that's related to my problem | 09:20 |
| jonibo|laptop | LLVM IR has a va_arg instruction... essentially intrinsics for handling this stuff | 09:25 |
| stekern | yes, but thats for _creating_ functions with variable args, not calling | 09:26 |
| jonibo|laptop | calling? | 09:26 |
| stekern | when 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 argument | 09:27 |
| stekern | https://github.com/skristiansson/llvm-or1k/blob/master/lib/Target/OR1K/OR1KISelLowering.cpp | 09:27 |
| stekern | yes, calling is what I have problems with (atm) | 09:28 |
| jonibo|laptop | if fn->isVarArg is true, then you have variable args | 09:32 |
| jonibo|laptop | then fn->getFunctionType->getNumParams will tell you how many _fixed_ args you have | 09:33 |
| jonibo|laptop | the 'rest' will be variadic | 09:33 |
| jonibo|laptop | those go on the stack | 09:33 |
| stekern | ah, yeah, that might actually work | 09:34 |
| jonibo|laptop | that's pretty much how GCC does it, too | 09:35 |
| jonibo|laptop | (strangely enough) | 09:35 |
| stekern | I somehow presumed fn->getFunctionType->getNumParams would be the same as ArgLocs.size() | 09:35 |
| stekern | will test that, thanks alot for the input! | 09:35 |
| jonibo|laptop | sure... good luck with that | 09:38 |
| jonibo|laptop | man, I wish had time to work on that LLVM stuff, too... great fun, it is! | 09:40 |
| jonibo|laptop | :) | 09:40 |
| stekern | sure is :) | 09:40 |
| michaelliu | hello, when I was buidling openrisc toolchain by hand, gcc stop and said requisites "mpc,mpfr,gmp" | 11:32 |
| Jia | apt-get install libmpc-dev | 11:32 |
| jeremybennett | michaelliu: These are the standard pre-requisites for building GCC. http://gcc.gnu.org/install/prerequisites.html | 11:34 |
| michaelliu | but, "Building the Easy Way!" not these requisites | 11:35 |
| jeremybennett | Where are you getting your build instructions from? | 11:36 |
| michaelliu | http://openrisc.net/toolchain-build.html | 11:37 |
| jeremybennett | Try using this instead: | 11:39 |
| jeremybennett | http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Installation_from_source | 11:39 |
| michaelliu | hi,<jeremybennett>,according to the web pages buiding ,have any problem? | 11:39 |
| jeremybennett | "./bld-all.sh" is pretty simple. | 11:40 |
| michaelliu | How Can using i686-mingw32 cross compiler building openrisc toolchain ? | 11:42 |
| jeremybennett | It is harder. For this you should use the openrisc.net instructions, but it is not the "Easy Way". The bld-all.sh script only works on Linux systems | 11:44 |
| jeremybennett | The MinGW system has known differences which always cause trouble, in particular in the naming of directory hierarchies and handling of symbolic links. | 11:45 |
| michaelliu | thanks,jeremybennett> | 11:48 |
| michaelliu | according to the "http://openrisc.net/toolchain-build.html" easy way . make -j3 is fine, make is fail. please why? | 11:52 |
| jeremybennett | I don't know. I don't use http://openrisc.net/toolchain-build.html 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 |
| jeremybennett | You could try leaving of -j3 in case parallel make is not working. | 11:58 |
| michaelliu | thanks, I'm using i686-pc-mingw32-gcc compile gcc-svn | 12:01 |
| jemarch | hi | 12:04 |
| michaelliu | hi, 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 |
| michaelliu | but configure or1ksim target is or32-linux , this is loop? | 14:12 |
| michaelliu | In order building them from source, which one is first? | 14:13 |
| jeremybennett | Yes, 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 |
| michaelliu | thanks | 14:16 |
| michaelliu | hi, 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 |
| michaelliu | configure: error: cannot compute suffix of object files: cannot compile | 15:13 |
| michaelliu | see config.log detail. it's said #define PACKAGE_URL "http://www.gnu.org/software/libgcc/" | 15:15 |
| michaelliu | configure: exit 1 | 15:15 |
| pgavin | I'm not sure if migw is supported | 15:37 |
| pgavin | have you tried cygwin? | 15:37 |
| afr1g11 | anyone seen nathan ??? | 21:03 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!