IRC logs for #openrisc Wednesday, 2019-09-11

--- Log opened Wed Sep 11 00:00:23 2019
ysionneaushorne: I would *guess* that you should not need a .rela.got for statically linked binaries ... right?08:24
ysionneauor maybe it depends on your TLS model...08:24
ysionneauwhat08:29
ysionneauwhat's in this .rela.got section anyway shorne ? relocs for TLS module id and DTPOFF?08:29
shorneysionneau: yes, its the DTPOFF, in this case its for R_OR1K_TLS_IE_HI1610:21
shornebut you are right, it should not be creating .rela.got when its static10:21
shorneit can just put the value directly into the .got10:21
shornewhich it does, so there are 2 issues I am looking at now it the linker (binutils-gdb/bfd/elf32-or1k.c)10:22
shorne1. Why does it try to do dynamic reloc writing when I have -static flat set.  Likely a problem with the 'dynamic' flag.10:23
shorne2. Why does the .rela.got section disappear and not get allocated.  (a. I can debug and see it gets created, then b. during allocation of the content (or1k_elf_size_dynamic_sections) it is not allocated c. later when trying to write relocs it crashes because there is nothing to write too as b. was skipped)10:25
shorne^ above I mean 'which it should' There is logic to skip writing to .rela.got if its 'static', but due to 1. the linker thinks its in dynamic mode.10:27
ysionneauI mean, the .got.rela section it creates, is it empty? can you spot which symbols generates the reloc ?10:27
ysionneaubut yes most probably it's just a dynamic "switch" logic issue10:27
shorneWell, yes,  there is a glibc test thought, that uses these macros: https://github.com/stffrdhrn/or1k-glibc/blob/upstream-rebase/sysdeps/or1k/tls-macros.h10:29
shornespecifically https://github.com/stffrdhrn/or1k-glibc/blob/upstream-rebase/sysdeps/or1k/tls-macros.h#L60-L6410:29
shorne     asm ("l.movhi  %0, gottpoffhi(" #x ")\n\t"\10:29
shorne  "l.add    %0, %0, %1\n\t"\10:29
shorne  "l.lwz    %0, gottpofflo(" #x ")(%0)\n\t"\10:29
shorne  "l.add    %0, %0, %2\n\t"\10:29
shorne  "l.lwz    %0, 0(%0)\n\t"\10:29
shorne10:29
shorneso the gottpoffhi, generates the reloc10:30
shorneYeah, I think so.  I was just looking into 2, as I couldn't see how the linker code chooses to skip .rela.got10:31
shornedo you have much experience with binutils/bfd code?10:31
shorneysionneau: this is the line that evaluates dynamic is true10:33
shornehttps://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf32-or1k.c;h=0d1336ceaccdc2a861c9bbb45b20c0931df0e0d2;hb=HEAD#l162510:33
shorne1625             dynamic = bfd_link_pic (info)10:33
shorne1626               || (sec && (sec->flags & SEC_ALLOC) != 010:33
shorne1627                   && h != NULL10:33
shorne1628                   && (h->root.type == bfd_link_hash_defweak || !h->def_regular));10:33
shornebreaking it down:  bfd_link_pic (info)10:33
shornelink_pic -> 010:34
shornebfd_link_hash_defweak 0 : def_regular 0 : def_dynamic 010:34
shorneso, its the def_regular is not true10:34
shornewhich causes the logic to think it needs dynamic relocations10:35
shorneThe thing is I cheked other targets and they seem to use similar logic10:35
ysionneau16:29 < shorne> do you have much experience with binutils/bfd code? < not at all10:44
ysionneauI only deal with libc so far10:44
ysionneaumy colleague deals with binutils/gcc10:44
ysionneausorry10:44
shornethats fine10:45
shorneI think I figured out 210:45
shornewhen the linker processes objects it does a few passes10:46
shorne1. scan all symbols and map our the required sections and relocs etc10:47
shorne2. allocate sections, any sections that are not needed as per 1. are marked for removal10:47
shorne3. write our symbols, relocs, text to all section10:48
ysionneau(I'd like to ramp up in toolchain developing knowledge though, in the mid-term future)10:48
shorneThe problem with "Why does the .rela.got section disappear", is because nothing was mapped to it in phase 110:49
shornewhich is expected10:49
shornebut due to "1. wrong dynmic flag logic" it tries to write to .rela.got, and the linker fails10:50
shornenow.  I guess there is a mismatch between the "dynamic" flag in phase 1 and phase 210:50
shorneI mean phase1 and phase310:50
ysionneauso the linker thinks it is linking pic code? it should not be pic code, right?10:50
shorneright it is not10:51
ysionneauah no the issue is with def_regular you said10:51
shorneyeah10:51
ysionneauI dont know what this is10:52
shorneThe issue with 2. is just me tyring to understand how the linker works :)10:52
shorneI am just learning as things break10:52
ysionneauhehe10:52
shorne:)10:52
ysionneauthis is exactly what my colleagues says also10:52
ysionneauI guess this is the only way for binutils/gcc learning...10:52
ysionneaujust have it crash until it does not anymore and you somehow understand whats going on10:53
ysionneauI wonder what's more painful, gcc/binutils lacks of internal documentation ... or LLVM C++10:53
shornethe docs for gcc are pretty good, but only if someone gives you an overview of what it means first10:59
shornebut, binutils is pretty sparse11:00
shorneeven glibc I have found is not well documented11:00
shornei.e. how do the ld.so internals work.11:00
ysionneauI didn't look at glibc much so far11:02
ysionneaujust uClibc-ng11:02
ysionneauand I reckon I had to do lots of code reading to understand whats going on11:02
ysionneauI can tell you that in our toolchain, there is no dynamic =11:03
ysionneaubut11:03
ysionneauhttps://dpaste.de/D7uB11:03
ysionneauso "need_relocs"11:04
ysionneauwhich seems a bit similar11:04
ysionneaubut anyway this code is not production ready, our tls is still a bit shacky11:11
shornere:  https://dpaste.de/D7uB, right and no use of def_default11:16
shorneysionneau: what is your target if you don't mind me asking?11:19
ysionneauKalray k1c VLIW core11:22
ysionneau17:14 < shorne> re:  https://dpaste.de/D7uB, right and no use of def_default < not in _elf_relocate_section ... but in other places11:23
ysionneauk1c core is presented on slides 5 and 6 : http://gallium.inria.fr/seminaires/transparents/20190708.Cyril.Six.pdf11:26
ysionneaushorne: I would have a question about _Unwind_ForcedUnwind in libgcc. Do you have it? Or do you have _Unwind_SjLj_ForcedUnwind ?11:32
ysionneaudoes your gcc support dwarf2 at runtime ?11:33
ysionneau(that's for pthread_cancel , exception handling ...)11:33
ysionneau(in libgcc_s.so)11:40
shornewe use _Unwind_ForcedUnwind with dwarf11:45
shorneIt worked last time I tested11:45
shornebut recently looking at new tests it looks like there may be issues11:46
shorneI havent investigated yet11:46
shorneworking on this linking issue11:46
shorne... I think its fixed now11:46
ysionneauwow11:47
ysionneaubravo :)11:47
shorneok, it works (I basically copied the 'dynamic' flag to be what riscv uses11:47
ysionneauanyway, I kind of understand that if you dont support dwarf runtime you are basically screwed11:47
shorne)11:47
ysionneauuclibc and glibc used to support loading SjLj (setjump longjmp) symbols from libgcc ...11:48
ysionneaubut they no longer support this11:48
ysionneauso if you dont support dwarf2 exception it's dead.11:48
ysionneaushorne: what kind of non-regression do you do to test that you didnt create an issue somewhere else?11:49
shorneright, I did remember debugging some nast issue with return handling with the libgcc/gcc port when I was working on it11:49
shorneysionneau: well, I will have to run the full gcc/binutils/gdb + now glibc tests to see how it goes11:49
ysionneauthe culprit seems to be: https://git.uclibc.org/uClibc/commit/?id=6cbeaa5dd11a1b506a8a97b4dfb4e632240f995311:49
ysionneaushorne: ok :)11:50
ysionneauwhat's the strongest supported libc for or1k? uclibc-ng? glibc? musl?11:50
ysionneaujust out of curiosity11:50
shorneI would say musl11:52
shorne+ newlib as well11:53
shornenewlib is the baremetal libc which we do use a lot, as many people use openrisc as more of a uController11:53
ysionneauok11:53
ysionneauwe do have newlib also, for the embedded use cases11:53
shorneglibc I am just working on now to get the port in shape11:53
shorneuclibc-ng support was better when waldemar was on this chat room asking me for help with test regressions11:54
ysionneauhehe11:54
shorneBut he has been away for a bit11:54
ysionneauhe is very slowly responding those days11:54
ysionneaubut he still does apply patches11:55
shorneI need to get to bed, the glibc tests are passing now11:56
shorneI mean, compiling now11:56
shornemany passing, some failing11:56
shorneIll have to look more at it tomorrow if I get time11:57
ysionneaugood luck12:05
ysionneaugn812:05
--- Log closed Thu Sep 12 00:00:24 2019

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