| --- Log opened Sat Aug 02 00:00:46 2014 | ||
| stekern | plt(__divsi3) didn't work | 00:20 |
|---|---|---|
| stekern | the call goes via the plt even with -Bsymbolic-functions | 00:21 |
| dalias | maybe it doesn't know it's a function? | 00:23 |
| dalias | what about -Bsymbolic? | 00:23 |
| dalias | and how does _dlstart work? | 00:23 |
| stekern | well, it's declared as a @function, but let's try -Bsymbolic just to be sure | 00:24 |
| stekern | to the second question - I don't know what differs from _dlstart | 00:25 |
| stekern | because, as you say, that works | 00:25 |
| stekern | -Bsymbolic didn't make a difference | 00:28 |
| stekern | ...there's definetely some extra magic involved when building libgcc, there's even this special flag for it: -fbuilding-libgcc | 00:28 |
| stekern | no idea what that does though | 00:29 |
| dalias | i think that flag is just to the compiler | 00:33 |
| dalias | perhaps it prevents it from generating references to the libgcc functions | 00:34 |
| dalias | so they can't be circularly defined | 00:34 |
| stekern | sounds plausible | 00:41 |
| stekern | all the .o's get linked together into the .so with xgcc, and all CFLAGS are in that commandline too | 00:42 |
| stekern | oh... I made a mistake when I passed -Bsymbolic-functions | 01:01 |
| stekern | that indeed works | 01:01 |
| stekern | which is nice, because it didn't make sense that it wouldn't | 01:02 |
| stekern | now, how to tell libgcc 'the right way' that we want that, that's a quest for tomorrow I think... | 01:03 |
| dalias | for hidden definitions the same would happen, but the problem is that when making libgcc_s.so, the definitions can't be hidden | 01:12 |
| dalias | you could however call the function via an alias that's hidden | 01:13 |
| stekern | dalias: that's basically what my hack does | 01:15 |
| stekern | well, not exactly, but it calls it via an alias | 01:16 |
| dalias | i see | 01:19 |
| dalias | FYI that's the hack that glibc uses for _everything_ internal | 01:19 |
| dalias | so it's not without precedent | 01:19 |
| stekern | just using a hidden alias didn't work, the r26 relocs is still in the .so | 01:33 |
| stekern | I'm going to take a look at bfd next | 01:33 |
| dalias | a plt() call to a hidden symbol should get resolved at ld time | 01:36 |
| dalias | just like -Bsymbolic would do | 01:36 |
| stekern | it get resolved, but through the plt | 01:37 |
| dalias | weird | 01:37 |
| dalias | that's a binutils bug i think, then | 01:38 |
| dalias | not sure if/why it matters tho | 01:38 |
| dalias | if you're worried about the kernel, the kernel does not use libgcc_s.so | 01:38 |
| dalias | it uses at most libgcc.a | 01:38 |
| dalias | actually a bug like this exists on microblaze too and it's breaking musl's dynamic linker i think | 01:39 |
| dalias | well it's somewhat different | 01:39 |
| dalias | gcc is generating GOT lookup + indirect call for hidden functions | 01:40 |
| dalias | vs jmp_slot reloc (which -Bsymbolic-functions then resolves fully without a plt entry) for default-visibility functions | 01:40 |
| stekern | dalias: yes, but the same code is used to build libgcc_s.so | 06:55 |
| dalias | for static linking you won't get a PLT tho, afaik | 07:18 |
| stekern | dalias: no, but that's not what I worry about. If I get a call through plt in the dynamic case, I'll need to setup the GOT pointer. and *that* is not going to work for the kernel. | 07:30 |
| dalias | the kernel is not the dynamic case | 07:30 |
| dalias | kernel cannot use .so's | 07:30 |
| stekern | no, but again, it's the same code/file | 07:31 |
| dalias | and it's static linked so the plt reloc should resolve to a direct rel26 call | 07:31 |
| dalias | but even if it didn't, if the linker is non-broken, using the GOT should be fine | 07:31 |
| dalias | if the kernel is static linked for a fixed load address, the GOT is entirely filled at ld time | 07:32 |
| dalias | no runtime relocation is needed | 07:32 |
| stekern | so I need that same code work in both the dynamic and static case. | 07:32 |
| dalias | this is what necessarily has to happen, because you can use PIC objects when static linking userspace binaries too | 07:32 |
| dalias | and in that case there's no dynamic linker to relocate the GOT at runtime | 07:33 |
| stekern | yes, adding a GOT to the kernel would be possible too. But I don't want to solve it that way ;) | 07:33 |
| dalias | ld just has to fill it in with constant addresses at ld time | 07:33 |
| dalias | but i claim it won't use the GOT (i may be wrong :) | 07:33 |
| dalias | it will make a plt (jmp_slot) relocation | 07:33 |
| dalias | but since the kernel is static linked, this will get resolved to a direct call by ld, rather than a plt entry | 07:34 |
| dalias | and thus, since there's no plt entry, there's no GOT access | 07:34 |
| stekern | well, it will use the GOT to calculate the GOT pointer | 07:34 |
| stekern | not for the plt | 07:34 |
| stekern | because if I get a call through plt in the dynamic case, I'll need to setup the GOT pointer in the asm. and that GOT pointer setup will then of course be present in the static case too | 07:35 |
| -!- Hesham1 is now known as Hesham | 08:18 | |
| stekern | inte sett nåt bra iadf | 12:21 |
| stekern | oops, wrong window | 12:21 |
| stekern | blueCmd: now with all your virtio an 9p, do you have some flashy way of running the gcc regressions instead of the old ftp+telnet? | 12:51 |
| Hesham | Are there any issues related to building mor1kx for Atlys board? I am trying to build it using fusesoc build atlys, but I got a "place and route" error. Using ISE 14.6 on fedora 20 | 12:59 |
| stekern | Hesham: try removing these two lines: | 13:01 |
| stekern | TIMESPEC TS_clk50mbufg_to_wb_clk = FROM "TNM_CLK50M" TO "wb_clk" TIG; | 13:02 |
| stekern | TIMESPEC TS_wb_clk_to_clk50mbufg = FROM "wb_clk" TO "TNM_CLK50M" TIG; | 13:02 |
| Hesham | stekern: I will give it a try and come back again, thanks. | 13:03 |
| stekern | in atlys.ucf | 13:06 |
| stekern | forgot to say that ;9 | 13:06 |
| Hesham | Yes I grep"ed" it and it's building now | 13:07 |
| blueCmd | stekern: yes, I run over ssh | 13:18 |
| blueCmd | but that is not improved by the fact that I'm using 9p | 13:19 |
| blueCmd | 9p is only really helpful for glibc which requires the source and the build directory to be located in the same path on both the testee and the tester | 13:20 |
| stekern | ah | 13:22 |
| stekern | how does ssh improve things? | 13:23 |
| blueCmd | it brings down the size of the board thing | 13:23 |
| blueCmd | and glibc supports testing over it | 13:23 |
| blueCmd | https://github.com/bluecmd/or1k-devel/blob/master/tests/or1k-linux-sim.exp | 13:24 |
| stekern | size of the board thing? | 13:24 |
| blueCmd | I linked the board thing above | 13:24 |
| stekern | h, *that* boardthing | 13:25 |
| stekern | I don't care so much about the size of that | 13:26 |
| blueCmd | http://openrisc.debian.net/tmp/freecores.github.io/ now with a search function! | 13:26 |
| stekern | I care more about that most of the test time is spent in start of ftp and telnet | 13:27 |
| blueCmd | with control mux I belive it was faster than telnet, but back then the system was too unstable to maintain the control connection | 13:27 |
| blueCmd | but then again, if the control mux connection fails it will just revert to the slower version so that's fine | 13:28 |
| stekern | control mux? | 13:28 |
| blueCmd | http://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing | 13:28 |
| stekern | ah | 13:29 |
| blueCmd | i.e. only one handshake and whatever | 13:29 |
| stekern | yeah, I got it | 13:29 |
| stekern | yup, that's what I want | 13:29 |
| blueCmd | top reason to use 9p is that it's faster and not NFS | 13:30 |
| stekern | because, sure there are a couple of tests that take a bit of time to run, but most are done in less time than it takes to setup the ftp/telnet session | 13:30 |
| blueCmd | but that requires qemu ofc | 13:30 |
| blueCmd | stekern: yes, it's a bit stupid | 13:30 |
| stekern | well 'requires', it's just software, everything is possible | 13:31 |
| blueCmd | stekern: you sound like my boss :P | 13:31 |
| stekern | yeah, I was just wondering if you had some type of setup where you'd just copy stuff into the share and then ran the tests somehow | 13:32 |
| stekern | that's of course completely independent what kind of remote fs you use | 13:32 |
| stekern | I want to setup a shared mount between the arm and openrisc on my sockit board too | 13:33 |
| stekern | but at least, I've got a bridged internet connection working for the openrisc core now | 13:34 |
| stekern | so I'm running the tests on that now | 13:35 |
| stekern | oops, the kernel crashed now ;) | 13:36 |
| stekern | maybe I should try against or1ksim first... | 13:37 |
| stekern | too many unknowns | 13:37 |
| blueCmd | :D | 13:39 |
| blueCmd | stekern: you can probably use 9p virtio-mmio between the two cpus somehow | 13:40 |
| Hesham | stekern: I got the same error, here is the log: http://pastebin.com/BXJPN3tT | 13:41 |
| stekern | blueCmd: exactly my thought, hence the 'everything is possible' comment =P | 13:41 |
| stekern | Hesham: do a git log on atlys.ucf, I think I added another constraint too at the same time as the one I just said, remove the other one too | 13:43 |
| blueCmd | stekern: why do you give bad configs to my GSOC student? | 13:43 |
| blueCmd | that's not very nice | 13:43 |
| blueCmd | :) | 13:43 |
| Hesham | stekern: That one? | 13:45 |
| Hesham | commit 081bf6253c8a9fcf6e906fd42bcbb691aa0e79ba | 13:45 |
| Hesham | Author: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> | 13:45 |
| Hesham | Date: Wed May 7 09:48:55 2014 +0300 | 13:45 |
| Hesham | atlys: add timing constraints for dvi_gen CDC | 13:45 |
| blueCmd | Hesham: looking at the log you probably want to remove something related to ethoc/eth0 as well | 13:45 |
| blueCmd | but yes, you can try to revert that patch | 13:46 |
| Hesham | blueCmd: So, could you give me good configs ? | 13:47 |
| blueCmd | Hesham: ha, I was only joking | 13:47 |
| Hesham | me too ;) | 13:47 |
| blueCmd | haha | 13:47 |
| Hesham | Do I have to un-comment TIMESPEC TS_clk50mbufg_to_wb_clk ... line(s) that stekern mentioned? | 13:48 |
| blueCmd | Hesham: leave commented | 13:48 |
| blueCmd | Hesham: a little background if you don't know what these things do: TIMESPEC (timing constriants) tells the Synthesis software that you expect a certain clock freqneucy or need a signal to be faster than a given value | 13:50 |
| blueCmd | synthesis can be a bit pessimistic at times, so this will allow you to bypass this | 13:50 |
| blueCmd | but it might be that the "Place and route" step makes an odd placement for some component that is critical, and that might break your system. | 13:51 |
| Hesham | I have a little experience with verilog/FPGA by writing a MIPS processor running on Atlys, but still not an expert | 13:52 |
| blueCmd | break as in: it might not work. nothing dangerous | 13:52 |
| Hesham | I noticed that some one was able to build mor1kx for atyls this week, can I give it a try from Ubuntu? or it would make no difference? | 13:54 |
| blueCmd | Hesham: it would make no difference | 13:54 |
| stekern | blueCmd: I got completely different fails in the execute tests: http://pastie.org/9439505 | 17:30 |
| stekern | then I get a lot of fails in stdatomic | 17:31 |
| stekern | but if we AND our results in execute, we're all good ;) | 17:33 |
| stekern | was your jul-25 run against gcc-5.0? | 17:33 |
| stekern | blueCmd: hmm, did you remove all the tabs in elf32-or1k.c before you sent it upstream? | 18:44 |
| blueCmd | stekern: I think I did | 19:09 |
| blueCmd | whY? | 19:09 |
| blueCmd | stekern: and yes, http://openrisc.debian.net/tmp/gcc-test-jul-25/gcc.fail is GCC trunk (4.10 I think is what it identifies itself as) | 19:10 |
| blueCmd | for gcc.c-torture/execute/ I wouldn't look on them for gcc, they are very much likely to be glibc / musl | 19:11 |
| blueCmd | stekern: stuff like tab/space sanity is part of bluecmd-lint and one of the reasons I'm accepting patches _before_ doing it :) | 19:24 |
| stekern | well, the ugly tab/space mix is a part of gnu coding style... | 19:36 |
| stekern | not that I care deeply, I just noticed that the diff between or1k-src was messy | 19:41 |
| stekern | ...and I just thought I'd give you a heads-up before you do the same to gcc | 19:42 |
| stekern | http://pastie.org/9439701 | 19:47 |
| stekern | that's the results I got | 19:48 |
| stekern | I haven't looked through any of it, probably a lot of low hanging fruit in there | 19:49 |
| stekern | but it's interesting, seems we have very few in common | 19:50 |
| blueCmd | stekern: I'm pretty sure I read up on the coding style before, but I might have massacared too much | 20:20 |
| blueCmd | stekern: Cool, nice output there | 20:21 |
| blueCmd | I would say AND yours and mine | 20:21 |
| blueCmd | that way it's very probable that it's gcc bugs | 20:22 |
| blueCmd | stekern: also, if you could run the full test suite for everything else (like g++, libstd++ and whatever there is) that would be great | 20:22 |
| blueCmd | stekern: as for tab/space. if you could link where this is written I'd be grateful. I can't find any mention of it | 20:31 |
| blueCmd | i know the indentation is "special", but whether to use tab or spaces I'm not so sure | 20:32 |
| stekern | I don | 20:33 |
| stekern | 't know if it's explicitly written anywhere | 20:34 |
| stekern | but it's what most files do in binutils/gcc/gnu stuff and also what emacs gnu c-style do | 20:34 |
| stekern | but as I said, not that it matters much, as long as it's consistent (which it is). | 20:36 |
| blueCmd | IIRC we had "the correct" way of doing it in just a few places in the file | 20:37 |
| stekern | I think I went over that file and corrected most of them, but I might remember wrong | 20:37 |
| blueCmd | might be my code that was wrong then | 20:37 |
| blueCmd | anyway | 20:37 |
| stekern | ;) | 20:37 |
| blueCmd | I got it the way I wanted and in the end that is what matters | 20:38 |
| stekern | yeah, my only point of bringing it up is, you might let the tab/space be in gcc to avoid creating unecessary diffs against or1k-gcc | 20:38 |
| blueCmd | in other news. I realised that I haven't updated my glibc source patch for debian for ages. I was a bit confused why -pie crashed when I knew I had fixed that | 20:39 |
| blueCmd | stekern: well, sure - but I think it will be hard to keep both anyway | 20:39 |
| blueCmd | especially for gcc which can be replaced with upstream when our port is upstreamed | 20:40 |
| stekern | well, there will obviously be a time of overlap, and I'm mostly thinking about when you want to go back and just diff something old and new | 20:41 |
| blueCmd | yep | 20:44 |
| blueCmd | *sigh* I knew that my glibc would break ABIs, but yeah - it sucks :P | 22:49 |
| blueCmd | seems like read and fputs and stuff like that broke, so maybe this actually means that the 64 bit offset was changed or something | 23:14 |
| blueCmd | hopefully to something good | 23:15 |
| blueCmd | LD_PRELOAD=old.libc.so.6 seems to allow me to use gcc at least :) | 23:18 |
| --- Log closed Sun Aug 03 00:00:48 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!