IRC logs for #openrisc Monday, 2013-02-11

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 0000202800:24
blueCmdsorry, no idea about newlib magic but perhaps it's possible to have multiple boards installed? sounds weird though00:24
_franck_yes it's possible to have more than one board but it should default to or1ksim00:25
blueCmdyeah it should00:25
blueCmdseems it forbids static though00:26
blueCmdgcc/config/or1k/or1k.h line 7500:26
blueCmdseems it adds -lboard-or1ksim if mboard is missing and if you're not using static linking00:27
_franck_don't understand that line :) but I can see !static00:28
_franck_any idea on the warning ?00:29
blueCmdah, yeah gcc spec lines are a bit weird, but it means if the first match then do the thing after the ":"00:29
blueCmdregarding the warning, you could do a standard "grep 0x100-static -R /where/you/install/gcc"00:31
blueCmdit should show which files contain that entrypoint, hopefully some crti.o or something like that00:31
blueCmdyou probably get loads of matches though so you might want to grep that output as well00:32
_franck_no, gives me nothing00:34
_franck_#define LINK_SPEC "%{mnewlib:-entry 0x100}%{static:-static}%{shared:-shared}"00:40
_franck_can 0x100 be concatened with static here ?00:40
blueCmdwell yes :P00:41
blueCmdadd a space00: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 though00:43
_franck_looks like it did the trick01:03
andresjkhi there01:04
_franck_hi andresjk01:04
andresjkdoes anyone knows if there is a list of the libraries and functions supported by or32-elf-gcc? im looking for scanf, and some math functions01:05
_franck_those function are supported by newlib so I guess you should look at newlib doc01:06
andresjkyeah, your right. thanks01:08
jeremybennettblueCmd: We need to retain or32 for the time being. I see no reason why the config cannot have both or32 and or1k.10:39
jeremybennettWe 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
jeremybennettSo we have to manage any transitions properly. OR1K is no longer a research curiosity used by a handful of people!10:40
blueCmdjeremybennett: 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-*-*-* anyway11:10
jonibowhy do you want to add openrisc-*-*-*?11:23
jonibothat doesn't seem to be in line with how things have been handled earlier... or1k-*-*-* is what it should be.11:24
jonibothat's or???? where ??? is some qualifier for the particular variant of the openrisc family... like 1k, 2k, 1knd, etc.11:25
blueCmdjonibo: it is already there11:41
blueCmdbut is an alias for or3211:41
joniboright... that's from the _old_ toolchain.... written about 10 years ago11:41
joniboi'd rip out openrisc-*-*-* altogether11:41
blueCmdah that makes sense11:41
jonibonobody uses it11:41
blueCmdgood, then we will leave it.11:41
blueCmdIs it ok if I simply send a patch to add or1k?11:42
joniboas far as I'm concerned, yes11:42
blueCmdshould I send something to the mailinglist about it?11:42
joniboyes, probably should11:42
joniboour 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
joniboleave just or1k-*-*11:44
joniboit's not like this is integrated into a bunch of build systems that are going to break11:44
jonibonothing "public", in any case11:44
joniboand for everybody else it's a trivial fix11:45
blueCmdjonibo: jeremybennett meant that the old or32 toolchain is used in a number of installations, it would be bad to alienate them I think11:45
joniboyeah, but it's two projects and they use GCC 4.511:46
jonibobig deal if they need to change the triple when moving to a later toolchain11:46
joniboif this stuff was upstream, I would agree... but it's a work in progress11:46
jonibo...what's the status of getting the toolchain upstream anyway?11:46
joniboand 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's11:47
jonibo...if autools wants a triple for an arch that's not in any upstream toolchain, that its.11:48
blueCmdI 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 work11:48
joniboit will be a major pain in the ass... ask the aarch64 people11:48
blueCmdyes, they have done a looot of work to ease this though11:48
blueCmdI'm glad I didn't get this idea last year11:48
jonibohave 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 toolchain11:51
jeremybennettblueCmd: jonibo is right that openrisc-*-* is obsolete.11:52
blueCmdjonibo: well, I guess that we will find out when the patch is sent to them ,no? is that being an asshole?11:52
jeremybennettHowever 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
joniboblueCmd: no, that's exactly the right way to do it!11:52
jonibodon't add or32-*-* to upstream autools11:53
jonibowe want that thing to die11:53
jeremybennettWe want to move to or1k, because that is the right naming.11:53
blueCmdjonibo: jeremybennett fight whenever I should remove or32 :-)11:53
jeremybennettI agree with not pushing or32 upstream.11:53
jeremybennettI'm just saying that don't kill all things or32.11:54
blueCmdit's already upstream so we're looking at a removal of it then11:54
joniboi think we agree... or1k-* upstream and or32-* for now in the toolchain11:54
joniboor32 is upstream?11:54
joniboopenrisc, too?11:54
jonibook, then the patch should remove two and add one11:54
blueCmdgrep or32 / openrisc11:54
joniboyup, got it11:54
joniboI think I actually knew that... had blocked it out11:55
jeremybennettI 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
blueCmdi'm with jeremybennett11:55
joniboyeah, but that openrisc stuff should just be ripped out11:55
joniboit's not cmpatible with anything that actually exists11:55
jonibonot even or1ksim11:55
jeremybennettjonibo: 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
jeremybennettSo just leave the obsolete stuff there. The important thing is to get or1k in there.11:56
joniboI 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 notice11:57
jonibo...and if there are users, we put it back quickly11:57
jeremybennettjonibo: 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
jeremybennettI still get angry emails about GDB 5.0!11:58
jonibook, you'll get a bit of sympathy from me given that last point...11:59
jeremybennettWhat 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
jonibowhat's the status of getting things upstream?11:59
joniboGCC, binutils?11:59
joniboi get asked this _all the time_11:59
jonibo...and I don't have a good answer12:00
jonibodo we need to rewrite everything from scratch (clean-room)?12:00
jeremybennettFSF 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
jeremybennettAll of them need to assign their copyright to the FSF.12:01
jonibowhere's the horizon for the merge?  another 3 years?12:03
blueCmd < that's the patch we're looking at them. it's just adding or1k, leaving or32 and openrisc12:03
blueCmdthat's the important part anyway to ride on the wave12:04
joniboum, no... you're missing or1k-*-linux*12:04
blueCmdjonibo: I think that is handled in some generic way, no?12:05
jonibono.... not as far as I now12:05
joniboit's been a while since I looked at this, though12:05
jonibosorry, you are right12:06
joniboit's handled generically12:06
joniboi was thinking of something else12:06
blueCmdjonibo: ;)12:06
jonibook perfect12:07
jonibothen your patch looks good12:07
joniboand or32-* defaults to -coff... really nice12:08
joniboespecially since nothing supports coff anymore12:08
joniboprobably should make that one -elf while we're at it12:09
blueCmdisn't it just recently the toolchain started using elf?12:10
jonibo3 years ago... I think12:10
joniboi think all the coff support has been ripped out around that time, too12:10
jonibobut that's just how I remember it... I could be wrong12:10
blueCmdjonibo: I'm thinking that we leave it "for now (TM)" with the same argument as jeremybennett (early adopters and what not)12:12
jonibosure, fine by me12:14
LoneTechjeremybennett: I don't think I did12:19
LoneTechlast 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
LoneTechbut I expect they've changed it around to be more convenient for some large company since then12:23
joniboLoneTech: is that a task you want to take on?12:24
jonibosomebody 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 got12:24
LoneTechsadly I don't think I'd be very good at it. too much I'm not getting done as is12:26
jonibono worries12:27
blueCmdjonibo: where did development start? are there commit logs from the beginning?12:33
jonibooriginally things were in CVS... then SVN... I _think_ the history has been preservered during that transition12:34
joniboi 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 there12:34
joniboit'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 person12:37
jonibo("seldom" may be exagerating a bit)12:37
jeremybennettSorry - back now12:43
jeremybennettI 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
jeremybennettUnless 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
jeremybennettYou could do the same with any organization or individual that has a FSF agreement in place.12:45
jeremybennettThe 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 used12:46
jeremybennettOn the whole contributors have left their name in the source comments, so you can track them through that.12:48
blueCmdjeremybennett: 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
blueCmdI mean, the code is still under GPL and all that. I guess I need to attribute the changes somehow?12:56
blueCmdjeremybennett: you think I need to have an FSF to submit the autoconf patches?13:00
jeremybennettblueCmd: I believe so, but an email to them would confirm the situation13:03
jeremybennettReusing existing code from other architectures in the FSF distribution is no problem.13:04
joniboblueCmd: copyright assignment's generally not needed for trivial patches (less than 100 lines or so!!!) so your autoconf patch is fine15:06
jonibocopying code from other arches is fine since it's already "owned" by the FSF15:06
blueCmdjonibo: great15:07
amsif anyone is curious :-)15:17
jeremybennettjonibo: 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
jeremybennettAdding a new architecture might not be considered trivial.15:44
jeremybennettNot sure where the 100 lines comes from. The FSF legal briefing note ( says "around 15 lines of code and/or text"15:48
jeremybennettSection 6.2 of that document goes into more detail15: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 secs17: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- toolchain17:23
stekern_gcc is probably harder to sort out, yes17:23
-!- You're now known as stekern17:23
blueCmdstekern: awesome17:30
jeremybennettstekern: That's good news.17:34
jeremybennettEasy to get the necessary assignments from those characters I should think.17:35
stekernme too :)17:35
jeremybennettblueCmd: You should sort out getting approval to contribute to the FSF if you want to do it.17:35
jeremybennettDid Rich d'Addio do anything with binutils. I know he did hacking on GCC?17:36
jeremybennettDon'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
stekernyeah, I excluded newlib and gdb17:38
jeremybennettnewlib 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
stekernthen it's only gdb left17:40
jeremybennettYup - but as noted it just needs a check against 5.3 to verify that I really did rewrite everything.17:42
jeremybennettAnd given _franck_ has since rewritten it again, I doubt any of the original remains.17:43
blueCmdwhat about uclibc ?17:43
blueCmdor is that already upstream?17:43
stekernthat's good, so then it's basically just you and _franck_ that needs to be added to my list above17:44
stekernblueCmd: aren't you obsoleting that with eglibc? =P17:44
jeremybennettIIRC uClibc has less onerous licensing restrictions. It's not FSF.17:45
blueCmdstekern: hah, sure - eglibc is a tad big though17:50
stekernyeah, I'm just kidding17:59
blueCmdstekern: i assumed you were18:01
blueCmdi think I got strace working, that's nice18:01
blueCmdI need to fill in aaaaaaaalll syscalls though18:01
blueCmdright now it thinks exit_group is socketpair18:02
blueCmd \o/19:33

Generated by 2.15.2 by Marius Gedminas - find it at!