| -!- mbuf` is now known as mbuf | 09:25 | |
| stekern | hmm, I need to compile libgcc with clang (more precisely crtstuff.c to get a -fPIC compiled crtbeginS.o), can I do that with the (G)CC_FOR_TARGET env vars? | 09:37 |
|---|---|---|
| stekern | ok, managed to build them, but in the ugliest way possible... | 11:02 |
| juliusb | ewww, compiling libgcc with clang hey? | 12:46 |
| juliusb | has no one done this linking business for an embedded target before with LLVM? | 12:46 |
| stekern | probably, but most likely they have gcc with PIC support ;) | 12:50 |
| stekern | rolling your own crtbegin/end is not hard though, I think there even are some freebsd ones, but I don't mind using the ones in libgcc | 12:51 |
| stekern | and I only need the crtbegin/end from libgcc, all other things are in compiler-rt | 12:52 |
| stekern | hmm, things doesn't work well on my 32-bit machine | 13:25 |
| stekern | or1k-linux-as screams about operand out of range | 13:27 |
| stekern | on all l.bf -offset | 14:14 |
| stekern | it interprets it as an very large positive offset | 14:14 |
| stekern | juliusb: you were using a 32-bit machine when you played around with the cgen assembler, right? | 14:16 |
| juliusb | stekern: yep, no 64bit machines in my posession | 15:10 |
| stekern | :) | 15:11 |
| stekern | isn't the amazon a 64-bit? | 15:11 |
| juliusb | oh yes but i never did work on it | 15:14 |
| juliusb | just to host | 15:14 |
| stekern | ok, I'll try to bisect what has broke it then | 15:15 |
| juliusb | care to pastebin the actual barf? | 15:19 |
| stekern | juliusb: ../test.S:12: Error: operand out of range (1073741820 not between -33554432 and 33554431) | 16:50 |
| stekern | I've bisected it down to https://github.com/pgavin/or1k-src/commit/339c6fde3333d9674c64ffc5c0e5fcfbe5563da8 | 16:51 |
| stekern | but it's probably a commit before that that actually contains the change | 16:52 |
| juliusb | stekern: and what is test.S:12? | 17:29 |
| juliusb | an l.branch immediate? | 17:29 |
| stekern | l.bf 1b | 17:29 |
| juliusb | kk | 17:30 |
| stekern | and 1: is a couple of instructions above | 17:30 |
| juliusb | ohhh ok, should be a label | 17:30 |
| juliusb | not an immediate | 17:30 |
| juliusb | so labels backwards don't work at all? | 17:30 |
| stekern | exactly | 17:31 |
| juliusb | oh, but is it that the immediate is getting generated correctly but the assembler says it's out of range? | 17:31 |
| juliusb | where would the error be? in the compiler generating the immediate? | 17:31 |
| stekern | and only on 32 | 17:31 |
| stekern | no, it's in the assembler | 17:31 |
| juliusb | OK, so the compiler generates 1b? | 17:32 |
| juliusb | or it's not being generated by the compiler? | 17:32 |
| stekern | I have a pure .S as test case | 17:32 |
| stekern | it doesn't matter if the label is foo: | 17:32 |
| juliusb | hmm | 17:33 |
| stekern | and I think the immediate is 30 bits and the expected is 26 | 17:33 |
| juliusb | I'm just looking through the CGEN changes he committed wondering if it's to do with them | 17:33 |
| stekern | I'm typing on my phone so it's hard for me to check, but it should show from the error message | 17:34 |
| stekern | I'm not sure what the correct is, it could be 28 before shifting or 26 after | 17:37 |
| juliusb | :) | 17:38 |
| juliusb | Phone keyboard tying sucks | 17:39 |
| juliusb | But, it looks like we have this for the processing of a 26-bit immediate: | 17:39 |
| juliusb | ((value pc) (sra WI (sub WI value pc) (const 2))) | 17:39 |
| juliusb | ((value pc) (add WI (sll WI value (const 2)) pc))) | 17:39 |
| juliusb | I forget why we have 2 things there, 2 actual arithmetic steps I geuss? | 17:41 |
| juliusb | and I even forget how it works | 17:41 |
| juliusb | that appears to be a common way of doing it | 17:49 |
| juliusb | take immediateValue - PC, arithmetic shift right 2 | 17:50 |
| juliusb | (does that get stored as the target PC?) | 17:50 |
| stekern | I guess this is the actual commit that contains the change: https://github.com/pgavin/or1k-src/commit/1d4d4eac0d93d514ad37db18cf04c542062d51b9 | 17:50 |
| juliusb | (inbetween) | 17:51 |
| juliusb | yeah i'm looing at that commit now | 17:51 |
| stekern | ah, ok | 17:51 |
| juliusb | although, all he did was change formatting on the df f-disp26 line | 17:51 |
| stekern | yeah, I didn't see anything obvious when quickly browsing through (on the phone) | 17:52 |
| juliusb | but basically, it takes the difference, eg if you were PC 0x1080 and the immediate was written as -4, I guess it goes sra((0xfffffffc - 0x1080), 2) | 17:58 |
| juliusb | which is 0xffffef7c, so sra(0xfffef7c,2) is 0xfffffbdf | 17:59 |
| juliusb | and I guess this then gets used in the next calculation, which is add ( sll(0xfffffbdf,2), 0x1080) | 18:00 |
| juliusb | which is 0xfffffffc | 18:01 |
| juliusb | so.... | 18:01 |
| juliusb | there appears to be no masking info there, other than the bit width of the way it's encoded into the instructino (starting at bit 25, is 26 bits long) | 18:02 |
| juliusb | what is a bit odd is that we don't indicate that it's signed | 18:02 |
| juliusb | like i yuo look a bit further down, you see that there's something where u declare that (df ... blahblah) stuff and you say it's a PCREL-ADDR in the case of f-disp26 but for f-simm16 you say ((MACH ORBIS-MACHS) SIGN-OPT) | 18:03 |
| juliusb | but, perhaps PCREL-ADDR assumes signed, I think it would be silly not to, right? | 18:03 |
| juliusb | so then probaly PCREL is OK | 18:03 |
| juliusb | and that weird sra process looks like it's getting done elsewhere | 18:04 |
| juliusb | I mean, in other architectures in CGEN | 18:04 |
| juliusb | I could have interpreted what the CGEN code does completly wrong, though :( | 18:05 |
| juliusb | I can't remember exactly how it works now | 18:05 |
| juliusb | ahhh, top one is encode algorith, bottom one is decode algorithm | 18:15 |
| juliusb | the mode, INT, is right, it's signed, as the only laternative is UINT, which clearly is unsigned | 18:15 |
| stekern | yeah, and that logic didn't change anyway | 18:21 |
| stekern | the only actual change on that row is the addition of the MACH_ORBIS | 18:22 |
| juliusb | it still could be something which never worked on 64-bit | 18:23 |
| juliusb | I mean, the way the encode/decode is specified | 18:23 |
| juliusb | the documentation has this example for a very similar thing: | 18:23 |
| juliusb | [A[A[AExample: | 18:23 |
| juliusb | 18:24 | |
| juliusb | (df f-disp8 | 18:24 |
| juliusb | "disp8, slot unknown" (PCREL-ADDR) | 18:24 |
| juliusb | 8 8 INT | 18:24 |
| juliusb | ((value pc) (sra WI (sub WI value (and WI pc (const -4))) (const 2))) | 18:24 |
| juliusb | ((value pc) (add WI (sll WI value (const 2)) (and WI pc (const -4))))) | 18:24 |
| juliusb | This defines a field called ‘f-disp8’ that is a signed PC-relative address beginning at bit 8 of size 8 bits that is left shifted by 2. | 18:24 |
| juliusb | and ours, for those following at home, is: | 18:24 |
| juliusb | ((value pc) (sra WI (sub WI value pc) (const 2))) | 18:24 |
| juliusb | ((value pc) (add WI (sll WI value (const 2)) pc))) | 18:24 |
| juliusb | they appear to mask their PC before doing the subtract | 18:24 |
| juliusb | and before doing the add | 18:25 |
| juliusb | but the immediate it's complaining about: 1073741820, is 30-bits | 18:27 |
| juliusb | (0x3ffffffc) | 18:27 |
| juliusb | so even shifted right by two for encoding it's still too big | 18:27 |
| stekern | never worked on 64-bit? it's not working on 32-bit | 18:28 |
| juliusb | oh sorry, I thought you said it's not working on 64-bit | 18:28 |
| juliusb | there must be backwards branches going on in the testsuite though, somewhere! | 18:28 |
| stekern | it works fine on 64-bit | 18:28 |
| juliusb | ahhh | 18:28 |
| juliusb | I got it around the wrong way then, sorry | 18:28 |
| juliusb | does it work if you do l.bf -4? | 18:29 |
| juliusb | but not if you do l.bf backwards_label? | 18:29 |
| stekern | and it works on 32-bit before that commit I bisected down to | 18:30 |
| juliusb | I see a diffrence in the way the PC is defined | 18:31 |
| juliusb | he's added a "type pc UWI" in the fuller definition | 18:31 |
| juliusb | let me look up what that menas | 18:31 |
| juliusb | mmm | 18:32 |
| stekern | same result with l.bf -4 | 18:32 |
| juliusb | yes, that's an interesting change | 18:32 |
| juliusb | he's declared the PC as unsigned | 18:32 |
| juliusb | which, I guess is true | 18:32 |
| juliusb | but maybe it screws with some of the arithmetic? | 18:32 |
| stekern | sounds like an candidate at least | 18:33 |
| stekern | where's that change? | 18:33 |
| stekern | in what file and what was it before? | 18:34 |
| juliusb | cpu/or1kcommon.cpu | 18:36 |
| juliusb | and try changing (type pc UWI) to just (type pc) | 18:36 |
| juliusb | I've no idea if this agood idea or not, but... :) | 18:36 |
| juliusb | it's worth a try | 18:36 |
| juliusb | I'm not sure I've built this toolchain recently | 18:36 |
| juliusb | I've managed to convince work to use OpenOCD for something | 18:37 |
| juliusb | so I've been having fun hacking on that lately, is kinda nice | 18:37 |
| juliusb | but it's for ARM stuff :( | 18:37 |
| juliusb | but have at least been playing with something open source | 18:37 |
| juliusb | and convincing them to go with a nice open source soloution instead of forking out thousands per desk for over the top proprietary debugging solutions | 18:38 |
| juliusb | at least, evaluate it | 18:38 |
| stekern | convincing the customer I work for to use open source is like banging your head against a waöll ;) | 18:41 |
| juliusb | it's in a way a skunkwords | 18:47 |
| juliusb | skunkworks | 18:47 |
| stekern | reverting the pc change didn't cut it | 18:49 |
| juliusb | :-/ | 18:51 |
| stekern | I've found the change among the regenerated ones | 20:01 |
| stekern | - value = ((SI) (((value) - (pc))) >> (2)); | 20:01 |
| stekern | + value = ((DI) (((value) - (pc))) >> (2)); | 20:01 |
| stekern | not sure what change make it generate that though | 20:02 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!