summaryrefslogtreecommitdiff
path: root/toolchain
diff options
context:
space:
mode:
Diffstat (limited to 'toolchain')
-rw-r--r--toolchain/elfosabi_hurd.mdwn83
1 files changed, 83 insertions, 0 deletions
diff --git a/toolchain/elfosabi_hurd.mdwn b/toolchain/elfosabi_hurd.mdwn
new file mode 100644
index 00000000..4d60f761
--- /dev/null
+++ b/toolchain/elfosabi_hurd.mdwn
@@ -0,0 +1,83 @@
+[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!meta title="ELFOSABI_HURD"]]
+
+[[!tag open_issue_binutils open_issue_glibc]]
+
+
+# [[!debbug 630180]]
+
+
+# [[open_issues/binutils]] commit 51b2f560ad035dffad3371093f8e5c80608d196c
+
+Usage of `ELFOSABI_LINUX`/`STB_GNU_UNIQUE`. Has also been wrong before already
+with respect to `STT_GNU_IFUNC`?
+
+
+# IRC
+
+IRC, freenode, #debian-hurd, 2011-06-11
+
+ <pinotree> youpi: not that there would be any hope in that, but id you try
+ asking doko about the gcc miscompiling (wrong elf format) issue?
+ <youpi> I didn't
+ <youpi> I'm still investigating
+ <youpi> maybe it's a binutils change actually
+ <pinotree> youpi: hm, are you sure it could be binutils? after all, even
+ some .o files are produced with format gnu/linux, so there's no binutils
+ involved up to that point of thecompilation yet?
+ <youpi> as is
+ <youpi> "as", I mean
+ <pinotree> i see
+ <youpi> since it's so unclear, I really prefer to investigate before
+ bothering doko
+ <pinotree> youpi: maybe i could be wrong,
+ <pinotree> in binutils, bfd/elf.c, around lines 9580
+ <youpi> the faulty thing seems to be gnu_unique_object in the source .s
+ file produced by g++
+ <pinotree> that's what that comment (which changed wrt binutils from eg
+ march) says
+ <youpi> seems to concur with my comment above :)
+ <pinotree> http://paste.debian.net/119542/ ‘¡û extract of diff
+ <youpi> ok, that really seems the culprit
+ <youpi> starting reportbug
+ <pinotree> who's the fault then?
+ <youpi> binutils
+ <youpi> it shouldn't hardcode LINUX
+ <pinotree> g++ emitting those symbols, or binutil considering them "linux"?
+ <youpi> it's a GNU thing, not a Linux thing
+ <pinotree> ah ok
+ <youpi> it's the same dynamic linker actually
+ <pinotree> youpi: http://sourceware.org/bugzilla/show_bug.cgi?id=10549
+ <pinotree> see the reporter :)
+ <youpi> heh
+ <pinotree> youpi: see also gas/config/obj-elf.c:1725
+ <pinotree> (another change related to that bug, it seems)
+
+IRC, freenode, #hurd, 2011-06-15
+
+ <jkoenig> also I still get an "ELF file OS ABI invalid" error with binutils
+ 2.21.52.20110606-2+hurd.1, is that expected?
+ <youpi> tschwinge: oops, the OS ABI invalid is actually due to the file
+ being marked GNU/Hurd
+ <youpi> I guess the linker is simply not aware that it should accept
+ GNU/Hurd
+ <tschwinge> youpi: So we got to work on glibc'S ld.so to teach it aboput
+ the Hurd OS ABI? (Or probably simply make that equivalent to the Linux
+ one?)
+ <youpi> probably simply an equivalent
+ <youpi> ELFOSABI_HURD is missing from elf/elf.h, for a start...
+ <youpi> linux' glibc has tests in lsdodefs.h
+ <youpi> the VALID_ELF_OSABI macro
+ <youpi> it's thus apparently a matter of providing an ldsodefs.h file with
+ VALID_ELF_HEADER, VALID_ELF_OSABI and VALID_ELF_ABIVERSION definitions
+ <youpi> (and include_next the generic one)
+ <youpi> I've prepared a patch for ldsodefs.h, I'll test it