| --- Log opened Sat Jan 25 00:00:09 2014 | ||
| stekern | blueCmd: awesome, you're going to make olofk_ cry of happiness ;) | 00:17 |
|---|---|---|
| blueCmd | hah | 00:36 |
| blueCmd | olofk_: look at the thing! | 00:36 |
| jeremybennett | olofk_: 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 |
| jeremybennett | Weak 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 |
| jeremybennett | The 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 |
| jeremybennett | The 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 |
| jeremybennett | We'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 |
| jeremybennett | I'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 |
| stekern | jeremybennett: I don't understand, if you are calling printf, which is using malloc, then you obviously need it | 11:41 |
| stekern | if you are not calling any functions that are using malloc (and are not using it yourself), it will not be pulled in | 11:42 |
| stekern | if 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 newlib | 11:43 |
| stekern | isn't that all good? | 11:43 |
| blueCmd | jonibo: feast upon my patches | 16:03 |
| jeremybennett | stekern: 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 |
| jeremybennett | So 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 |
| jeremybennett | The 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 |
| jeremybennett | I'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 |
| stekern | jeremybennett: libnewlib.a? you mean libc.a? | 19:04 |
| jeremybennett | Sorry - brain switched off. I mean libc.a from newlib | 19:04 |
| stekern | so where does the malloc come from then? if not from libc.a? | 19:04 |
| jeremybennett | from libc.a as well. | 19:04 |
| stekern | now you got me confused ;) you said that printf can't link against that | 19:05 |
| jeremybennett | But the rules say that printf in libc.a can't look for weak malloc in libc.a. | 19:05 |
| stekern | so why does it work then? | 19:05 |
| jeremybennett | So printf needs malloc. But the rules for linkers say it can't look in its own .a file. | 19:05 |
| jeremybennett | Because I hacked the SPEC for gcc to force malloc symbol always to be looked for. | 19:06 |
| jeremybennett | I think it was LIB_SPEC | 19:06 |
| jeremybennett | So you *always* get malloc whether you need it or not! | 19:06 |
| stekern | ok, let me take a look | 19:06 |
| jeremybennett | stekern - if you find out how to fix it, I shall be very interested. It's an issue that keeps coming up. | 19:07 |
| stekern | hmm, I can't find any SPEC that does anything related to that | 19:13 |
| stekern | jeremybennett: 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 included | 19:22 |
| stekern | and if you define you own malloc, that one will be used | 19:22 |
| stekern | sorry 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:24 | 20:17 |
| stekern | was that due to not exporting the gcc PATH? | 20:18 |
| blueCmd | I'm surprised how well qemu-user works | 20:35 |
| blueCmd | with 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 too | 20:36 |
| blueCmd | with binfmt-misc it works very well, you can just execute random binary and it will work. | 20:36 |
| blueCmd | Hopefully that will help even more with the regression suits | 20:36 |
| _franck_ | stekern: didn't remember I wrote that :) I think it was, as you said, because of the not exported gcc PATH | 20:40 |
| blueCmd | the sameful "oups" does sound like that could be the cause | 20:41 |
| stekern | someone had the same problem on the forums, that's why I asked | 20:51 |
| _franck_ | yeah, I've seen this but wasn't sure of the solution | 20: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_: priv | 20: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 file | 21:27 |
| _franck_ | I'm testing this | 21:27 |
| _franck_ | cool, it seems to work | 21:30 |
| stekern | _franck_: thanks, I knew that needed to be done, but hadn't got around to it | 22:49 |
| _franck_ | no problem | 22:49 |
| blueCmd | do we have any smp openrisc? | 22:59 |
| stekern | there are multicore variants, but mostly in research context | 23:08 |
| blueCmd | stekern: http://asciinema.org/a/7362 | 23:11 |
| blueCmd | all: http://asciinema.org/a/7362 | 23:11 |
| blueCmd | screencast of me installing Debian from scratch and doing apt-get install python and running a python program | 23:12 |
| blueCmd | warning: installing python is not something you would do inside or1ksim, it takes like 10 minutes :P so you can fast forward there | 23:13 |
| stekern | cool! | 23:13 |
| stekern | and that asciinema.org site was cool too, didn't know about that ;) | 23:13 |
| blueCmd | no, I found it just for this :P | 23:14 |
| veprbl | blueCmd: will it be a mainline debian port? | 23:34 |
| blueCmd | veprbl: that's a few years away, but who knows | 23:35 |
| blueCmd | if it's only me using it, probably not | 23:36 |
| veprbl | or maybe you could go for emdebian | 23:38 |
| stekern | blueCmd: you've got to think big, world dominance is the goal ;) | 23:38 |
| blueCmd | stekern: ofc! | 23:39 |
| blueCmd | veprbl: so emdebian is a hack really | 23:39 |
| veprbl | like ugly? | 23:40 |
| stekern | anyone knows by heart in what file the busybox main is defined...? | 23:40 |
| stekern | +does -s | 23:40 |
| blueCmd | well, 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' debian | 23:40 |
| blueCmd | so that's something | 23:40 |
| blueCmd | stekern: busybox.c or main.c I would guess :P | 23:41 |
| veprbl | funny) | 23:41 |
| stekern | good guess, unfortunately none of them exist | 23:42 |
| stekern | in appletlib.c it seems to be | 23:45 |
| stekern | blueCmd: I'd definetely be interested in trying it out on some real hw | 23:53 |
| blueCmd | stekern: cool! I need some place to host my repository | 23:55 |
| blueCmd | all my hosts are "in the cloud" and I halt them when I'm done with them | 23: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!