| --- Log opened Tue Jul 08 00:00:09 2014 | ||
| stekern | dalias: (qemu-user fail thread tests) I know, but I thought it'd be a good start at least | 02:11 |
|---|---|---|
| dalias | stekern, do you have the run results/ | 02:13 |
| dalias | i only saw build results | 02:13 |
| stekern | dalias: (build part) if I run 'make run' in libc-tests, the tests run (at least it looks like that to me), but I get no error output from that | 02:13 |
| stekern | which is suspicous, since at least the thread tests should fail... | 02:13 |
| stekern | hmm, ok... I don't get *any* output from src/common/runtest.exe when running it without args. looking at the source, I should at least get a 'usage' message then. | 02:28 |
| stekern | weird, but something is definitely off here | 02:28 |
| dalias | it's an executable for the target, right? | 02:29 |
| dalias | i suspect there's something keeping it from working on the or1k port | 02:29 |
| stekern | yes, executable | 02:30 |
| stekern | ..for the target | 02:30 |
| stekern | yes, something is wrong, a simple hello world compiled with musl-gcc output nothing as well | 02:31 |
| stekern | maybe I should have tested *that* before running the tests ;) | 02:33 |
| stekern | gotta run to the bus, be back in ~1 hour | 02:36 |
| dalias | *nod* ok | 02:36 |
| dalias | strace is your friend, btw :) | 02:36 |
| stekern | yes, not going to work in qemu-user though :( | 02:37 |
| dalias | qemu-or1k -strace | 02:38 |
| stekern | hah, cool. I didn't now that feature existed. thanks | 02:40 |
| dalias | stekern, back? | 03:48 |
| stekern | just arrived | 03:48 |
| dalias | ah | 03:49 |
| stekern | strace output is rather sparse: | 03:51 |
| stekern | 32573 set_tid_address(-159405428,1,-159398720,3,1,-2097152) = 32573 | 03:51 |
| dalias | well the first syscall seems to be right | 03:52 |
| dalias | so it got that far | 03:52 |
| stekern | on a real target it segfaults, so should be relatively easy to debug from there | 04:07 |
| dalias | :) | 04:09 |
| stekern | or well, "real target", in or1ksim ;) | 04:11 |
| dalias | :) | 04:13 |
| dalias | btw how practical is real or1k yet? | 04:13 |
| stekern | practical, in what sense? | 04:18 |
| dalias | i meant for it to be an open-ended question because i don't know what sense | 04:19 |
| stekern | I would say it's as practical as any of the other soft cores (microblaze, nios II, lm32 etc) | 04:19 |
| stekern | when implemented on an FPGA I mean | 04:20 |
| dalias | so for example in terms of whether there are applications where it's cost-effective | 04:20 |
| dalias | also how it performs, etc | 04:22 |
| stekern | well, if you decide to tape out an ASIC with a CPU core, you can of course avoid license costs by using it. | 04:22 |
| dalias | *nod* | 04:22 |
| stekern | performance wise, it depends on the implementation, but I can speak about mor1kx because I know that. | 04:23 |
| stekern | it's not super-fancy, simple in-order single-issue 6-stage implementation | 04:24 |
| stekern | but it's fairly efficient at that | 04:24 |
| stekern | when running in FPGAs you of course get limited clock frequency (typically below 100MHz) | 04:26 |
| dalias | any idea on the segfault yet? | 04:28 |
| stekern | ah, right, coffee-break chit chat is over ;) | 04:29 |
| dalias | ;) | 04:29 |
| stekern | looks like it's ld.so that segfaults in __reloc_self | 04:32 |
| dalias | :) | 04:32 |
| stekern | maybe I should elaborate, I now tried to just run ld.so, and that segfaults too | 04:33 |
| dalias | any idea where? | 04:35 |
| stekern | oh, I mean, *that* is the one that segfaults in __reloc_self | 04:35 |
| stekern | or maybe you mean where in __reloc_self | 04:36 |
| dalias | yeah | 04:36 |
| stekern | when loading the second arg | 04:36 |
| dalias | so very early? | 04:36 |
| dalias | ah, it looks like your _dlstart didn't setup any args for it... | 04:39 |
| stekern | or not exactly loading the second arg, but rather loading from the calculated address from arg1 and arg2 | 04:39 |
| dalias | yes but _dlstart never puts anything in the arg registers :) | 04:39 |
| stekern | hah, yeah... that might help.. ;) | 04:40 |
| dalias | also, while -Bsymbolic-functions should fix this, you probably don't want a call via the plt here :) | 04:40 |
| dalias | just a direct call to __reloc_self is what you want (but of course -Bsymbolic-functions makes it into one anyway) | 04:41 |
| dalias | and loading the GOT register is probably not useful at this point, since it won't yet point to any valid data | 04:41 |
| dalias | __reloc_self is written not to depend on any global data or calls | 04:42 |
| stekern | right, I think I understand now, I should just load arg1 with *sp, arg2 with sp+4 and arg3 with the address of _DYNAMIC | 05:04 |
| stekern | but I do need to load the GOT register to get _DYNAMIC don't I? | 05:19 |
| stekern | well, it doesn't have to be the GOT register, but I need to get the got address into a register so I can as well use that | 05:20 |
| stekern | but _DYNAMIC is the first entry in GOT, so I should probably just load it into r5 instead | 05:34 |
| stekern | dalias: so, does something like this look sane? http://pastie.org/9366370 | 05:37 |
| stekern | at least ld.so runs happily with that | 05:38 |
| stekern | dalias: also, without the call through PLT, there's an R_OR1K_INSN_REL_26 inserted at the __reloc_self call site | 05:55 |
| stekern | (well, it will not actually be a call through plt, since it's already resolved when plt(__reloc_self) is used) | 05:56 |
| stekern | ok, now the hello world works... | 07:56 |
| stekern | man, I've must have exceeded the Ballmer peak when I wrote that _dlstart or something... | 10:20 |
| stekern | think I have straightened out the bugs in that now though | 10:20 |
| ysionneau | the Ballmer peak? | 10:36 |
| ysionneau | ah http://xkcd.com/323/ | 10:37 |
| rah | http://wutheringbytes.com/ | 11:57 |
| rah | anyone going to this? | 11:57 |
| rah | there's this talk: | 11:57 |
| rah | * The Future of Microprocessors, Sophie Wilson (Director of IC Technology, | 11:58 |
| rah | Broadcom) | 11:58 |
| -!- Francisco is now known as Guest66322 | 14:19 | |
| Guest66322 | Hi all, | 14:19 |
| Guest66322 | I'm getting this error: | 14:20 |
| Guest66322 | INFO: Preparing or1200 INFO: Checking out http://opencores.org/ocsvn/openrisc/openrisc/trunk/or1200 revision 852 to /home/xico/.cache/fusesoc/or1200 svn: Server sent unexpected return value (502 Bad Gateway) in response to OPTIONS request for 'http://opencores.org/ocsvn/openrisc/openrisc/trunk/or1200' ERROR: Failed to configure the system ERROR: "svn co -q --no-auth-cache -r 852 --username orpsoc --password orpsoc http://open | 14:20 |
| Guest66322 | Does anyone know if server is down ? | 14:20 |
| dalias | stekern, does the linker fail to resolve the REL_26? if so it's not a big deal to use the plt version since the linker will patch it out anyway due to -Bsymbolic-functions | 14:43 |
| stekern | dalias: yes, that's exactly what happens | 14:48 |
| stekern | I wonder, should we consider that a bug in the linker? | 14:48 |
| dalias | i'm not sure. i think it's consistent with the way other archs behave | 14:48 |
| stekern | anyway, I've left the plt() in there for now | 14:49 |
| dalias | iirc this is why we have illogical plt-type relocs on microblaze too | 14:49 |
| stekern | mmm, I saw that | 14:54 |
| dalias | are the +0 and +4 in your gotpc relocs right? | 14:55 |
| dalias | i ask because it would be easy to have the hi part wrong and still work most of the time | 14:56 |
| stekern | I think so, I don't have the code in front of me now. but r9 will contain the address at 1: | 14:58 |
| -!- guilherme is now known as Guest14693 | 15:06 | |
| -!- Guest14693 is now known as guiluz | 15:06 | |
| -!- Guest66322 is now known as Francisco | 15:15 | |
| -!- Francisco is now known as Guest54007 | 15:16 | |
| -!- Guest54007 is now known as francisconunes | 15:16 | |
| dalias | yes i think i see it now | 15:39 |
| dalias | i don't see how your code is working tho | 15:40 |
| dalias | it's passing the address of the GOT rather than the address of _DYNAMIC | 15:40 |
| stekern | yes, I know, but isn't that function it calls actually going through the got looking for relocations | 15:44 |
| stekern | ? | 15:44 |
| stekern | I'll happily admit that I don't follow that function (that I blatantly copied from microblaze) | 15:45 |
| jtdesousa | Hi, I am getting svn: Server sent unexpected return value (502 Bad Gateway) in response to OPTIONS request for 'http://opencores.org/ocsvn/openrisc/openrisc/trunk/or1200' | 15:47 |
| jtdesousa | ERROR: Failed to configure the system | 15:47 |
| jtdesousa | ERROR: "svn co -q --no-auth-cache -r 852 --username orpsoc --password orpsoc http://opencores.org/ocsvn/openrisc/openrisc/trunk/or1200 /home/jts/.cache/fusesoc/or1200" exited with an error code. | 15:47 |
| jtdesousa | ERROR: See stderr for details. | 15:47 |
| stekern | 'that function' = __reloc_self | 15:53 |
| dalias | stekern, no, the GOT doesn't have any information about relocations | 16:04 |
| dalias | it's one of the main targets on which the relocations are performed | 16:04 |
| dalias | the relocations however are in a relocation table which can only be found by looking for the relevant DT_RELA etc. entries in the _DYNAMIC array | 16:05 |
| stekern | dalias: hmm, that's true. I'll take another look later tonight when I'm at the machine. | 16:14 |
| dalias | ok | 16:19 |
| -!- guilherme is now known as Guest99037 | 16:53 | |
| stekern | dalias: so, let's try again, hopefully this is the last version of start.s: https://github.com/skristiansson/musl-or1k/blob/master/src/ldso/or1k/start.s | 17:45 |
| stekern | thanks a lot for having the patience walking me through it | 17:45 |
| dalias | ok i'll look | 17:46 |
| dalias | i think you could just use gotpchi and gotpclo directly with _DYNAMIC and _DYNAMIC+4 | 17:46 |
| dalias | rather than first loading the got address then adding the got-relative _DYNAMIC address | 17:47 |
| dalias | but either way should be valid | 17:47 |
| stekern | yeah, that'd probably work | 18:01 |
| dalias | iirc that's how we do it on other archs | 18:02 |
| dalias | btw i really like the way microblaze has 32-bit immediates via 2 instruction slots :) | 18:03 |
| stekern | me too | 18:07 |
| stekern | but I'm curious how that's implemented in hw | 18:07 |
| dalias | i think it's a hidden temporary register that's cleared by all instructions except imm | 18:08 |
| dalias | and when it's clear, the low 16 bits are just sign-extended | 18:08 |
| dalias | rather than using the value of this register for the high bits | 18:08 |
| dalias | there must also be some special logic for resetting pc back when an interrupt occurs between the imm and following instruction | 18:09 |
| dalias | or interrupts may just be deferred by one cycle | 18:09 |
| stekern | yes, I was more thinking in the lines of: is it threated like a single instruction, i.e. an exception can't happen in between the imm and the following insn | 18:09 |
| stekern | right | 18:09 |
| dalias | the difference between these two implementations should be mostly non-observable | 18:10 |
| stekern | I would guess that they are just deferred, special logic is annoying | 18:10 |
| dalias | the only way i can think that you might be able to observe it is attempting to measure a bias of randomly-timed interrupts' return addresses in a sequence of code with imm's | 18:11 |
| dalias | if the bias is backwards, it probably resets. if the bias is forward, it probably blocks interrupts | 18:11 |
| stekern | and the first has other implifications, like if you modify the return from exception register | 18:11 |
| dalias | either has that. | 18:11 |
| dalias | even if the instruction were executed atomically, you could still explicitly jump to the middle of it | 18:12 |
| dalias | which is what would happen if you modify the return-from-exception address | 18:12 |
| stekern | well, yeah, but the first would still be more transparent in the ISA I think | 18:13 |
| stekern | i.e. I would expect it to be documented if that was the case | 18:14 |
| stekern | can't say I've gone through the microblaze docs with a comb, maybe it is | 18:14 |
| dalias | overall i like the microblaze isa. it's like "mips done right" ;-) | 18:15 |
| stekern | otoh, blocking exception has interesting side-effects when handling pagefaults if they would be located on each side of a page boundary | 18:16 |
| dalias | yes.. | 18:16 |
| dalias | i suspect exceptions just decrement pc if the imm register is not clear | 18:16 |
| dalias | or maybe (this seems unlikely tho) exceptions even save/restore the imm register? | 18:17 |
| stekern | yeah, that's of course an option, but that wouldn't work if you (manually) nest exceptions | 18:32 |
| stekern | dalias: our assembler didn't like the micro-optimisation you suggested: | 18:34 |
| stekern | src/ldso/or1k/start.s: Assembler messages: | 18:34 |
| stekern | src/ldso/or1k/start.s: Internal error! | 18:34 |
| stekern | Assertion failure in gas_cgen_tc_gen_reloc at ../../binutils-gdb/gas/cgen.c line 1064. | 18:34 |
| dalias | ah | 18:50 |
| blueCmd | stekern: do you know if ethmac _needs_ DMA? | 19:20 |
| blueCmd | seems like it, hmm | 19:24 |
| blueCmd | I would like to tell the ethoc driver to DMA map to a certain memory area | 19:30 |
| blueCmd | the rational is that ethoc + it's memory chip it's DMAing to is not on the same board as the FPGA which is running Linux | 19:31 |
| stekern | mhmm | 19:31 |
| stekern | it's easy to tweak the driver to do that | 19:31 |
| blueCmd | cool! is it dirty or is it a candidate for upstream? | 19:32 |
| stekern | well, dirty is easy | 19:33 |
| stekern | I bet if you want to do it upstreamable you shoud find/add devicetree mappings for that | 19:33 |
| stekern | dalias: I just did the setjmp optimization, and then I remembered one thing I saw in microblaze earlier: http://git.musl-libc.org/cgit/musl/tree/src/setjmp/microblaze/setjmp.s#n20 | 20:06 |
| stekern | that should be 30->40 | 20:07 |
| blueCmd | stekern: FYI, it turns out that I can just do: | 20:10 |
| blueCmd | reg = <0x92000000 0x100>, <0x200000 0x8000>; | 20:10 |
| blueCmd | the code is already there to let me specify a default :) | 20:10 |
| stekern | hah, ok. cool | 20:11 |
| blueCmd | that will map the DMA area to 0x200000 (if that wasn't clear) | 20:11 |
| stekern | I'm not to familiar with the ethoc driver, I was just speaking generally that it is easy to change the driver to do that if it isn't supported | 20:11 |
| stekern | but that's good to know. | 20:12 |
| blueCmd | indeed, and I learned quite a few things finding out how it worked :) | 20:12 |
| stekern | that microblaze typo makes me wonder another thing, can microblaze handle unaligned accesses? | 20:13 |
| olofk | Has opencores.org become increasingly shaky? I'm considering cloning some of the repos to github to increase availability | 21:34 |
| dalias | stekern, thanks for the microblaze catch! | 23:34 |
| --- Log closed Wed Jul 09 00:00:11 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!