| blueCmd | _franck_: wzup? | 00:21 |
|---|---|---|
| _franck_ | you may have an idea about my problem: why do I need to add -lboard-or1ksim to get a program compile (almost) ok while using -static -mnewlib -mboard=or1ksim ? | 00:23 |
| _franck_ | doesn't the board lib linked automatically ? | 00:23 |
| _franck_ | plus, after that I still have: /opt/or1k-toolchain/lib/gcc/or1k-elf/4.8.0/../../../../or1k-elf/bin/ld: warning: cannot find entry symbol 0x100-static; defaulting to 00002028 | 00:24 |
| blueCmd | sorry, no idea about newlib magic but perhaps it's possible to have multiple boards installed? sounds weird though | 00:24 |
| _franck_ | yes it's possible to have more than one board but it should default to or1ksim | 00:25 |
| blueCmd | yeah it should | 00:25 |
| blueCmd | seems it forbids static though | 00:26 |
| blueCmd | gcc/config/or1k/or1k.h line 75 | 00:26 |
| blueCmd | (ish) | 00:26 |
| blueCmd | seems it adds -lboard-or1ksim if mboard is missing and if you're not using static linking | 00:27 |
| _franck_ | don't understand that line :) but I can see !static | 00:28 |
| _franck_ | ok | 00:28 |
| _franck_ | any idea on the warning ? | 00:29 |
| blueCmd | ah, yeah gcc spec lines are a bit weird, but it means if the first match then do the thing after the ":" | 00:29 |
| blueCmd | regarding the warning, you could do a standard "grep 0x100-static -R /where/you/install/gcc" | 00:31 |
| blueCmd | it should show which files contain that entrypoint, hopefully some crti.o or something like that | 00:31 |
| blueCmd | you probably get loads of matches though so you might want to grep that output as well | 00:32 |
| _franck_ | no, gives me nothing | 00:34 |
| _franck_ | #define LINK_SPEC "%{mnewlib:-entry 0x100}%{static:-static}%{shared:-shared}" | 00:40 |
| _franck_ | can 0x100 be concatened with static here ? | 00:40 |
| blueCmd | aha | 00:41 |
| blueCmd | no | 00:41 |
| blueCmd | well yes :P | 00:41 |
| _franck_ | :) | 00:41 |
| blueCmd | add a space | 00:41 |
| blueCmd | _franck_: you told me you couldn't read them! ;) | 00:42 |
| _franck_ | well, now I can :) almost... | 00:42 |
| blueCmd | _franck_: heh, don't ask me how it's parsed though. it's gcc black magic, quite useful though | 00:43 |
| _franck_ | looks like it did the trick | 01:03 |
| andresjk | hi there | 01:04 |
| _franck_ | hi andresjk | 01:04 |
| andresjk | does anyone knows if there is a list of the libraries and functions supported by or32-elf-gcc? im looking for scanf, and some math functions | 01:05 |
| _franck_ | those function are supported by newlib so I guess you should look at newlib doc | 01:06 |
| andresjk | yeah, your right. thanks | 01:08 |
| jeremybennett | blueCmd: We need to retain or32 for the time being. I see no reason why the config cannot have both or32 and or1k. | 10:39 |
| jeremybennett | We are surprised when we make a change like this quite how large the legacy user base is. Remember OR1K is in orbit in TechEdSat and in Samsung Set Top Boxes. All these people are using the or32 tool chain. | 10:40 |
| jeremybennett | So we have to manage any transitions properly. OR1K is no longer a research curiosity used by a handful of people! | 10:40 |
| blueCmd | jeremybennett: sounds good, what do you think about the fallback? I suppose there is no harm in having openrisc-*-*-* fall back to or32-*-*-* since the new name uses or1k-*-*-* anyway | 11:10 |
| jonibo | why do you want to add openrisc-*-*-*? | 11:23 |
| jonibo | that doesn't seem to be in line with how things have been handled earlier... or1k-*-*-* is what it should be. | 11:24 |
| jonibo | that's or???? where ??? is some qualifier for the particular variant of the openrisc family... like 1k, 2k, 1knd, etc. | 11:25 |
| blueCmd | jonibo: it is already there | 11:41 |
| blueCmd | but is an alias for or32 | 11:41 |
| jonibo | right... that's from the _old_ toolchain.... written about 10 years ago | 11:41 |
| jonibo | i'd rip out openrisc-*-*-* altogether | 11:41 |
| blueCmd | ah that makes sense | 11:41 |
| jonibo | nobody uses it | 11:41 |
| blueCmd | good, then we will leave it. | 11:41 |
| blueCmd | Is it ok if I simply send a patch to add or1k? | 11:42 |
| jonibo | as far as I'm concerned, yes | 11:42 |
| blueCmd | should I send something to the mailinglist about it? | 11:42 |
| jonibo | yes, probably should | 11:42 |
| jonibo | our toolchain isn't upstream anyway so I don't see why we worry so much about compatibility while getting it into good shape... i'd rip out or32-*-* as well. | 11:44 |
| jonibo | leave just or1k-*-* | 11:44 |
| jonibo | it's not like this is integrated into a bunch of build systems that are going to break | 11:44 |
| jonibo | nothing "public", in any case | 11:44 |
| jonibo | and for everybody else it's a trivial fix | 11:45 |
| blueCmd | jonibo: jeremybennett meant that the old or32 toolchain is used in a number of installations, it would be bad to alienate them I think | 11:45 |
| jonibo | yeah, but it's two projects and they use GCC 4.5 | 11:46 |
| jonibo | big deal if they need to change the triple when moving to a later toolchain | 11:46 |
| jonibo | if this stuff was upstream, I would agree... but it's a work in progress | 11:46 |
| jonibo | ...what's the status of getting the toolchain upstream anyway? | 11:46 |
| jonibo | and I agree with your point above... since arm64 is asking projects to regenerate with a new config.sub, now would be a good time to get or1k-* into autotools and ride the wave of autoreconf's | 11:47 |
| jonibo | ...if autools wants a triple for an arch that's not in any upstream toolchain, that its. | 11:48 |
| blueCmd | I don't know, but it doesn't really need to be as far as I'm concerned. I want to start porting debian packages in a while and then I predict that updating config.sub will be the major work | 11:48 |
| jonibo | it will be a major pain in the ass... ask the aarch64 people | 11:48 |
| blueCmd | yes, they have done a looot of work to ease this though | 11:48 |
| blueCmd | I'm glad I didn't get this idea last year | 11:48 |
| jonibo | heh | 11:48 |
| jonibo | have you already checked with autotools if they'll take the triple now? if not, it might be a good idea to run that past them... would be good if they'd take or1k-*-* | 11:51 |
| jonibo | ...even though there's no upstream toolchain | 11:51 |
| jeremybennett | blueCmd: jonibo is right that openrisc-*-* is obsolete. | 11:52 |
| blueCmd | jonibo: well, I guess that we will find out when the patch is sent to them ,no? is that being an asshole? | 11:52 |
| jeremybennett | However you should have two entries, one for or32-*-* which is still the stable tool chain and one for or1k-*-* which is the development tool chain. | 11:52 |
| jonibo | blueCmd: no, that's exactly the right way to do it! | 11:52 |
| jonibo | don't add or32-*-* to upstream autools | 11:53 |
| jonibo | we want that thing to die | 11:53 |
| jeremybennett | We want to move to or1k, because that is the right naming. | 11:53 |
| blueCmd | jonibo: jeremybennett fight whenever I should remove or32 :-) | 11:53 |
| jeremybennett | I agree with not pushing or32 upstream. | 11:53 |
| jeremybennett | I'm just saying that don't kill all things or32. | 11:54 |
| blueCmd | it's already upstream so we're looking at a removal of it then | 11:54 |
| jonibo | i think we agree... or1k-* upstream and or32-* for now in the toolchain | 11:54 |
| jonibo | or32 is upstream? | 11:54 |
| jonibo | openrisc, too? | 11:54 |
| blueCmd | yepp | 11:54 |
| blueCmd | http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD | 11:54 |
| jonibo | ok, then the patch should remove two and add one | 11:54 |
| blueCmd | grep or32 / openrisc | 11:54 |
| jonibo | :) | 11:54 |
| jonibo | yup, got it | 11:54 |
| jonibo | I think I actually knew that... had blocked it out | 11:55 |
| jeremybennett | I really wouldn't worry about killing it. Remember there are some parts of the tool chain that are upstream, and we won't garner any favours by breaking them. | 11:55 |
| jeremybennett | (openrisc is in FSF binutils). | 11:55 |
| blueCmd | i'm with jeremybennett | 11:55 |
| jonibo | yeah, but that openrisc stuff should just be ripped out | 11:55 |
| jonibo | it's not cmpatible with anything that actually exists | 11:55 |
| jonibo | not even or1ksim | 11:55 |
| jeremybennett | jonibo: I'm not defending it, just I don't want to create unnecessary work. The trouble is every time we make a change like that we discover a bucket load of people who actually have been using it for the past 10 years. | 11:56 |
| jeremybennett | So just leave the obsolete stuff there. The important thing is to get or1k in there. | 11:56 |
| jonibo | I think it would be nice to know who's using it... rip it out and we'll find out when they start screaming... but i'll bet you nobody screams because there are no users who will actually notice | 11:57 |
| jonibo | ...and if there are users, we put it back quickly | 11:57 |
| jeremybennett | jonibo: The trouble is that when they scream, they look for names associated with the tool chain, application notes etc, and all the email comes my direction! | 11:58 |
| jonibo | :) | 11:58 |
| jeremybennett | I still get angry emails about GDB 5.0! | 11:58 |
| jonibo | ok, you'll get a bit of sympathy from me given that last point... | 11:59 |
| jeremybennett | What I suggest is that when you patch autotools, you comment openrisc--** and or32-*-* as deprecated. Then in a few years we can rip them out. | 11:59 |
| jonibo | what's the status of getting things upstream? | 11:59 |
| jonibo | GCC, binutils? | 11:59 |
| jonibo | i get asked this _all the time_ | 11:59 |
| jonibo | ...and I don't have a good answer | 12:00 |
| jonibo | do we need to rewrite everything from scratch (clean-room)? | 12:00 |
| jeremybennett | FSF requires copyright assignment, which is the big blocker. At last September's meeting, I think LoneTech or O01eg volunteered to start trying to contact all the past contributors. | 12:01 |
| jeremybennett | All of them need to assign their copyright to the FSF. | 12:01 |
| jonibo | where's the horizon for the merge? another 3 years? | 12:03 |
| blueCmd | http://293eb3b54924da4b.paste.se/ < that's the patch we're looking at them. it's just adding or1k, leaving or32 and openrisc | 12:03 |
| blueCmd | that's the important part anyway to ride on the wave | 12:04 |
| jonibo | um, no... you're missing or1k-*-linux* | 12:04 |
| blueCmd | jonibo: I think that is handled in some generic way, no? | 12:05 |
| jonibo | no.... not as far as I now | 12:05 |
| jonibo | it's been a while since I looked at this, though | 12:05 |
| jonibo | sorry, you are right | 12:06 |
| jonibo | it's handled generically | 12:06 |
| jonibo | i was thinking of something else | 12:06 |
| blueCmd | jonibo: http://90c01ac7887bc9f7.paste.se/ ;) | 12:06 |
| jonibo | ok perfect | 12:07 |
| jonibo | then your patch looks good | 12:07 |
| jonibo | and or32-* defaults to -coff... really nice | 12:08 |
| jonibo | especially since nothing supports coff anymore | 12:08 |
| jonibo | probably should make that one -elf while we're at it | 12:09 |
| blueCmd | isn't it just recently the toolchain started using elf? | 12:10 |
| jonibo | 3 years ago... I think | 12:10 |
| blueCmd | oh | 12:10 |
| jonibo | i think all the coff support has been ripped out around that time, too | 12:10 |
| jonibo | but that's just how I remember it... I could be wrong | 12:10 |
| blueCmd | jonibo: I'm thinking that we leave it "for now (TM)" with the same argument as jeremybennett (early adopters and what not) | 12:12 |
| jonibo | sure, fine by me | 12:14 |
| LoneTech | jeremybennett: I don't think I did | 12:19 |
| LoneTech | last time I did some reading up on it us swedes couldn't even sign over copyright (which wasn't even a legal term in swedish law) | 12:22 |
| LoneTech | but I expect they've changed it around to be more convenient for some large company since then | 12:23 |
| jonibo | LoneTech: is that a task you want to take on? | 12:24 |
| jonibo | somebody eventually has to do it so we know if we need to re-write the entire toolchain from scratch or whether we can upstream what we've got | 12:24 |
| LoneTech | sadly I don't think I'd be very good at it. too much I'm not getting done as is | 12:26 |
| LoneTech | sorry | 12:26 |
| jonibo | no worries | 12:27 |
| blueCmd | jonibo: where did development start? are there commit logs from the beginning? | 12:33 |
| jonibo | originally things were in CVS... then SVN... I _think_ the history has been preservered during that transition | 12:34 |
| jonibo | i haven't looked at the GCC git repo for a while... but I think it has all the SVN history... in which cases the netire history should be there | 12:34 |
| jonibo | it's not so easy to see who the author of a patch was, though, in the CVS/SVN logs... the comitter and author are seldom the same person | 12:37 |
| jonibo | ("seldom" may be exagerating a bit) | 12:37 |
| jeremybennett | Sorry - back now | 12:43 |
| jeremybennett | I was going to say that the FSF requires you to sign an agreement before you can contribute anything, which can take a few months to process. | 12:44 |
| jeremybennett | Unless they already have it, early contributors probably aren't going to want to go down that route. We've solved it in the past by getting people to assign to Embecosm (which we can make much more lightweight), contingent on us immediately reassigning to the FSF. | 12:45 |
| jeremybennett | You could do the same with any organization or individual that has a FSF agreement in place. | 12:45 |
| jeremybennett | The FSF has pretty high standards for demonstrating that you own the stuff you contribute. So it really matters that you track down anyone who wrote original stuff that is still being used | 12:46 |
| jeremybennett | On the whole contributors have left their name in the source comments, so you can track them through that. | 12:48 |
| blueCmd | jeremybennett: Aha. I copied quite a lot of code internally from other archs and then modified it to be correct for or1k, does that entail anything? | 12:55 |
| blueCmd | I mean, the code is still under GPL and all that. I guess I need to attribute the changes somehow? | 12:56 |
| blueCmd | jeremybennett: you think I need to have an FSF to submit the autoconf patches? | 13:00 |
| jeremybennett | blueCmd: I believe so, but an email to them would confirm the situation | 13:03 |
| jeremybennett | Reusing existing code from other architectures in the FSF distribution is no problem. | 13:04 |
| jonibo | blueCmd: copyright assignment's generally not needed for trivial patches (less than 100 lines or so!!!) so your autoconf patch is fine | 15:06 |
| jonibo | copying code from other arches is fine since it's already "owned" by the FSF | 15:06 |
| blueCmd | jonibo: great | 15:07 |
| ams | http://www.gnu.org/prep/maintain/maintain.html#Copying-from-Other-Packages | 15:14 |
| ams | if anyone is curious :-) | 15:17 |
| jeremybennett | jonibo: I'd check up on that comment. Trivial patches are not defined only by size, but the significance of the change they make. | 15:43 |
| jeremybennett | Adding a new architecture might not be considered trivial. | 15:44 |
| jeremybennett | Not sure where the 100 lines comes from. The FSF legal briefing note (https://www.gnu.org/prep/maintain/maintain.html#Legal-Matters) says "around 15 lines of code and/or text" | 15:48 |
| jeremybennett | Section 6.2 of that document goes into more detail | 15:49 |
| --- Log closed Mon Feb 11 17:05:45 2013 | ||
| --- Log opened Mon Feb 11 17:06:00 2013 | ||
| -!- Irssi: #openrisc: Total of 27 nicks [0 ops, 0 halfops, 0 voices, 27 normal] | 17:06 | |
| -!- Irssi: Join to #openrisc was synced in 22 secs | 17:06 | |
| stekern_ | regarding copyrights on or1k-src (if we exclude newlib and gdb), it's pretty simple, that's based on the openrisc port by Johan Rydberg (that's already upstream). After that juliusb, peter gavin, me and blueCmd have hacked on it. | 17:21 |
| stekern_ | so that's already essentially a "cleanroom rewrite" from the or32- toolchain | 17:23 |
| stekern_ | gcc is probably harder to sort out, yes | 17:23 |
| -!- You're now known as stekern | 17:23 | |
| blueCmd | stekern: awesome | 17:30 |
| jeremybennett | stekern: That's good news. | 17:34 |
| jeremybennett | Easy to get the necessary assignments from those characters I should think. | 17:35 |
| stekern | me too :) | 17:35 |
| jeremybennett | blueCmd: You should sort out getting approval to contribute to the FSF if you want to do it. | 17:35 |
| jeremybennett | Did Rich d'Addio do anything with binutils. I know he did hacking on GCC? | 17:36 |
| jeremybennett | Don't forget GDB. I did pretty much a full rewrite for GDB 6.8, and we threw out all the custom JTAG stuff. You'll need to just cross-check against GDB 5.3 to see if any old stuff got reused. | 17:37 |
| jeremybennett | (I think your earlier comment about or1k-src really applied only to the binutils bit being upstream). | 17:38 |
| stekern | yeah, I excluded newlib and gdb | 17:38 |
| jeremybennett | newlib should be no problem. That was a clean rewrite by me, and then Julius rewrote that. I don't think any of the old 1.13 port remains. | 17:39 |
| stekern | then it's only gdb left | 17:40 |
| jeremybennett | Yup - but as noted it just needs a check against 5.3 to verify that I really did rewrite everything. | 17:42 |
| jeremybennett | And given _franck_ has since rewritten it again, I doubt any of the original remains. | 17:43 |
| blueCmd | what about uclibc ? | 17:43 |
| blueCmd | or is that already upstream? | 17:43 |
| stekern | that's good, so then it's basically just you and _franck_ that needs to be added to my list above | 17:44 |
| stekern | blueCmd: aren't you obsoleting that with eglibc? =P | 17:44 |
| jeremybennett | IIRC uClibc has less onerous licensing restrictions. It's not FSF. | 17:45 |
| blueCmd | stekern: hah, sure - eglibc is a tad big though | 17:50 |
| stekern | yeah, I'm just kidding | 17:59 |
| blueCmd | stekern: i assumed you were | 18:01 |
| blueCmd | i think I got strace working, that's nice | 18:01 |
| blueCmd | I need to fill in aaaaaaaalll syscalls though | 18:01 |
| blueCmd | right now it thinks exit_group is socketpair | 18:02 |
| blueCmd | http://dbdb3606cc043883.paste.se/ \o/ | 19:33 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!