IRC logs for #openrisc Saturday, 2014-08-02

--- Log opened Sat Aug 02 00:00:46 2014
stekernplt(__divsi3) didn't work00:20
stekernthe call goes via the plt even with -Bsymbolic-functions00:21
daliasmaybe it doesn't know it's a function?00:23
daliaswhat about -Bsymbolic?00:23
daliasand how does _dlstart work?00:23
stekernwell, it's declared as a @function, but let's try -Bsymbolic just to be sure00:24
stekernto the second question - I don't know what differs from _dlstart00:25
stekernbecause, as you say, that works00:25
stekern-Bsymbolic didn't make a difference00:28
stekern...there's definetely some extra magic involved when building libgcc, there's even this special flag for it: -fbuilding-libgcc00:28
stekernno idea what that does though00:29
daliasi think that flag is just to the compiler00:33
daliasperhaps it prevents it from generating references to the libgcc functions00:34
daliasso they can't be circularly defined00:34
stekernsounds plausible00:41
stekernall the .o's get linked together into the .so with xgcc, and all CFLAGS are in that commandline too00:42
stekernoh... I made a mistake when I passed -Bsymbolic-functions01:01
stekernthat indeed works01:01
stekernwhich is nice, because it didn't make sense that it wouldn't01:02
stekernnow, how to tell libgcc 'the right way' that we want that, that's a quest for tomorrow I think...01:03
daliasfor hidden definitions the same would happen, but the problem is that when making, the definitions can't be hidden01:12
daliasyou could however call the function via an alias that's hidden01:13
stekerndalias: that's basically what my hack does01:15
stekernwell, not exactly, but it calls it via an alias01:16
daliasi see01:19
daliasFYI that's the hack that glibc uses for _everything_ internal01:19
daliasso it's not without precedent01:19
stekernjust using a hidden alias didn't work, the r26 relocs is still in the .so01:33
stekernI'm going to take a look at bfd next01:33
daliasa plt() call to a hidden symbol should get resolved at ld time01:36
daliasjust like -Bsymbolic would do01:36
stekernit get resolved, but through the plt01:37
daliasthat's a binutils bug i think, then01:38
daliasnot sure if/why it matters tho01:38
daliasif you're worried about the kernel, the kernel does not use libgcc_s.so01:38
daliasit uses at most libgcc.a01:38
daliasactually a bug like this exists on microblaze too and it's breaking musl's dynamic linker i think01:39
daliaswell it's somewhat different01:39
daliasgcc is generating GOT lookup + indirect call for hidden functions01:40
daliasvs jmp_slot reloc (which -Bsymbolic-functions then resolves fully without a plt entry) for default-visibility functions01:40
stekerndalias: yes, but the same code is used to build libgcc_s.so06:55
daliasfor static linking you won't get a PLT tho, afaik07:18
stekerndalias: 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
daliasthe kernel is not the dynamic case07:30
daliaskernel cannot use .so's07:30
stekernno, but again, it's the same code/file07:31
daliasand it's static linked so the plt reloc should resolve to a direct rel26 call07:31
daliasbut even if it didn't, if the linker is non-broken, using the GOT should be fine07:31
daliasif the kernel is static linked for a fixed load address, the GOT is entirely filled at ld time07:32
daliasno runtime relocation is needed07:32
stekernso I need that same code work in both the dynamic and static case.07:32
daliasthis is what necessarily has to happen, because you can use PIC objects when static linking userspace binaries too07:32
daliasand in that case there's no dynamic linker to relocate the GOT at runtime07:33
stekernyes, adding a GOT to the kernel would be possible too. But I don't want to solve it that way ;)07:33
daliasld just has to fill it in with constant addresses at ld time07:33
daliasbut i claim it won't use the GOT (i may be wrong :)07:33
daliasit will make a plt (jmp_slot) relocation07:33
daliasbut since the kernel is static linked, this will get resolved to a direct call by ld, rather than a plt entry07:34
daliasand thus, since there's no plt entry, there's no GOT access07:34
stekernwell, it will use the GOT to calculate the GOT pointer07:34
stekernnot for the plt07:34
stekernbecause 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 too07:35
-!- Hesham1 is now known as Hesham08:18
stekerninte sett nåt bra iadf12:21
stekernoops, wrong window12:21
stekernblueCmd: 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
HeshamAre 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 2012:59
stekernHesham: try removing these two lines:13:01
stekernTIMESPEC TS_clk50mbufg_to_wb_clk = FROM "TNM_CLK50M" TO "wb_clk" TIG;13:02
stekernTIMESPEC TS_wb_clk_to_clk50mbufg = FROM "wb_clk" TO "TNM_CLK50M" TIG;13:02
Heshamstekern: I will give it a try and come back again, thanks.13:03
stekernin atlys.ucf13:06
stekernforgot to say that ;913:06
HeshamYes I grep"ed" it and it's building now13:07
blueCmdstekern: yes, I run over ssh13:18
blueCmdbut that is not improved by the fact that I'm using 9p13:19
blueCmd9p 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 tester13:20
stekernhow does ssh improve things?13:23
blueCmdit brings down the size of the board thing13:23
blueCmdand glibc supports testing over it13:23
stekernsize of the board thing?13:24
blueCmdI linked the board thing above13:24
stekernh, *that* boardthing13:25
stekernI don't care so much about the size of that13:26
blueCmd now with a search function!13:26
stekernI care more about that most of the test time is spent in start of ftp and telnet13:27
blueCmdwith control mux I belive it was faster than telnet, but back then the system was too unstable to maintain the control connection13:27
blueCmdbut then again, if the control mux connection fails it will just revert to the slower version so that's fine13:28
stekerncontrol mux?13:28
blueCmdi.e. only one handshake and whatever13:29
stekernyeah, I got it13:29
stekernyup, that's what I want13:29
blueCmdtop reason to use 9p is that it's faster and not NFS13:30
stekernbecause, 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 session13:30
blueCmdbut that requires qemu ofc13:30
blueCmdstekern: yes, it's a bit stupid13:30
stekernwell 'requires', it's just software, everything is possible13:31
blueCmdstekern: you sound like my boss :P13:31
stekernyeah, 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 somehow13:32
stekernthat's of course completely independent what kind of remote fs you use13:32
stekernI want to setup a shared mount between the arm and openrisc on my sockit board too13:33
stekernbut at least, I've got a bridged internet connection working for the openrisc core now13:34
stekernso I'm running the tests on that now13:35
stekernoops, the kernel crashed now ;)13:36
stekernmaybe I should try against or1ksim first...13:37
stekerntoo many unknowns13:37
blueCmdstekern: you can probably use 9p virtio-mmio between the two cpus somehow13:40
Heshamstekern: I got the same error, here is the log:
stekernblueCmd: exactly my thought, hence the 'everything is possible' comment =P13:41
stekernHesham: 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 too13:43
blueCmdstekern: why do you give bad configs to my GSOC student?13:43
blueCmdthat's not very nice13:43
Heshamstekern: That one?13:45
Heshamcommit 081bf6253c8a9fcf6e906fd42bcbb691aa0e79ba13:45
HeshamAuthor: Stefan Kristiansson <>13:45
HeshamDate:   Wed May 7 09:48:55 2014 +030013:45
Hesham    atlys: add timing constraints for dvi_gen CDC13:45
blueCmdHesham: looking at the log you probably want to remove something related to ethoc/eth0 as well13:45
blueCmdbut yes, you can try to revert that patch13:46
HeshamblueCmd: So, could you give me good configs ?13:47
blueCmdHesham: ha, I was only joking13:47
Heshamme too ;)13:47
HeshamDo I have to un-comment TIMESPEC TS_clk50mbufg_to_wb_clk ... line(s) that stekern mentioned?13:48
blueCmdHesham: leave commented13:48
blueCmdHesham: 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 value13:50
blueCmdsynthesis can be a bit pessimistic at times, so this will allow you to bypass this13:50
blueCmdbut 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
HeshamI have a little experience with verilog/FPGA by writing a MIPS processor running on Atlys, but still not an expert13:52
blueCmdbreak as in: it might not work. nothing dangerous13:52
HeshamI 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
blueCmdHesham: it would make no difference13:54
stekernblueCmd: I got completely different fails in the execute tests:
stekernthen I get a lot of fails in stdatomic17:31
stekernbut if we AND our results in execute, we're all good ;)17:33
stekernwas your jul-25 run against gcc-5.0?17:33
stekernblueCmd: hmm, did you remove all the tabs in elf32-or1k.c before you sent it upstream?18:44
blueCmdstekern: I think I did19:09
blueCmdstekern: and yes, is GCC trunk (4.10 I think is what it identifies itself as)19:10
blueCmdfor  gcc.c-torture/execute/ I wouldn't look on them for gcc, they are very much likely to be glibc / musl19:11
blueCmdstekern: stuff like tab/space sanity is part of bluecmd-lint and one of the reasons I'm accepting patches _before_ doing it :)19:24
stekernwell, the ugly tab/space mix is a part of gnu coding style...19:36
stekernnot that I care deeply, I just noticed that the diff between or1k-src was messy19:41
stekern...and I just thought I'd give you a heads-up before you do the same to gcc19:42
stekernthat's the results I got19:48
stekernI haven't looked through any of it, probably a lot of low hanging fruit in there19:49
stekernbut it's interesting, seems we have very few in common19:50
blueCmdstekern: I'm pretty sure I read up on the coding style before, but I might have massacared too much20:20
blueCmdstekern: Cool, nice output there20:21
blueCmdI would say AND yours and mine20:21
blueCmdthat way it's very probable that it's gcc bugs20:22
blueCmdstekern: also, if you could run the full test suite for everything else (like g++, libstd++ and whatever there is) that would be great20:22
blueCmdstekern: as for tab/space. if you could link where this is written I'd be grateful. I can't find any mention of it20:31
blueCmdi know the indentation is "special", but whether to use tab or spaces I'm not so sure20:32
stekernI don20:33
stekern't know if it's explicitly written anywhere20:34
stekernbut it's what most files do in binutils/gcc/gnu stuff and also what emacs gnu c-style do20:34
stekernbut as I said, not that it matters much, as long as it's consistent (which it is).20:36
blueCmdIIRC we had "the correct" way of doing it in just a few places in the file20:37
stekernI think I went over that file and corrected most of them, but I might remember wrong20:37
blueCmdmight be my code that was wrong then20:37
blueCmdI got it the way I wanted and in the end that is what matters20:38
stekernyeah, my only point of bringing it up is, you might let the tab/space be in gcc to avoid creating unecessary diffs against or1k-gcc20:38
blueCmdin 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 that20:39
blueCmdstekern: well, sure - but I think it will be hard to keep both anyway20:39
blueCmdespecially for gcc which can be replaced with upstream when our port is upstreamed20:40
stekernwell, 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 new20:41
blueCmd*sigh* I knew that my glibc would break ABIs, but yeah - it sucks :P22:49
blueCmdseems like read and fputs and stuff like that broke, so maybe this actually means that the 64 bit offset was changed or something23:14
blueCmdhopefully to something good23:15 seems to allow me to use gcc at least :)23:18
--- Log closed Sun Aug 03 00:00:48 2014

Generated by 2.15.2 by Marius Gedminas - find it at!