| --- Log opened Sun Apr 20 00:00:13 2014 | ||
| stekern | blueCmd: 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 time | 05:49 | |
| stekern | I found the question to the other question myself: https://github.com/bluecmd/or1k-glibc/blob/master/ports/sysdeps/or1k/libc-tls.c#L28 | 05:53 |
| stekern | you might want to change that AArch64 comment to or1k ;) | 05:54 |
| stekern | but how can that clobber r3? | 05:55 |
| stekern | or I mean... of course it can... | 06:05 |
| stekern | but what call site doesn't understand to save r3 if it needs it later? | 06:05 |
| stekern | because, at least mpf_const_catalan doesn't use/need the value in r3 after the call to __tls_get_addr | 06:09 |
| stekern | ah, nnm, now I see it. the call to mpfr_cache eluded me | 06:11 |
| stekern | yeah, that definetely looks like a gcc bug | 06:14 |
| blueCmd | stekern: yes, since I emit the call to tls_get_addr "internally" apparently it doesn't understand to save those regs | 08:52 |
| blueCmd | I 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 |
| blueCmd | what I'm currently doing is trying to get gcc to emit a real function call, so I don't have to hack | 08:53 |
| stekern | or.. the caller-saved regs (which are not r3-r11) | 08:54 |
| stekern | yeah, that sounds like a more correct way to do it | 08:54 |
| stekern | ...and ok, I see now how the __tls_get_addr call is generated from gcc | 09:04 |
| blueCmd | stekern: regarding the comments, yes the glibc code is frankenstein atm | 09:14 |
| stekern | haha | 09:55 |
| stekern | with the problem with the deprecated syscalls withdrawn, the musl porting experience have been a breeze so far | 09:56 |
| stekern | updating the arch spec on the contrary hasn't, it has took almost as long time updating that as implementing the l.lwa/lswa instructions | 09:58 |
| blueCmd | haha | 09:58 |
| stekern | ...we really should move away from .odt | 09:58 |
| blueCmd | gah, gcc's damn .md files - they are confusing as f*ck | 10:00 |
| stekern | you don't say | 10:00 |
| stekern | I can't count the number of times I've went "ah, now I get it! ...no, I don't" =) | 10:01 |
| blueCmd | "error: unrecognizable insn:" *sigh* | 10:02 |
| stekern | llvm's .td files are a bit confusing at first too, but they actually start to make sense after a while | 10:04 |
| stekern | oh, just noticed, simoncook have pushed some updates lately | 10:04 |
| blueCmd | I honestly have no idea how to solve this | 11:01 |
| blueCmd | I could hack __tls_get_addr to save all regs, but that would be a huge hack and in glibc | 11:01 |
| blueCmd | I cannot make gcc emit a real function call | 11:01 |
| blueCmd | ../../src/const_catalan.c:153:1: internal compiler error: in distribute_notes, at combine.c:13176 | 11:09 |
| stekern | but why doesn't that 'emil_library_call' do the 'right thing'? | 11:15 |
| blueCmd | stekern: beats me | 11:17 |
| blueCmd | stekern: the function appears to have support for protecting parameters on the stack, but not for regs as far as I can see | 11:26 |
| stekern | hmm, where do you see that? | 11:29 |
| blueCmd | gcc/calls.c emit_library_call_value_1 (warning: large function) | 11:30 |
| stekern | hmm, wonder if you need to do the same kind of silly things as you have to do for varargs? | 11:37 |
| stekern | or rather, the silly things you would have to do for varargs if you don't have the abi for varargs that we have | 11:39 |
| blueCmd | hm, varargs passes everything on stack or just after reg >X ? | 11:40 |
| blueCmd | I don't recall | 11:40 |
| stekern | to 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 |
| stekern | or1k varags ABI is: pass everything on the stack | 11:42 |
| stekern | which is a bit unfortunate, because that makes our vararg ABI incompatible with our static arg abi | 11:42 |
| blueCmd | right yes | 11:42 |
| blueCmd | glibc has overrides for a lot of functions due to that (called as a non-vargs, defined as vargs) | 11:43 |
| stekern | what 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 |
| stekern | how does other archs handle the libcalls? | 11:44 |
| blueCmd | every one has their own different way that is in some way incompatible or super-ugly | 11:45 |
| stekern | haha, sounds like gcc alright | 11:46 |
| stekern | but perhaps the reason for that is something along what I guessed | 11:47 |
| blueCmd | but having it defined as a vargs should be possible | 11:47 |
| blueCmd | but I don't know if tha solves stuff | 11:47 |
| stekern | anyway, gotta start packing for the trip back home, I'll read the backlogs later. | 11:47 |
| stekern | bbl | 11:47 |
| blueCmd | stekern: http://www.unknownerror.org/Problem/index/-2000453944/program-crash-after-modification-on-gcc-and-gcov/ he had the same problem, no solution posted :P | 13:03 |
| stekern | hmm, yeah... but there has to be some way to be able to insert some kind of 'marker' that the libcall is a function call | 16:49 |
| stekern | and it's still surprising that the emit_... call doesn't act as such on it's own | 16:50 |
| stekern | because 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 danger | 16:52 |
| stekern | no matter what kind of calling convention is used | 16:55 |
| stekern | but didn't you say that it did work with -O0? | 17:20 |
| stekern | what's the asm output then? | 17:20 |
| stekern | I'm just thinking if it's some optimization that is getting a bit too aggressive, then we should try to pinpoint which one | 17:22 |
| stekern | another thing worth investigating is, at what point is the libcall emitted? could it be 'too late'? | 17:24 |
| olofk | Limb: You are using the same name for the timespec and the timing name | 19:06 |
| olofk | The syntax for timespec in this case is "TIMESPEC <timespec name> = PERIOD <timing name> <Frequency>; | 19:07 |
| olofk | So try to change that to TIMESPEC TS_dbg_clk = PERIOD dbg_tck_pin 100 KHz; | 19:08 |
| olofk | Hmm... isn't chipscope available in the ISE webpack license? | 19:15 |
| olofk | I'm not looking forward to debugging my wb_ram with four leds | 19:16 |
| blueCmd | stekern: doesn\t work with either -O0 or -O3 | 19:19 |
| blueCmd | i thought optimization was to blame for this, but the same number of tests fail with -O3 as with -O0 | 19:20 |
| --- Log closed Mon Apr 21 00:00:14 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!