IRC logs for #openrisc Thursday, 2014-07-31

--- Log opened Thu Jul 31 00:00:43 2014
poke53281blueCmd: The flags are implemented in a horrible way.00:27
poke53281to use it with qemu-user is not so easy on the command line00:29
poke53281the binfmt-tools don't support options.00:29
poke53281and a bash script is not possible to execute.00:29
poke53281I would suggest, that you change the qemu source that the noflags cpu is the default.00:30
poke53281I guess the speed improvement will be a a factor 2 or 3.00:30
poke53281stekern: When I try to install the new uClibc I get an error message.
poke53281Maybe you know anything about it.04:40
stekernpoke53281: you should use the Linux headers from upstream04:54
stekernnot the ones in jonas repo04:54
stekernpoke53281: but really, you should use musl ;)04:57
stekerndalias: thanks for committing the mmap2 fixes05:00
stekernand I think your way of doing it is the right way (defining it as PAGE_SIZE not PAGE_SHIFT) and do the divide in __mmap05:01
stekernarc actually have a chance of working in musl05:01
stekernif it'd ever get ported ;)05:02
daliasstekern, the divide is in case we ever have to define UNIT as libc.page_size, for an arch where it's variable and the kernel uses the current pagesize for the mmap2 unit05:02
daliasin that case the kernel didn't give us a PAGE_SHIFT, only a PAGE_SIZE...05:02
stekernyes, you can configure the arc kernel to have either 4/8/16K pages and their mmap2 follow that05:03
daliasso unless we go to the trouble of converting it elsewhere (which would be really ugly) there's no choice but to divide05:03
stekernso, exactly the case you just described05:03
daliasah, i see05:03
daliasis arc interesting? i'm not familiar with it05:04
stekerndunno, I was just browsing the kernel to see which other archs had broken mmap2 and spotted that05:04
stekernjeremy_bennett can probably answer, he has afair been deeply involved with arc in a previous life05:07
daliasbtw the whole mmap2 thing is stupid05:07
daliasit can only map up to 16TB offsets05:07
daliasi'm pretty sure there can be files bigger than that now05:08
daliaslinux needs to add a proper mmap64 syscall with a full 64bit offset05:08
poke53281stekern: How do you know, which linux headers I am using :)05:14
poke53281Yes, I use indeed some kernel from jonas repo05:15
stekernpoke53281: well, you showed me your error messages ;)05:16
stekernyou can use that kernel, just not the headers from that05:18
stekernif you want to be adventurous, you can use this:
poke53281This is annonying. Which each kernel I run into another problem.05:20
poke53281No, I had enough adventurous for today. Updated binutils, uclibc and gcc.05:21
stekernwhat problems are you seeing now?05:21
poke53281cloning another mega repository. This would be the third incarnation of the Linux repo on my hard drive.05:24
stekernwell... you can clone with: git clone --depth 1 git://
poke532811. Linux: segmentation fault, when using my old uClibc. New headers and a bew compilation of uClibc solved this.05:27
poke532812. Linux: The ethernet no longer works.05:27
poke532813. Linux: my compiled X-window system gives strange output and crashed after some time.05:28
poke532814. Linux: I realize that my bzip2 decompression routine is maybe buggy and I add checksums.05:28
stekernbut wait.... wasn't 2. when you used another repo than jonas'?05:29
poke53281Yes, no 2.05:29
stekernso... what Linux repo are you using?05:29
poke53281The one from jonas currently.05:30
poke53281But as you can see in No. 4. Maybe the problem is fully kernel related05:30
poke53281No 2 is also solved I think. But the kernel crashed one or two times. So I went back to 3.1305:31
poke53281But I patch the kernel pretty much.05:32
poke53281Especially the htlb.05:33
stekerndid you try to use old userspace with the non-jonas kernel?05:36
poke53281At least the toolchain compiles now.05:36
stekernthat will not work05:36
poke53281Yes, I tried. And yes, it didn't work. I realized that.05:36
stekernbecause old userspace will try to call syscalls that openrisc doesn't have05:37
stekernjonas repo have a couple of patches that added the 'deprecated' syscalls, because at that time uclibc couldn't handle archs that were missing them05:39
poke53281Ahh, Ok. I understand05:40
stekernI removed those patches when I rebased all the out-of-tree patches ontop of 3.1505:40
stekernbecause they are not 'needed' anymore05:41
stekern(as long as you are not trying to run old userspace apps)05:41
stekernbut you wouldn't have been able to run your old userspace apps on a vanilla kernel from mainline neither05:44
poke53281Yes, therefore I wanted to take the easy way and use an "old" kernel.05:45
stekernI can dig out the couple of lines that the patch added for you ;)05:46
stekernbut as you saw, it will produce 'broken' linux headers05:46
poke53281Ahh, no problem. Let me see, how far I get if everything is new.05:47
stekernI dug them out anyway ;)05:51
jeremy_bennettstekern: dalias: just seen the post regarding ARC - it is a configurable architecture, so has a more complex tool chain than most. Joern Rennecke (amylaar) is the maintainer.08:50
jeremy_bennettBut I think this is the Linux side of things, so not is particular area of expertise. If you can phrase the question in an email I can try to see who knows about it.08:51
stekernjeremy_bennett: the question was more of general nature, whether ARC is interesting (like where it's typically used and so forth)09:25
stekernthe particular issue that it has in the Linux kernel is all clear to us, we don't need further explanations about that ;)09:26
blueCmdstekern:      15665:     binding file /usr/lib/or1k-linux-gnu/ [0] to /lib/or1k-linux-gnu/ [0]: normal symbol `__umodsi3' [GCC_3.0]09:46
blueCmd   105: 00002624    32 FUNC    GLOBAL DEFAULT   12 __umodsi3@@GCC_3.009:46
blueCmd     15681:     symbol=__umodsi3;  lookup in file=/usr/lib/or1k-linux-gnu/ [0]09:48
blueCmd     15681:     symbol=__umodsi3;  lookup in file=/lib/or1k-linux-gnu/ [0]09:48
blueCmd     15681:     symbol=__umodsi3;  lookup in file=/lib/or1k-linux-gnu/ [0]09:48
blueCmddo you recon this is like a trace? that libm is the one that is accessing it?09:48
stekernwhere is this from?09:48
blueCmdyes, maybe. Let's recompiled glibc again (which I remember promising but totally not doing)09:48
stekernwhat are you doing?09:48
blueCmdstekern: LD_DEBUG=all apt-get install asdasdasd09:48
stekernwhat is going wrong?09:49
blueCmdstekern: it's the same crash as before09:49
blueCmdstekern: :)09:49
blueCmdstekern: but you did a good job being a rubber duck here anyway09:49
stekernbut you said it had moved to strcasecmp?09:49
blueCmdstekern: it moved back!09:49
stekerngeese and ducks, you're just full of bird analogies09:51
stekerncan you define 'crash'?09:53
stekernare there fire?09:53
stekernblueCmd: is the current glibc compiled against the asm libgcc without @function and .size?09:58
stekernthe one that crashes09:59
blueCmdstekern: yes10:02
blueCmdso I think that's the problem10:02
blueCmdthat maybe now everything else works, and in the old case glibc worked but everything else was broken10:02
blueCmdhm, apparently we do not support STT_GNU_IFUNC for binutils10:09
stekernwhat does it do?10:16
maxpalnHi, starting to debug the mor1kx - I found I had some simulator hangs and the Linux binary I used in HW for the OR1200 doesn't work. I am guessing I have a SW issue - maybe a GCC version problem or something like that. The first thing I want to do is get a clean set of simulations running using the latest tests that stekern pointed me at.10:21
maxpalnI am missing or1k-asm.h - and poking around I noticed several other aspects to that set of tests that weren't present in the originals. For example, native/lib contains a Makefile but I am not sure how it's targets should be used etc.10:23
maxpalnwhat's the recommended use model for these new tests?10:23
stekernor1k-asm is included in the or1k- toolchains10:23
maxpalnok, so I wonder why it isn't being found10:24
stekernI forgot that you were still using the old toolchain when I pointed you to the test repo10:24
maxpalnmore generally, I wonder if I am making hard work for myself by trying to back in these new tests into my old test environment.10:24
maxpalnThis could be a good spot to segue into a full up to date tool chain etc.10:25
stekernyes, but otoh, then you are changing a lot of things at the same time10:25
stekernI would stick with the old tests10:25
maxpalnOk, but the old tests don't pass at the moment10:25
maxpalna lot of them do10:25
maxpalnbut one of them hung -10:26
stekernat least until you're confident that your soc is sound10:26
stekernthe linux kernel compiled 'for or1200' should just work (unless your soc is otherwise substantially different)10:27
maxpalnwell, I found that or1200-except didn't complete10:27
maxpalnto speed up sim I wasn't tracing any signals in the simulator - so I haven't been able to debug10:27
maxpalnwhen I tested the Linux kernel in HW and found it didn't boot either (no UART output) I thought there must be a SW issue somewhere.10:28
maxpalnLet me run the tests again with signal tracing enabled and go back to debugging the individual tests10:30
maxpalnuntil I have a cleanly passing set of simulation results I think I am on a hiding to nothing...10:30
blueCmdpoke53281: man, that noflags thing was much faster. no wonder since it translates adds 1:110:32
stekernthere *might* be some of the or1200 tests that makes assumptions that are only valid for or1200 (stupid assumptions, like that a certain amount of instructions should take a certain amount of ticks)10:33
stekernI don't know if exactly that assumption exist, but that type of assumptions10:33
stekernor you've just found a bug in mor1kx10:34
maxpalnmaybe - I guess we'll see once I start debugging10:34
maxpalnjust running through the simulations again now10:34
stekernif you have the or1200-except elf I can give it a run here too10:36
maxpalnHmmm, interesting - to speed things up I switched from my DDR3 memory model to the basic SRAM - it simulates around 1000 times quicker :-), if I get a clean sweep on the SRAM tests I'll re-run with the DDR3 model10:36
maxpalnAlmost immediately I have got a failure on or1200-mmu10:36
stekernif you can gather together the elfs from the failing tests I can try to run them here too10:40
maxpalnok, I'll zip them up and send them over10:41
stekernI mean, feel free to debug them yourself, but four eyes are always better than two10:43
stekernheh, coincidently I just found a bug in mor1kx mmu10:44
maxpaln:-) don't worry - I'll  be doing plenty of debugging10:52
maxpalnbut knowing that the ELF *should* work is a nice starting point!10:52
maxpalnok, 6 failures out of 18 tests - that's a pretty big hit ratio. I have included a README that lists how the test fails in case you care - four of them produce an simulation failure, two them just hang11:21
maxpalnI'll let you know what I find11:21
stekerngreat, thanks11:27
jeremy_bennettstekern: Ah OK - the answer to that is that ARC is very interesting. Due to its configurability. It is quite widely used as an embedded core (since it is Synopsys' in house core).11:34
stekernmaxpaln: this is the results I gained from these tests: dsxinsn and mmu passes11:51
stekernext and mac instructions aren't implemented in mor1kx so they are kind of expected to fail11:52
stekernthe ext instructions should be easy to add, so that was a good reminder for me to do.11:52
stekernI think the overflow handling in or1200 isn't exactly compliant with the spec, so that might be the reason why that fails11:53
stekernthat leaves that and the except test as question marks, I have no good explanation to why the except test fails.11:54
stekerninterestingly, the except test doesn't hang for me like it did for you11:59
maxpalnhmm, just back at my desk12:00
maxpalnso i'll remove ext and mac from my tests.12:01
maxpalnso for the remainder your results are: or1200-except: fail, or1200-ov: fail, or1200-mmu: ? or1200-dsxinsn ?12:04
maxpalnsorry - just noticed that the two  I marked as ? pass12:05
maxpalnmaybe I'll start with the except test - it fails for you and hangs for me, that could be a good clue.12:05
maxpalnout of interest, the OR1200 monitor used to produce some nice log file giving instruction sequences and register dumps etc. Can you MOR1kX monitor do this (yet)?12:11
stekernit can even produce nicer instruction traces12:12
stekernwith disassembled instructions12:13
stekernjuliusb was crazy enough to write an disassembler in verilog ;)12:13
maxpalnNice! - I have included the monitor now (I eventually worked out the defines) but the output in the ../out folder is this12:13
maxpaln[root@localhost run]# ls -l ../out12:14
maxpalntotal 1612:14
maxpaln-rw-r--r-- 1 root root 64 Jul 31 05:10 or1200-mmu-general.log12:14
maxpaln-rw-r--r-- 1 root root 38 Jul 31 05:10 or1200-mmu-trace.log12:14
maxpalnneither contain the instructions etc.12:14
maxpalndo I have to enable something in the monitor?12:14
stekernI think you have to poke it with something to make it emit it12:14
maxpalnhmmm , let me have a look12:14
stekernit slows down simulation, so you don't want it always remembered12:14
stekernehm enabled12:14
stekernI was about to say that I don't remember how that's done in the next sentence...12:15
maxpalnaha, +define+TRACE_ENABLE appers to be the ticket12:16
maxpalnor rather +define+trace_enable12:17
fnunesHi, I am trying to connect OpenOCD to a digilent atlys board using the digilent programming port or the xilinx platform cable. Is it possible to openocd use the vendors drivers ?12:17
stekernusing the xilinx platform cable should definetely be possible, iirc someone did that12:17
stekernusing the digilent programming port should be possible in theory, but I don't know how much effort is required to make that work12:18
fnunesI tried but it seems necessary to write a driver/deamon that supports openocd.12:19
stekernhmm... this mmu bug is interesting, it happens under a scenario I'm not sure how it should be handled12:29
stekernthe problem is that the kernel has a variable in memory has the cache inhibit bit set (at least during boot), but this variable is also being accessed with the mmu off.12:32
stekernso, the problem is that writes to that memory area when the mmu is on will not be seen by the accesses when the mmu is off12:33
stekernI'm fixing it now by letting the writes go through to the cache even though the cache inhibit bit is set, I can't come up with any drawbacks with this approach12:34
maxpalnoh, nice - the monitor trace output is sweet!12:47
maxpalnit is enabled via +trace_enable on the vsim command BTW12:47
blueCmdpoke53281: you cut down the compile time like 6 times with that flag12:50
blueCmdpoke53281: \o/12:50
maxpalnwell, my mmu simulation failure is triggered by a Bus Exception - it occurs during the Write Tes Program section of the itlb_translation_test() - here to be precise:13:07
maxpalnS 00002518: 9c420001 l.addi  r2,r2,0x0001    r2= 00000007  flag: 113:07
maxpalnS 000033f4: c0032000 l.mtspr r3,r4,0x0000    SPR[1802]  = 0010c060  flag: 113:07
maxpalnS 00000200: 9c21ff00 l.addi  r1,r1,0xff00    r1= 0000a444  flag: 113:07
maxpalngoing to dive into the simulation waveform to track down13:07
mor1kx[mor1kx] skristiansson pushed 1 new commit to master:
mor1kxmor1kx/master 7b08833 Stefan Kristiansson: cappuccino/lsu: perform stores to cache during cache inhibit...13:07
stekernmaxpaln: hmm, non of those instructions should cause bus errors13:08
maxpalnyep, that is what I concluded13:08
stekernwhere is the closest load/store before that?13:08
maxpalnalthough, it is nice to have an expert confirm it13:08
stekernstores on mor1kx is deferred13:09
maxpalnS 0000250c: d410a000 l.sw    0x0000(r16),r20 [0010c064] = 15000000  flag: 113:09
maxpalnS 00002510: 9c601802 l.addi  r3,r0,0x1802    r3= 00001802  flag: 113:09
maxpalnS 00002514: 040003b8 l.jal   0x00003b8           flag: 113:09
maxpalnS 00002518: 9c420001 l.addi  r2,r2,0x0001    r2= 00000007  flag: 113:09
maxpalnS 000033f4: c0032000 l.mtspr r3,r4,0x0000    SPR[1802]  = 0010c060  flag: 113:09
maxpalnS 00000200: 9c21ff00 l.addi  r1,r1,0xff00    r1= 0000a444  flag: 113:09
stekernso you can get the exception later in the execution stream, but epcr should still point to the load/store13:10
maxpalnah, I see13:10
maxpalnputting together a sensible waveform now13:10
stekernah, it can be the l.jal. instruction fetch can cause bus errors as well13:10
stekernor the store before that13:11
stekernhow much ram do you have in your simulation system?13:12
stekernthe store is just above 1MB, I bet you at least have that much?13:12
maxpalnnot much - its an SRAM13:12
stekernI think the tests expects at least 8MB13:12
maxpalnAh, good spot -13:13
maxpalnI had shrunk the amount of SRAM so I could run a HW test with it - I only had 64 KB :-)13:14
maxpalnI will run again with 8 MB13:14
maxpalnI think you beat me by about 2 minutes - I had just noticed the WB_RAM component asserting errors, that only really happens when an address larger than the instantiated RAM is accessed!13:14
maxpalnput that one down as a stupid error!13:17
maxpalnI try to keep those under 10 a day!!13:17
maxpalnyep, mmu test now passes.13:17
maxpalnso lets try the except test now - this one failed for you too.13:17
maxpalnok, I have discovered the cause of the hang in my except13:40
maxpalnI suspect the reason it doesn't hang in your case is that you are using a newer/better arbiter implementation13:40
maxpalnIn fact, this comes back to the discussion we had earlier about whether it is valid for STB to remain asserted between ccyles13:41
maxpalnThe sequence of events is like this:13:41
maxpalnCPU deliberately attempts to access an invalid memory address at 0xEE -13:41
maxpalndue to the way the arbiter is set up in my SOC this goes nowhere and eventually triggers a watchdog error13:42
maxpalnhowever, the STB never deasserts before starting the new cycle -13:42
maxpalnand the sourcve of the bug is that the watchdog timer is looking for that transition on STB to start the timer13:43
maxpaln   assign wbm_stb_edge = (wbm_stb_o & !wbm_stb_r);13:43
maxpaln   always @(posedge wb_clk)13:43
maxpaln     if (wb_rst) watchdog_timer <= 0;13:43
maxpaln     else if (wbm_ack_i) // When we see an ack, turn off timer13:43
maxpaln       watchdog_timer <= 0;13:43
maxpaln     else if (wbm_stb_edge) // New access means start timer again13:43
maxpaln       watchdog_timer <= 1;13:43
maxpalnso the new access to 0xEE goes nowhere and the watchdog hasn't been triggered!13:43
maxpalnI think the solution is probably to upgrade the arbiter in my SOC - what do you think?13:44
stekernhmm, yeah13:51
stekernbut why does that code even look for an edge?13:51
maxpalnwe have pulled holes inthe arbiter implementation before - I think it is generally quite poor.13:52
maxpalnThe question is how to improve - I am not against a wholesale change to whatever is the newest version13:53
maxpalnWith a new processor and arbiter(s) this would essentially bring me close to the latest HW I guess - peripherals aside.13:54
maxpalnAt the very least it would be good to review the latest arbiter for ideas on patching up the version I am using.13:55
maxpalnwhat's the quickest way to download the latest SOC code? Is there a git clone?13:55
maxpalnI guess this would be ORPSoCv313:57
maxpalnFound this on the websit e- will assume this is up to date13:58
maxpalngit clone
blueCmdmaxpaln: git clone and the one you said14:01
maxpalnhmmm, this is pretty different - not completely unrecognisable - but different enough that It's not entirely clear how it hangs together. I'll review some of the systems - maybe the atyls board, to see if there are good examples of hanging a SOC together14:06
maxpalnhmmm, I see a fundamentally different approach is used here - there is one arbiter per peripheral...14:08
HeshamI have used verilator model as stekern suggested, should I use OpenOCD to connect it with GDB?14:09
maxpalnHmmm, this comment is interesting -
maxpalnI don't see an external watchog in the atlys system14:12
maxpalnor any of the others for that matter - curious!14:13
maxpalnperhaps even more interesting is the fact that the latest or1k-tests stekern sent me doesn't include an except test - at least not by that name14:20
stekernHesham: yes14:20
stekernmaxpaln: yes, there is no watchdog (yet)14:22
stekernthat comment is however false14:22
stekernit will error on out of bound accesses14:22
maxpalnaha - so where is that implemented - because that scenario is pretty much what the watchdog in my arbiter is doing14:24
maxpalnthe out of bounds trapping that is, I haven't spotted it anywhere yet14:26
stekernman the or1200 tests are crap, there's no clear way they are expressing where they fail...14:32
stekernthey just incremenet a counter and then check that that happen to match a 'magic' constant14:32
maxpalnI found them confusing - but then I don't really follow most of the tests so I assumed I was misunderstanding the point. %-)14:34
blueCmdstekern: rebuilding gcc doesn't seem to fix my crash :'(14:38
blueCmdstill crashes on loading __umodsi314:38
blueCmdI'll try to rebuild gcc one final time with the new glibc, then there should be no traces left of the weird asm file14:38
blueCmdaugh. I did rebuild glibc, I'm about to rebuild gcc again14:39
maxpalnok, I see - this is starting to make sense now14:44
maxpalnat least, I can see how the arbiter hangs together - but I am a little confused about why the atlys orpsoc_top.v doesn't appear to instantiate wb_intercon()14:47
stekernok, I understand why the except test fails here too14:49
stekernit has to do with the deferred stores14:49
maxpalnHave I unwittingly highlighted a bug!14:51
stekernmaxpaln wb_intercon is instantiated in this autogenerated file:
stekernno, it's just that the test will not work with14:51
maxpalnok, well that is good news, kinda - I can skip the test :-)14:52
stekernso, the assumption is that bus errors are non-recoverable, so when you get the bus exception, you'll get the pc and offending address for debugging purposes14:53
stekernbut, the or1200-except test tries to recover after the bus errors it has induced14:54
HeshamOK, thanks stekern14:54
stekernHesham: you should invoke openocd like this for that: ./src/openocd -c "set TAP_TYPE MOHOR" -f ./tcl/interface/jtag_vpi.cfg -f ./tcl/board/or1k_generic.cfg -s ./tcl14:55
maxpalnaha - ok, actually now you mention it I did wonder how this test managed to carry on after a bus exception but when I was debugging the Linux kernel in HW a bus exception was fatal.14:56
maxpalnand, as for the wb_interconnect - that makes complete sense now.14:56
Heshamstekern: There is no ./tcl/board/or1k_generic.cfg file there14:56
HeshamI only found ./tcl/target/or1k.* file14:57
maxpalnso, I am assuming that wb_interconnect also gets auto generated by the fusesoc tools.14:58
stekernmaxpaln: actually, it's a python script in orpsoc-cores/wb_intercon/sw/14:59
Heshamstekern: ain't this the correct repo to clone ?14:59
stekernHesham: ah, no...
stekernyou should use openocd from upstream15:00
stekerni.e. the official openocd repo15:00
maxpalnIn light of the abandonment of the except test it is possible I can still get a passing simulation regression suite against my SOC. I will target that for now - if I run into problems I may skip a step and jump to the new fusesoc flow.15:00
HeshamUnfortunately I was following these instruction -> I assume it's out-dated now15:01
HeshamThanks stekern15:01
stekernah, maybe they are15:01
stekern_franck_ is our openocd expert, but he is busy fixing his house most of the time nowdays ;)15:02
stekernHesham: I think the orconf2013 workshop notes should be pretty up-to-date15:02
HeshamI am checking it...15:04
stekernlook, _franck_ is so busy so he'll go hide if you mention his name ;)15:05
Heshamstekern: is this the correct configuration for building OpenOCD to run with verilator? -> ./configure --enable-ftdi --enable-usb_blaster_libftdi --enable-maintainer-mode15:12
HeshamCause I got an error "Error: The specified debug interface was not found (jtag_vpi)"15:12
HeshamWhen running the command you typed15:12
stekernHesham: I think you need something else there too15:19
stekernwait, i'll try to find what ;)15:19
stekern ./configure --enable-ftdi --enable-usb_blaster_libftdi --enable-jtag_vpi --enable-maintainer-mode15:20
_franck_stekern: :)15:23
_franck_you're right, I spend my free time looking for building material15:24
_franck_drawing things on sketchup15:24
_franck_by the time I get back to openrisc things, you'll have a mor1kx v5.0 :(15:25
Heshamstekern: Did you find it?15:43
stekern ./configure --enable-ftdi --enable-usb_blaster_libftdi --enable-jtag_vpi --enable-maintainer-mode16:00
stekernHesham: ^16:00
HeshamThanks stekern :)16:07
poke53281blueCmd: yes, a factor of 6 is possible.16:56
poke53281the flags are really really horrible implemented.16:56
poke53281with 64 bit arithmetic and no optimizations.16:57
poke53281If we could get rid of the delayed slot, the openrisc cpu would look similar to  a byte code machine.17:00
poke53281No side effects. No history related stuff which has to be implemented.17:01
blueCmdpoke53281: there is or1knd17:13
poke53281I am afraid to try it. Does it work with Linux.17:19
poke53281stekern: When I try to compile a natie gcc I get the error message:
poke53281Oh wait. Maybe a typo in the configure parameters.17:24
poke53281Yes, was a typo17:31
stekerngood, it's enough with blueCmd's problems with those libgcc functions ;)17:37
blueCmdyeah, tell me about it17:44
pecastroups ... wrong window...17:46
poke53281nice, finally I can compile gcc without -fpic19:01
stekernwhy did you need that before?19:10
poke53281An error message in gcc 4.8.0. I think one file was supposed to be compiled with -fpic but wasn't.19:26
poke53281Also nice: looks like linux compiles finally without orkk-elf-gcc.19:27
poke53281no linker errors anymore19:27
stekernpoke53281: yes, that's the main reason we switched back to the asm versions of the libgcc functions21:05
daliasstekern, if you're doing weird stuff with the libgcc functions (rather than just using the existing C), please make sure you make their visibility hidden21:09
dalias(.hidden in asm)21:09
daliashaving default visibility on libgcc symbols causes major ABI breakage21:09
blueCmdmaybe that's related21:13
daliaswhat happens is that other libraries (including libc) will pull in _parts_ of libgcc.a, depending on what they use (e.g. long long math), then _expose_ that as part of their api/abi (their exported dynamic symbols)21:16
daliasso a program using such a library will get the symbol from the library, and therefore not pull in its own copy from libgcc.a21:17
daliasnow, if the shared library later changes in such a way that it no longer needs that particular function from libgcc.a....21:17
daliasthe shared library no longer exports it, and the application breaks with missing symbol errors at runtime21:17
blueCmdthat's what I'm seeing I think21:17
stekernyeah, that makes sense, and we should add .hidden, but blueCmd I can't see how that's related to what you are seeing21:19
daliasin general, any .a file that's potentially goin to get linked into a .so file needs to (1) be -fPIC, and (2) have all its symbols hidden21:19
blueCmdstekern: the last sentence that dalias writes is ugly close to the behaviour I'm seeing21:19
stekernblueCmd: all your libs are linked to the C version21:20
daliasand also (3) be free of state that needs to be process-global (since each .so and the main program will all get their own copies of the objects from the .a file)21:20
blueCmdstekern: not libc21:20
daliasstekern, if bluecmd first built an app against the old .so's which were built against libgcc.a with exported symbols...21:21
dalias...then replaced the .so's with ones built against the all-C libgcc.a21:21
stekerndalias: no, the other way around21:21
daliasthe app would then have unresolved symbols at load time21:21
blueCmddalias: it's the other way around, first all-C then all-ASM21:21
daliasbluecmd, was the first all-C built with --disable-shared? :)21:21
blueCmdI don't think so21:22
daliasgcc has a bug where --disable-shared also turns off visibility attributes21:22
blueCmdwe have some visibility bugs thought I think21:22
daliasbasically, --disable-shared should be interpreted as "build a gcc that can't produce working shared libraries" :)21:22
blueCmd"gcc.dg/visibility-d.c scan-not-hidden"21:22
stekerndalias: looking around other archs asm implementations, there are actually very few (if any) that declare those functions as .hidden (unless I'm missing something when grepping)21:32
blueCmdyeah, I didn't see it either - but it's worth trying if this doesn't solve it21:33
daliashmm that sounds like a major bug then unless they have something in the build system to fix it21:33
daliasi wasn't aware libgcc had asm21:33
stekernyeah, that's what I'm thinking, that there has to be some black magic, it's gcc after all ;)21:34
stekernthe function we are speaking about are __udivsi3, __umodsi3, __divsi3 etc21:34
daliasbtw i have an evil asm implementation of those for x8621:35
daliasusing the fpu :)21:35
daliasld80 fpu can do 64/64 integer division assuming the result is exact21:36
daliasand you can make it exact by first doing fmod21:36
daliasthe concept isn't sufficiently tested to consider putting it in musl tho21:37
daliasit's more just a toy at this point21:37
stekernI'm not sure our asm versions are much better than the C versions, but it get around the issue where you have got references in them21:38
daliaslibgcc should always be built with -fPIC21:40
stekernexactly, so there *will* be got references in the C versions21:40
stekernbut our Linux port uses libgcc.a for those functions21:40
blueCmdjust add a GOT to the kernel21:41
blueCmdhow hard can it be?21:41
daliasyeah, i think the easiest would but just adding a GOT21:42
stekernso we need them to be position independent, but without got references. and the asm versions fulfill that.21:42
blueCmdI was being sarcastic actually21:42
stekernblueCmd: you still haven't answered, how does it crash? ;)21:48
stekernblueCmd: are you using my hacked version of or1k.S now?22:13
stekernthe one without the R_OR1K_INSN_REL_26?22:13
blueCmdstekern: hm, I haven't looked at the relocations for libgcc22:16
stekernI don't think your dynlinker can handle those22:17
blueCmdare those special?22:19
blueCmd(i.e. are they not emitted in normal C?)22:19
stekern <- this will just write the address of the symbol at the place where the jump is, no?22:20
blueCmdstekern: right, you mean it needs PC + X ?22:20
stekernyes, and then account for if it's a l.jal, l.jalr, l.j or l.jr22:21
stekernwhat I really mean is that I don't think the dynlinker even should try to resolve those22:22
blueCmdso how did this work for you in musl?22:22
stekernI used my hacked up version that avoids the R_OR1K_INSN_REL_26 relocations22:23
blueCmdstekern: do you have a patch?22:23
daliasi dont think a rel26 reloc should exist at dynamic-linking time22:23
daliasonly in .o files22:23
daliasconceptually (whether or not it's in .text) it's a TEXTREL22:24
stekerndalias: yeah, I think it's a bug in our (ld) linker that those get emitted22:25
blueCmdstekern: aha22:26
blueCmdstekern: this makes sense22:26
blueCmdtoo bad I didn't get you the first time when you spoke about this22:26
blueCmdoh well, at least my CPU has been getting its exercise22:27
stekernI'm going to look into that too, why they end up in the dyn libs22:27
daliasstekern, where do they get emitted?22:27
stekernthat jump will end up in both resolved *and* with an R_OR1K_INSN_REL_26 relocation22:31
daliasstekern, i think that's a bug, but it probably comes from not having it hidden22:32
daliasin PIC you should have that as a plt call22:32
daliasor have the function be hidden22:32
daliasotherwise it's a TEXTREL22:32
blueCmddalias: '.hidden __udivsi' in the entry point should fix that?22:35
daliasfor this purpose, i think it needs to be declared .hidden at the point of the call22:36
daliasfor the .so issue, what matters is that the definition is .hidden22:37
blueCmdstekern: do you recon this is what R_X86_64_IRELATIV is for?22:57
blueCmdone of the things on my TODO list is to support IFUNC relocations22:57
blueCmd < test program that should output a relocation but doesn't for or1k22:58
blueCmddalias: you might know as well22:58
daliaswhy should there be a reloc in the output?22:59
daliasit's fully linked22:59
daliasif this were an ET_DYN file it should still have a reloc22:59
daliasbut not for a non-pie main program ELF file23:00
blueCmddalias: gnu_indirect_function should do some magic23:00
daliasoh i missed that..23:00
blueCmdthis code is taken from glibc's configure in order to support --enable-multi-arch23:00
blueCmdit complains that we do not support 'GNU IFUNC'23:00
daliasyes, it looks like you don't support ifunc :)23:00
daliasmusl doesn't either and i'm hesitant to add it23:01
daliasbecause running application/library code while performing relocations and while the dynamic linker holds locks is a really bad design :(23:01
blueCmdI'm not going to argue there23:04
daliasi think the condition for adding it would be having a clearly documented specification from the binutils/glibc/etc. ppl on what ifunc resolvers can do23:05
daliasand a statement that doing anything else is UB23:05
daliasright now there's none as far as i can tell23:05
daliasthe contract is "you can do whatever seems to work" ...23:06
poke53281It is impressive how small a distribution could be, if you care  a little bit about size.
blueCmddalias: adding .hidden might actually break stuff. I don't get the versioned symbols that the libraries are trying to import anymore23:06
poke53281I removed the manuals. The include files are included23:06
daliaspoke53281, that's not small. :)23:06
blueCmddalias: I'm going to build it and see if it works, but if it doesn't I'm going to tear that out23:07
daliasbluecmd, ah... i see why magic is needed for .hidden23:07 obviously should not have hidden definitions23:08
daliaslibgcc.a needs hidden definitions23:08
blueCmddalias: you don't have scummvm in that VM though ;)23:10
daliasstill pretty impressive i thought23:12
poke53281dalias: and no gcc and no ssh. What is this?23:12
daliaspcc :)23:13
poke53281looks like the equivalent of my busybox. And in my case, it is statically compiled23:13
daliasssh isn't really possible because the browser doesn't give js that kind of network permission23:13
poke53281Hehe, I know.23:14
poke53281And now ask the question. Why does it work with jor1k? ;)23:14
poke53281Yes, of course23:15
blueCmdWeb 2.0!23:15
daliaswebsockets let you connect to arbitrary host/port??23:15
poke53281hehe, no23:15
blueCmddalias: I think poke53281 has a 'private' network that you can connect to via the websocket23:15
poke53281I use wesocket only asa wrapper for ethernet frames.23:16
* blueCmd is just trying to show off that he actually read about poke53281's work23:16
daliasi see23:16
daliasbtw how small can you get a usable jor1k setup?23:16
daliasi'm guessing if you want a compiler that's a big limiting factor23:17
daliassince there's no pcc for or1k23:17
poke53281blueCmd: At least one read the stuff I wrote.23:18
poke53281compressed or uncompressed?23:19
poke53281how small? binutils.tar.bz2 and the kernel image23:19
poke53281which is 2 MB.23:19
poke53281So, compressed something around 2.7MB.23:19
poke53281busybox.tar.bz2 I mean23:20
poke53281not binutils.tar.bz223:20
poke53281gcc+binutils cost around 7MB.23:20
poke53281If you remove stuff like lto and cpp.23:20
blueCmdpoke53281: did I tell you about a party I went to and the guy showed me jor1k?23:21
blueCmd(and I told him I ported Debian to the thing and he was 'Wow! I read aobut that!')23:21
poke53281No. :)23:22
blueCmdpoke53281: so your work is quite high-profile23:22
poke53281Let's wait until it is really useful. We are working hard on it.23:22
poke53281you will soon be able to save your state23:24
poke53281and to access your local filesystem.23:24
poke53281At least, this is the plan.23:24
blueCmdstekern: _franck_: juliusb: I know you are honorable people and always do as you're told, so there is surely no point in reminding - but I'll do it anyway. Have you emailed the GNU forms yet?23:24
blueCmdpoke53281: your thing boots quicker than dalias's23:25
poke53281I hope so.23:25
poke53281with or without decompression of the filesystem?23:26
blueCmdpoke53281: whatever is default23:26
blueCmdpoke53281: looking at, this could be pretty cool for kernel module programming and stuff23:27
blueCmdit might even be possible to create a VPI/DPI interface to a verilator instance.. hmm23:28
poke53281well, it is cool for teaching programming with life examples.23:28
blueCmdhaving a certain memory area and a couple of IRQs connected to verilator23:29
blueCmdthat could be quite cool23:29
poke53281and yes, even kernel programming.23:29
poke53281who wants to write a tutorial for programming  based on such an online emulator?23:29
blueCmdstekern: simple test case does *not* crash with your patch23:30
blueCmdstekern: thanks x100. this was getting really off-putting23:30
blueCmdpoke53281: imagine gdb integration as well23:31
poke53281does gdb compile?23:31
poke53281Last time I had problems23:31
poke53281I plan also to give the user a lot more statistics in future.23:32
poke53281like number of page faults, number of syscalls and so on.23:32
poke53281It would be also funny to "acccidentally" link the ata block device with the framebuffer.23:33
poke53281That you can "see", how such a filesystem works.23:34
blueCmdpoke53281: nope, I don't think it does23:37
blueCmdpoke53281: cool!23:37
--- Log closed Fri Aug 01 00:00:45 2014

Generated by 2.15.2 by Marius Gedminas - find it at!