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