--- Log opened Wed Sep 11 00:00:23 2019 | ||
ysionneau | shorne: I would *guess* that you should not need a .rela.got for statically linked binaries ... right? | 08:24 |
---|---|---|
ysionneau | or maybe it depends on your TLS model... | 08:24 |
ysionneau | what | 08:29 |
ysionneau | what's in this .rela.got section anyway shorne ? relocs for TLS module id and DTPOFF? | 08:29 |
shorne | ysionneau: yes, its the DTPOFF, in this case its for R_OR1K_TLS_IE_HI16 | 10:21 |
shorne | but you are right, it should not be creating .rela.got when its static | 10:21 |
shorne | it can just put the value directly into the .got | 10:21 |
shorne | which it does, so there are 2 issues I am looking at now it the linker (binutils-gdb/bfd/elf32-or1k.c) | 10:22 |
shorne | 1. Why does it try to do dynamic reloc writing when I have -static flat set. Likely a problem with the 'dynamic' flag. | 10:23 |
shorne | 2. 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 |
ysionneau | I mean, the .got.rela section it creates, is it empty? can you spot which symbols generates the reloc ? | 10:27 |
ysionneau | but yes most probably it's just a dynamic "switch" logic issue | 10:27 |
shorne | Well, yes, there is a glibc test thought, that uses these macros: https://github.com/stffrdhrn/or1k-glibc/blob/upstream-rebase/sysdeps/or1k/tls-macros.h | 10:29 |
shorne | specifically https://github.com/stffrdhrn/or1k-glibc/blob/upstream-rebase/sysdeps/or1k/tls-macros.h#L60-L64 | 10: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 |
shorne | | 10:29 |
shorne | so the gottpoffhi, generates the reloc | 10:30 |
shorne | Yeah, I think so. I was just looking into 2, as I couldn't see how the linker code chooses to skip .rela.got | 10:31 |
shorne | do you have much experience with binutils/bfd code? | 10:31 |
shorne | ysionneau: this is the line that evaluates dynamic is true | 10:33 |
shorne | https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf32-or1k.c;h=0d1336ceaccdc2a861c9bbb45b20c0931df0e0d2;hb=HEAD#l1625 | 10:33 |
shorne | 1625 dynamic = bfd_link_pic (info) | 10:33 |
shorne | 1626 || (sec && (sec->flags & SEC_ALLOC) != 0 | 10:33 |
shorne | 1627 && h != NULL | 10:33 |
shorne | 1628 && (h->root.type == bfd_link_hash_defweak || !h->def_regular)); | 10:33 |
shorne | breaking it down: bfd_link_pic (info) | 10:33 |
shorne | link_pic -> 0 | 10:34 |
shorne | bfd_link_hash_defweak 0 : def_regular 0 : def_dynamic 0 | 10:34 |
shorne | so, its the def_regular is not true | 10:34 |
shorne | which causes the logic to think it needs dynamic relocations | 10:35 |
shorne | The thing is I cheked other targets and they seem to use similar logic | 10:35 |
ysionneau | 16:29 < shorne> do you have much experience with binutils/bfd code? < not at all | 10:44 |
ysionneau | I only deal with libc so far | 10:44 |
ysionneau | my colleague deals with binutils/gcc | 10:44 |
ysionneau | sorry | 10:44 |
shorne | thats fine | 10:45 |
shorne | I think I figured out 2 | 10:45 |
shorne | when the linker processes objects it does a few passes | 10:46 |
shorne | 1. scan all symbols and map our the required sections and relocs etc | 10:47 |
shorne | 2. allocate sections, any sections that are not needed as per 1. are marked for removal | 10:47 |
shorne | 3. write our symbols, relocs, text to all section | 10:48 |
ysionneau | (I'd like to ramp up in toolchain developing knowledge though, in the mid-term future) | 10:48 |
shorne | The problem with "Why does the .rela.got section disappear", is because nothing was mapped to it in phase 1 | 10:49 |
shorne | which is expected | 10:49 |
shorne | but due to "1. wrong dynmic flag logic" it tries to write to .rela.got, and the linker fails | 10:50 |
shorne | now. I guess there is a mismatch between the "dynamic" flag in phase 1 and phase 2 | 10:50 |
shorne | I mean phase1 and phase3 | 10:50 |
ysionneau | so the linker thinks it is linking pic code? it should not be pic code, right? | 10:50 |
shorne | right it is not | 10:51 |
ysionneau | ah no the issue is with def_regular you said | 10:51 |
shorne | yeah | 10:51 |
ysionneau | I dont know what this is | 10:52 |
shorne | The issue with 2. is just me tyring to understand how the linker works :) | 10:52 |
shorne | I am just learning as things break | 10:52 |
ysionneau | hehe | 10:52 |
shorne | :) | 10:52 |
ysionneau | this is exactly what my colleagues says also | 10:52 |
ysionneau | I guess this is the only way for binutils/gcc learning... | 10:52 |
ysionneau | just have it crash until it does not anymore and you somehow understand whats going on | 10:53 |
ysionneau | I wonder what's more painful, gcc/binutils lacks of internal documentation ... or LLVM C++ | 10:53 |
shorne | the docs for gcc are pretty good, but only if someone gives you an overview of what it means first | 10:59 |
shorne | but, binutils is pretty sparse | 11:00 |
shorne | even glibc I have found is not well documented | 11:00 |
shorne | i.e. how do the ld.so internals work. | 11:00 |
ysionneau | I didn't look at glibc much so far | 11:02 |
ysionneau | just uClibc-ng | 11:02 |
ysionneau | and I reckon I had to do lots of code reading to understand whats going on | 11:02 |
ysionneau | I can tell you that in our toolchain, there is no dynamic = | 11:03 |
ysionneau | but | 11:03 |
ysionneau | https://dpaste.de/D7uB | 11:03 |
ysionneau | so "need_relocs" | 11:04 |
ysionneau | which seems a bit similar | 11:04 |
ysionneau | but anyway this code is not production ready, our tls is still a bit shacky | 11:11 |
shorne | re: https://dpaste.de/D7uB, right and no use of def_default | 11:16 |
shorne | ysionneau: what is your target if you don't mind me asking? | 11:19 |
ysionneau | Kalray k1c VLIW core | 11:22 |
ysionneau | 17:14 < shorne> re: https://dpaste.de/D7uB, right and no use of def_default < not in _elf_relocate_section ... but in other places | 11:23 |
ysionneau | k1c core is presented on slides 5 and 6 : http://gallium.inria.fr/seminaires/transparents/20190708.Cyril.Six.pdf | 11:26 |
ysionneau | shorne: I would have a question about _Unwind_ForcedUnwind in libgcc. Do you have it? Or do you have _Unwind_SjLj_ForcedUnwind ? | 11:32 |
ysionneau | does 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 |
shorne | we use _Unwind_ForcedUnwind with dwarf | 11:45 |
shorne | It worked last time I tested | 11:45 |
shorne | but recently looking at new tests it looks like there may be issues | 11:46 |
shorne | I havent investigated yet | 11:46 |
shorne | working on this linking issue | 11:46 |
shorne | ... I think its fixed now | 11:46 |
ysionneau | wow | 11:47 |
ysionneau | bravo :) | 11:47 |
shorne | ok, it works (I basically copied the 'dynamic' flag to be what riscv uses | 11:47 |
ysionneau | anyway, I kind of understand that if you dont support dwarf runtime you are basically screwed | 11:47 |
shorne | ) | 11:47 |
ysionneau | uclibc and glibc used to support loading SjLj (setjump longjmp) symbols from libgcc ... | 11:48 |
ysionneau | but they no longer support this | 11:48 |
ysionneau | so if you dont support dwarf2 exception it's dead. | 11:48 |
ysionneau | shorne: what kind of non-regression do you do to test that you didnt create an issue somewhere else? | 11:49 |
shorne | right, I did remember debugging some nast issue with return handling with the libgcc/gcc port when I was working on it | 11:49 |
shorne | ysionneau: well, I will have to run the full gcc/binutils/gdb + now glibc tests to see how it goes | 11:49 |
ysionneau | the culprit seems to be: https://git.uclibc.org/uClibc/commit/?id=6cbeaa5dd11a1b506a8a97b4dfb4e632240f9953 | 11:49 |
ysionneau | shorne: ok :) | 11:50 |
ysionneau | what's the strongest supported libc for or1k? uclibc-ng? glibc? musl? | 11:50 |
ysionneau | just out of curiosity | 11:50 |
shorne | I would say musl | 11:52 |
shorne | + newlib as well | 11:53 |
shorne | newlib is the baremetal libc which we do use a lot, as many people use openrisc as more of a uController | 11:53 |
ysionneau | ok | 11:53 |
ysionneau | we do have newlib also, for the embedded use cases | 11:53 |
shorne | glibc I am just working on now to get the port in shape | 11:53 |
shorne | uclibc-ng support was better when waldemar was on this chat room asking me for help with test regressions | 11:54 |
ysionneau | hehe | 11:54 |
shorne | But he has been away for a bit | 11:54 |
ysionneau | he is very slowly responding those days | 11:54 |
ysionneau | but he still does apply patches | 11:55 |
shorne | I need to get to bed, the glibc tests are passing now | 11:56 |
shorne | I mean, compiling now | 11:56 |
shorne | many passing, some failing | 11:56 |
shorne | Ill have to look more at it tomorrow if I get time | 11:57 |
ysionneau | good luck | 12:05 |
ysionneau | gn8 | 12: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!