[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #12 from Nick Alcock --- Thanks! I already have that locally -- I really should finish testing and submit everything. Simply removing __thread won't do, unfortunately: it makes libctf even less threadsafe than it already is, and I'm trying to get it *more* threadsafe. The only thing that's held me off fixing this bug (other than pressure of other work, like the deduplicating CTF linker) is the annoyance of having to implement bsearch_r :) but I suppose I can take the bsearch from glibc without worries. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 Michael Forney changed: What|Removed |Added Attachment #12084|0 |1 is obsolete|| --- Comment #11 from Michael Forney --- Created attachment 12085 --> https://sourceware.org/bugzilla/attachment.cgi?id=12085=edit Patch fixing issue 2 (v2) Whoops, my local change removing __thread snuck into this patch. Added a new version which only adds the macro fallbacks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #10 from Michael Forney --- I ran into issues 1 (__thread) and 2 (__libctf_*_) when building binutils-2.33.1 with my C compiler (https://git.sr.ht/~mcf/cproc). I found this issue when I went to submit a patch for issue 2, so I attached the patch here instead. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 Michael Forney changed: What|Removed |Added CC||mforney at mforney dot org --- Comment #9 from Michael Forney --- Created attachment 12084 --> https://sourceware.org/bugzilla/attachment.cgi?id=12084=edit Patch fixing issue 2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #8 from Nick Alcock --- Nice diagnosis! Looks like there are some bugs in busybox and tcc to fix. I agree that the first three things you reported are bugs, and I'll fix them once I get a spare moment. Thanks for the report! -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #7 from Harald van Dijk --- (In reply to Harald van Dijk from comment #6) > This is not compatible with how libbfd.a is created, > where ar is invoked multiple times, so if I use this instead, readelf does > build, but nothing else. ar being invoked multiple times was due to a misdetected maximum command line argument length. If I override the configure check by setting lt_cv_sys_max_cmd_len=-1, binutils links successfully when using tcc's ar. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #6 from Harald van Dijk --- (In reply to Harald van Dijk from comment #5) > (In reply to Nick Alcock from comment #4) > > I'll try to get tcc working in a bit, but in the absence of that you could > > try to figure out which symbol in ctf-open-bfd.c is at fault (or if it's all > > of them). > > I'll take a look. Oh this is annoying, it depends on the ar being used. On my uclibc-ng system, the ar used for building binutils is busybox ar (with a wrapper script to accept the right options). busybox ar creates archives that do not contain a "/" entry. When that is missing, tcc just links the whole archive. tcc comes with a built-in archiver (tcc -ar) which does not have this problem and can build readelf successfully. It does, however, have a different problem: tcc -ar rc lib.a objs... overwrites lib.a. It always creates a new archive. This is not compatible with how libbfd.a is created, where ar is invoked multiple times, so if I use this instead, readelf does build, but nothing else. I think these are bugs in busybox ar and tcc -ar. It would be nice to work around them, but it is not really a bug in binutils. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #5 from Harald van Dijk --- (In reply to Nick Alcock from comment #4) > The C compiler shouldn't affect anything here: the linker in use is what > matters. tcc has its own built-in linker. > I'll try to get tcc working in a bit, but in the absence of that you could > try to figure out which symbol in ctf-open-bfd.c is at fault (or if it's all > of them). I'll take a look. > Surely the thing doesn't just pull in the whole .a file blindly: you'd > hardly be able to link anything when using tcc if that were true (and many > binaries would be enormous: .a files are used as intermediate stages in > building larger projects a *lot*). You're right that it is not as simple as that. tcc's linker has the same whole-archive/no-whole-archive option that binutils ld has and it looks like it does default to no-whole-archive. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #4 from Nick Alcock --- The C compiler shouldn't affect anything here: the linker in use is what matters. I'll try to get tcc working in a bit, but in the absence of that you could try to figure out which symbol in ctf-open-bfd.c is at fault (or if it's all of them). Surely the thing doesn't just pull in the whole .a file blindly: you'd hardly be able to link anything when using tcc if that were true (and many binaries would be enormous: .a files are used as intermediate stages in building larger projects a *lot*). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #3 from Harald van Dijk --- (In reply to Nix from comment #1) > 4: This is very strange. In 2.33, readelf carefully calls only .o files that > do not cite BFD functions, even indirectly, so ctf-open-bfd.o is never > pulled in and BFD is never needed. (I just checked 2.33, and there are no > references to any ctf-open-bfd.o functions in anything else in libctf, and > no references from readelf either. You can figure out what the dead refs are > by #if 0'ing out the contents of libctf/ctf-open-bfd.c and doing make > all-libctf, then rebuilding readelf and seeing what the reported locus of > undefined symbol errors is now. (objdump will, obviously, fail to build if > you do this, because it uses the functions you just removed, but that's not > a problem). If I comment out the entire file, readelf links successfully. It seems that with tcc, merely being included in libctf.a is enough to require its dependencies to be present as well. > In trunk, we generate two .a / .so's, one containing ctf-open-bfd.o and the > other not, in part to make this separation more explicit, but I really > thought I had it working in 2.33 too. Well, what's in 2.33 does work with gcc... Having two separate libraries seems like it should satisfy tcc. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #2 from Nick Alcock --- (For the avoidance of doubt: the commenter above was me, logged in under the wrong bugzilla account.) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 Nick Alcock changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-10-21 Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 Nick Alcock changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 Nick Alcock changed: What|Removed |Added CC|nix at esperi dot org.uk |nick.alcock at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 Nix changed: What|Removed |Added CC||nix at esperi dot org.uk --- Comment #1 from Nix --- Thanks for the heads-up! I'll get to all of these soon. 1: We can't remove __thread when gold is disabled because libctf is intended to be usable from outside binutils, and some of those clients might create threads (and there are existing threaded clients that will switch to libctf once the shared-lib version is out in 2.34): so this bit has to be threadsafe: there are still a few parts of libctf that are not threadsafe, but I consider that a bug. The use of __thread was just a workaround for the lack of a bsearch_r(): it might be easiest to fix this by just implementing a bsearch_r of my own. G. 2: Ouch, what an oversight. Fallbacks used to exist but I mistakenly removed them when integrating everything into binutils. Will definitely fix. 3: I honestly had no idea wasn't a purely-glibc thing (I should have checked, I have uclibc-ng here and everything). Agreed. 4: This is very strange. In 2.33, readelf carefully calls only .o files that do not cite BFD functions, even indirectly, so ctf-open-bfd.o is never pulled in and BFD is never needed. (I just checked 2.33, and there are no references to any ctf-open-bfd.o functions in anything else in libctf, and no references from readelf either. You can figure out what the dead refs are by #if 0'ing out the contents of libctf/ctf-open-bfd.c and doing make all-libctf, then rebuilding readelf and seeing what the reported locus of undefined symbol errors is now. (objdump will, obviously, fail to build if you do this, because it uses the functions you just removed, but that's not a problem). In trunk, we generate two .a / .so's, one containing ctf-open-bfd.o and the other not, in part to make this separation more explicit, but I really thought I had it working in 2.33 too. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
