| blueCmd | _franck_: *facepalm* sorry for not looking there first | 00:23 |
|---|---|---|
| _franck_ | :) no problem | 00:28 |
| _franck_ | irc is faster sometimes | 00:28 |
| _franck_ | about this: http://pastebin.com/xHVm6wRj | 00:28 |
| _franck_ | -lboard-or1ksim | 00:28 |
| _franck_ | do you think we should change this and always add -lboard-or1ksim without condiction on -static ? | 00:29 |
| _franck_ | I mean -lboard-%* | 00:29 |
| _franck_ | is there any reason for not doing it ? | 00:29 |
| blueCmd | does it work? | 00:44 |
| blueCmd | if so, add it | 00:44 |
| blueCmd | i can't see any reason not to add it | 00:44 |
| _franck_ | yes it works | 00:44 |
| _franck_ | me too, I'll it | 00:44 |
| _franck_ | *add | 00:44 |
| _franck_ | unexpected failures from 227 to 122 ! :) | 00:57 |
| _franck_ | better than the stable GDB 7.2 | 00:58 |
| blueCmd | _franck_: great work! | 01:06 |
| blueCmd | _franck_: any reason not to commit these groups to git? | 01:07 |
| _franck_ | well I was waiting for my openocd work to be applied... | 01:08 |
| _franck_ | but as those openocd folks are not the kind of person willing to apply other people patchs I'm not sure or1k openocd will be official some day | 01:08 |
| _franck_ | I'll push my openocd or1k v2 port (because it is so different from the version on openrisc github) | 01:09 |
| _franck_ | then I'll commit my tdesc patches to gdb | 01:09 |
| blueCmd | _franck_: ah ok. well I'm basing my linux port around this xml stuff now so It would be nice to have in the repo i think | 01:11 |
| _franck_ | ok, I'll push that | 01:12 |
| _franck_ | you'll show me what you did to use the xml file in place (I mean I always got it from the remote) | 01:13 |
| blueCmd | _franck_: i haven't figured it all out, but the XML files are used to generate tdesc-c-files I use | 01:14 |
| _franck_ | yes and it's just matter of adding some lines in makefiles to get this tdesc c file generated ? | 01:15 |
| blueCmd | yes | 01:53 |
| blueCmd | hah, fixing a few things in my testsuite environment shows gcc regressions are also down - all those uClibc-related + TLS now pass with eglibc \o/ | 02:38 |
| poke53281 | great | 02:42 |
| poke53281 | I am looking forward to compile some more complex stuff for my javascript or1k emulator. | 02:48 |
| blueCmd | poke53281: :D cool! | 10:32 |
| LoneTech | I do not recall any or1200-elf toolchain | 10:53 |
| blueCmd | jonibo: do you remember if you ever implemented orig_r11 ? all I see now is the skeleton and no code that fills it | 12:36 |
| jonibo | blueCmd: orig_r11 is implemented... | 13:55 |
| jonibo | but... | 13:55 |
| jonibo | I think you've got an old kernel... 3.4 or so right? | 13:56 |
| jonibo | it's not in there | 13:56 |
| jonibo | I've got a complete rework of the signal handling out of tree (or in "wip" directory, maybe?) | 13:56 |
| jonibo | I noticed you were on an old kernel yesterday when looking at your patch | 13:56 |
| jonibo | I was going to get you to move to a later one, but I wanted to get one showstopper fixed before directing you to it | 13:57 |
| jonibo | ...and it took all evening and all morning to sort out | 13:57 |
| jonibo | now that's almost done... so I'll hopefully direct you toward a newer kernel later today | 13:57 |
| jonibo | there's a lot of churn in the signal handling right now due to upstream changes | 13:58 |
| stekern | blueCmd: regarding cgen, this is the history behind the toolchain in one sentence (from my understaning when I did digging on it last): around 2000 Johan Rydberg submitted the openrisc target, that was cgen based. Around a year after that Ivan Guzvinec submitted the or32 target, that was completely decoupled from the work already started by Rydberg for some reason. Then Julius picked up the old openrisc toolchain, fixed it up so we again have a cgen based toolchain. | 16:36 |
| stekern | (ok, it was a bit more than one sentence, but almost) | 16:37 |
| stekern | =P | 16:37 |
| stekern | jonibo: blueCmd was sniffing on a newer kernel earlier (I adviced him to), but he had some problems with ethoc on that iirc. | 16:39 |
| LoneTech | stekern: got cut off at "fixed it up so we again h" | 16:54 |
| stekern | ave a cgen based toolchain | 17:12 |
| stekern | juliusb: looks like the or1k-timer test gives a false negative if bus accesses are slow | 17:14 |
| stekern | the tickloop has similiar problems, to that I already have a patch | 17:15 |
| stekern | http://pastie.org/6164411 | 17:16 |
| blueCmd | jonibo: in the kernel it's implemented yes, but it's not exported via ptrace, right? | 17:17 |
| blueCmd | stekern: jonibo: that's right, never got eth0 to work. i patched the kernel so it was detected but never succeeded in negotations | 17:19 |
| blueCmd | jonibo: I started working with 3.6.10 but had to move down to 3.4 since that worked with ethoc | 17:20 |
| blueCmd | _franck_: I have a rundamentary gdbserver for or1k*linux working quite nicely now | 17:40 |
| blueCmd | _franck_: if you could merge your things to mainline so I can merge mine upon that, that would be stellar | 17:41 |
| _franck_ | blueCmd: ok, I'll try to do that asap | 18:36 |
| poke53281 | jonibo: Thanks for the patch of the self modifying code. Otherwise I would have send a similar patch myself in the next few days. | 19:12 |
| blueCmd | jonibo: i always need to patch this from mainline: "arch/openrisc/kernel/entry.S:1053: Error: unresolved expression that must be resolved" | 20:28 |
| blueCmd | it's a compile error and I'm surprised noone has removed it | 20:29 |
| blueCmd | *sigh* my bad, this was something else. I just assumed it was the same old thing I needed patch in the old kernel | 20:30 |
| blueCmd | jonibo: the TI_STACK macro, maybe I'm just blind (and/or tierd) - but I cant find it defined anywhere | 20:32 |
| blueCmd | (that's the compile error) | 20:43 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!