IRC logs for #openrisc Sunday, 2014-04-20

--- Log opened Sun Apr 20 00:00:13 2014
stekernblueCmd: what does the __tls_get_addr look like? and where does that come from?05:48
* stekern is trying to accidently learns some tls stuff at the same time05:49
stekernI found the question to the other question myself:
stekernyou might want to change that AArch64 comment to or1k ;)05:54
stekernbut how can that clobber r3?05:55
stekernor I mean... of course it can...06:05
stekernbut what call site doesn't understand to save r3 if it needs it later?06:05
stekernbecause, at least mpf_const_catalan doesn't use/need the value in r3 after the call to __tls_get_addr06:09
stekernah, nnm, now I see it. the call to mpfr_cache eluded me06:11
stekernyeah, that definetely looks like a gcc bug06:14
blueCmdstekern: yes, since I emit the call to tls_get_addr "internally" apparently it doesn't understand to save those regs08:52
blueCmdI did a quick hack and saved r3 and r9 and it crashed much later, so I guess I need to save r3-r11.08:53
blueCmdwhat I'm currently doing is trying to get gcc to emit a real function call, so I don't have to hack08:53
stekernor.. the caller-saved regs (which are not r3-r11)08:54
stekernyeah, that sounds like a more correct way to do it08:54
stekern...and ok, I see now how the __tls_get_addr call is generated from gcc09:04
blueCmdstekern: regarding the comments, yes the glibc code is frankenstein atm09:14
stekernwith the problem with the deprecated syscalls withdrawn, the musl porting experience have been a breeze so far09:56
stekernupdating the arch spec on the contrary hasn't, it has took almost as long time updating that as implementing the l.lwa/lswa instructions09:58
stekern...we really should move away from .odt09:58
blueCmdgah, gcc's damn .md files - they are confusing as f*ck10:00
stekernyou don't say10:00
stekernI can't count the number of times I've went "ah, now I get it!, I don't" =)10:01
blueCmd"error: unrecognizable insn:" *sigh*10:02
stekernllvm's .td files are a bit confusing at first too, but they actually start to make sense after a while10:04
stekernoh, just noticed, simoncook have pushed some updates lately10:04
blueCmdI honestly have no idea how to solve this11:01
blueCmdI could hack __tls_get_addr to save all regs, but that would be a huge hack and in glibc11:01
blueCmdI cannot make gcc emit a real function call11:01
blueCmd../../src/const_catalan.c:153:1: internal compiler error: in distribute_notes, at combine.c:1317611:09
stekernbut why doesn't that 'emil_library_call' do the 'right thing'?11:15
blueCmdstekern: beats me11:17
blueCmdstekern: the function appears to have support for protecting parameters on the stack, but not for regs as far as I can see11:26
stekernhmm, where do you see that?11:29
blueCmdgcc/calls.c emit_library_call_value_1 (warning: large function)11:30
stekernhmm, wonder if you need to do the same kind of silly things as you have to do for varargs?11:37
stekernor rather, the silly things you would have to do for varargs if you don't have the abi for varargs that we have11:39
blueCmdhm, varargs passes everything on stack or just after reg >X ?11:40
blueCmdI don't recall11:40
stekernto elaborate, in gcc if you pass arguments in registers to vararg functions you still have to emit instructions to save those to the stack (since that's what gcc expects)11:41
stekernor1k varags ABI is: pass everything on the stack11:42
stekernwhich is a bit unfortunate, because that makes our vararg ABI incompatible with our static arg abi11:42
blueCmdright yes11:42
blueCmdglibc has overrides for a lot of functions due to that (called as a non-vargs, defined as vargs)11:43
stekernwhat I'm now getting at is, perhaps the libcall logic follows the same scheme in gcc, gcc code perhaps expect that all args are on the stack. And the archs that differ from that, need to do "special things" to get around that assumption.11:44
stekernhow does other archs handle the libcalls?11:44
blueCmdevery one has their own different way that is in some way incompatible or super-ugly11:45
stekernhaha, sounds like gcc alright11:46
stekernbut perhaps the reason for that is something along what I guessed11:47
blueCmdbut having it defined as a vargs should be possible11:47
blueCmdbut I don't know if tha solves stuff11:47
stekernanyway, gotta start packing for the trip back home, I'll read the backlogs later.11:47
blueCmdstekern: he had the same problem, no solution posted :P13:03
stekernhmm, yeah... but there has to be some way to be able to insert some kind of 'marker' that the libcall is a function call16:49
stekernand it's still surprising that the emit_... call doesn't act as such on it's own16:50
stekernbecause I think my whole vararg rambling made no sense, it should be enough that you make a call for the caller-saved regs to be in danger16:52
stekernno matter what kind of calling convention is used16:55
stekernbut didn't you say that it did work with -O0?17:20
stekernwhat's the asm output then?17:20
stekernI'm just thinking if it's some optimization that is getting a bit too aggressive, then we should try to pinpoint which one17:22
stekernanother thing worth investigating is, at what point is the libcall emitted? could it be 'too late'?17:24
olofkLimb: You are using the same name for the timespec and the timing name19:06
olofkThe syntax for timespec in this case is "TIMESPEC <timespec name> = PERIOD <timing name> <Frequency>;19:07
olofkSo try to change that to TIMESPEC TS_dbg_clk = PERIOD dbg_tck_pin 100 KHz;19:08
olofkHmm... isn't chipscope available in the ISE webpack license?19:15
olofkI'm not looking forward to debugging my wb_ram with four leds19:16
blueCmdstekern: doesn\t work with either -O0 or -O319:19
blueCmdi thought optimization was to blame for this, but the same number of tests fail with -O3 as with -O019:20
--- Log closed Mon Apr 21 00:00:14 2014

Generated by 2.15.2 by Marius Gedminas - find it at!