IRC logs for #openrisc Saturday, 2014-01-25

--- Log opened Sat Jan 25 00:00:09 2014
stekernblueCmd: awesome, you're going to make olofk_ cry of happiness ;)00:17
blueCmdhah00:36
blueCmdolofk_: look at the thing!00:36
jeremybennettolofk_: Just seen your message about newlib. I think the issue you are referring to is the problem with weak references. The general idea with a static library is to only link in the stuff you actually need.09:44
jeremybennettWeak references in newlib mean "use me unless someone has defined a version elsewhere". The idea being that the user can override any library function and the user version will be picked up.09:44
jeremybennettThe problem is that linking does not do intra-library resolution of weak references (part of the spec). But malloc and free are defined as weak references.09:46
jeremybennettThe problem is that library functions like printf use malloc, but since they are both in the library and malloc is weak, printf fails to find malloc when linking, so on execution the code for malloc is missing.09:47
jeremybennettWe've solved this by always putting malloc into the linked code, but this means if you *don't* need it your linked code is bigger than necessary.09:47
jeremybennettI'm not sure how to resolve this. We are not the only architecture with the issue - the same thing happens with ARM. But as far as I can see the spec says this is exactly how linking should behave.09:48
stekernjeremybennett: I don't understand, if you are calling printf, which is using malloc, then you obviously need it11:41
stekernif you are not calling any functions that are using malloc (and are not using it yourself), it will not be pulled in11:42
stekernif you want to have your own version of malloc, you can define that and use that, it will work fine, since malloc is defined weak in newlib11:43
stekernisn't that all good?11:43
blueCmdjonibo: feast upon my patches16:03
jeremybennettstekern: Yes - it may appear obvious. But both malloc are in libnewlib.a, with malloc marked as a weak reference. The rules say you don't do resolving of dependencies for weak references within a library.16:20
jeremybennettSo the code for printf will be taken from libc.a, but it won't link against the malloc in libc.a, so the code from libc.a for malloc won't be included.16:21
jeremybennettThe rationale being that there might be a malloc in the user code which should take precedence. But by then we are past looking at libc.a.16:22
jeremybennettI'm sure there is a solution, but discovering the same problem afflicted ARM and hadn't been fixed I decided that must mean it was a hard problem, and went off to look at other things.16:23
stekernjeremybennett: libnewlib.a? you mean libc.a?19:04
jeremybennettSorry - brain switched off. I mean libc.a from newlib19:04
stekernso where does the malloc come from then? if not from libc.a?19:04
jeremybennettfrom libc.a as well.19:04
stekernnow you got me confused ;) you said that printf can't link against that19:05
jeremybennettBut the rules say that printf in libc.a can't look for weak malloc in libc.a.19:05
stekernso why does it work then?19:05
jeremybennettSo printf needs malloc. But the rules for linkers say it can't look in its own .a file.19:05
jeremybennettBecause I hacked the SPEC for gcc to force malloc symbol always to be looked for.19:06
jeremybennettI think it was LIB_SPEC19:06
jeremybennettSo you *always* get malloc whether you need it or not!19:06
stekernok, let me take a look19:06
jeremybennettstekern - if you find out how to fix it, I shall be very interested. It's an issue that keeps coming up.19:07
stekernhmm, I can't find any SPEC that does anything related to that19:13
stekernjeremybennett: and even so, what do you mean by "*always* get malloc"? the simple tests I just did with the or1k toolchain shows that if you don't call something that need malloc, it will not be included19:22
stekernand if you define you own malloc, that one will be used19:22
stekernsorry for being stubborn, but I tend to pound on things until I understand them ;)19:23
stekern_franck_: this: http://www.juliusbaxter.net/openrisc-irc/%23openrisc.2013-01-24.log.html#t12:2420:17
stekernwas that due to not exporting the gcc PATH?20:18
blueCmdI'm surprised how well qemu-user works20:35
blueCmdwith my signal patches I have been able to do really nice stuff. Native compilation with like 'make -j7' automatically forks like how you would expect it too20:36
blueCmdwith binfmt-misc it works very well, you can just execute random binary and it will work.20:36
blueCmdHopefully that will help even more with the regression suits20:36
_franck_stekern: didn't remember I wrote that :) I think it was, as you said, because of the not exported gcc PATH20:40
blueCmdthe sameful "oups" does sound like that could be the cause20:41
stekernsomeone had the same problem on the forums, that's why I asked20:51
_franck_yeah, I've seen this but wasn't sure of the solution20:51
_franck_this stupid Quartus generates mixed language files (verilog & VHDL) for some cores (ALTMEMPHY here) and *of course* modelsim ALTERA version supports only a single HDL...20:53
blueCmd_franck_: priv20:56
stekern_franck_: can't you force it to only generate verilog?21:22
_franck_all files except one are verilog. However, I found that there is a verilog model for the simulation of this particular VHDL file21:27
_franck_I'm testing this21:27
_franck_cool, it seems to work21:30
stekern_franck_: thanks, I knew that needed to be done, but hadn't got around to it22:49
_franck_no problem22:49
blueCmddo we have any smp openrisc?22:59
stekernthere are multicore variants, but mostly in research context23:08
blueCmdstekern: http://asciinema.org/a/736223:11
blueCmdall: http://asciinema.org/a/736223:11
blueCmdscreencast of me installing Debian from scratch and doing apt-get install python and running a python program23:12
blueCmdwarning: installing python is not something you would do inside or1ksim, it takes like 10 minutes :P so you can fast forward there23:13
stekerncool!23:13
stekernand that asciinema.org site was cool too, didn't know about that ;)23:13
blueCmdno, I found it just for this :P23:14
veprblblueCmd: will it be a mainline debian port?23:34
blueCmdveprbl: that's a few years away, but who knows23:35
blueCmdif it's only me using it, probably not23:36
veprblor maybe you could go for emdebian23:38
stekernblueCmd: you've got to think big, world dominance is the goal ;)23:38
blueCmdstekern: ofc!23:39
blueCmdveprbl: so emdebian is a hack really23:39
veprbllike ugly?23:40
stekernanyone knows by heart in what file the busybox main is defined...?23:40
stekern+does -s23:40
blueCmdwell, I probably shouldn't talk too much since I haven't used it much, but the emdebian guys I've been talking to have been telling me to use 'normal' debian23:40
blueCmdso that's something23:40
blueCmdstekern: busybox.c or main.c I would guess :P23:41
veprblfunny)23:41
stekerngood guess, unfortunately none of them exist23:42
stekernin appletlib.c it seems to be23:45
stekernblueCmd: I'd definetely be interested in trying it out on some real hw23:53
blueCmdstekern: cool! I need some place to host my repository23:55
blueCmdall my hosts are "in the cloud" and I halt them when I'm done with them23:55
--- Log closed Sun Jan 26 00:00:10 2014

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!