[Bug ld/31619] New: sh: fdpic linker breaks function pointer equality
https://sourceware.org/bugzilla/show_bug.cgi?id=31619 Bug ID: 31619 Summary: sh: fdpic linker breaks function pointer equality Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: bugdal at aerifal dot cx Target Milestone: --- Created attachment 15453 --> https://sourceware.org/bugzilla/attachment.cgi?id=15453=edit proposed fix The sh linker's handling of function descriptors seems to be based on a mistaken idea that the linker can create "canonical" function descriptors for dynamic symbols, which provide the definition of the public address of a function. This is not what the ABI document specifies, and is simply not possible, because the linker logic to create these function descriptors does not preserve enough information for a dynamic linker to find the descriptors it created and associate them with symbol names. The issue came up as part of work on fdpic support for xtensa, where the same confusion arose and it was noted that neither the WIP xtensa fdpic support, nor the existing sh fdpic support, was doing the right (or even workable) thing. On SH, the bug has two layers: 1. The SYMBOL_FUNCDESC_LOCAL macro wrongly checks whether the symbol is defined locally, rather than whether it is externally visible. Whenever the symbol is externally visible (outside the executable/DSO being created), the output must preserve any R_SH_FUNCDESC relocation for the dynamic linker to see. 2. sh_elf_relocate_section wrongly "optimizes" FUNCDESC relocations that would call locally, but which SYMBOL_FUNCDESC_LOCAL says can't have their addresses defined locally, to be section-based rather than symbolic. This makes it so that, even if the first issue is fixed, the output is still broken. I have a proposed patch (attached) fixing both. Note that, even with these, GCC will not do the right thing because it emits R_SH_GOTOFFFUNCDESC relocations rather than R_SH_GOTFUNCDESC relocations when the symbol is locally defined. This can be worked around for testing by passing -fPIC to GCC so that it generates code suitable for use in a shared library. I will be submitting a separate patch for GCC to fix the default main-program behavior. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31171] New: ld generates gratuitous PLT entries on ARM
https://sourceware.org/bugzilla/show_bug.cgi?id=31171
Bug ID: 31171
Summary: ld generates gratuitous PLT entries on ARM
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
This looks like it may be the same as
https://sourceware.org/bugzilla/show_bug.cgi?id=22374 for other archs. I was
testing with the program:
#include
static void (*f)() = abort;
int main() {
return (long)f;
}
built with -O0 so there's no attempt at determining that f doesn't change and
inlining it. The emitted asm and .o file clearly do not contain any references
to abort from .text; however, the linked executable has JUMP_SLOT relocations
and abort@plt instructions.
Both 32-bit arm and aarch64 are affected.
The condition for generating a PLT entry (and analogously, for data, a copy
relocation) should be that the symbol is referenced from text, not that it's a
function-type symbol being referenced at all. References from data do not need
PLT entries or copy relocations.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gold/27625] New: powerpc64: gold erroneously rejects linking code that calls __tls_get_addr
https://sourceware.org/bugzilla/show_bug.cgi?id=27625 Bug ID: 27625 Summary: powerpc64: gold erroneously rejects linking code that calls __tls_get_addr Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: bugdal at aerifal dot cx CC: ian at airs dot com Target Milestone: --- When targeting powerpc64, attempting to link a source file that calls __tls_get_addr directly (rather than produced as a result of a thread-local object access with the associated relocations to facilitate relaxation) produces the message: "error: __tls_get_addr call lacks marker reloc" This breaks linking of glibc and musl libc. The check that's triggering seems to correspond to one lld wrongly added and then reverted in https://github.com/llvm/llvm-project/commit/9267caebfa9209e4ae69517043d008d1b83307aa (see also https://reviews.llvm.org/D92959), which the BFD linker does not do. Calls to __tls_get_addr are only candidates for relaxation with the appropriate relocations attached to them; otherwise, they should be treated as normal function calls and should not produce link errors. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/26541] gold makes incorrect usage of fallocate in fallback path
https://sourceware.org/bugzilla/show_bug.cgi?id=26541 --- Comment #5 from Rich Felker --- Ah no, at least according to your patch the original gold bug seems to be there still too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/26541] gold makes incorrect usage of fallocate in fallback path
https://sourceware.org/bugzilla/show_bug.cgi?id=26541 --- Comment #2 from Rich Felker --- Why is this still open? It's trivial to fix. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 --- Comment #13 from Rich Felker --- This patch keeps expanding way beyond the scope of what I can commit to review, and I don't think it's nearing something that fixes the problem. It's not clear to me if bfd_stat uses fstat on the open file (safe) or stat on the name (unsafe) and I could go look this up, but this is ballooning into something much larger than I can take on and after I look that up there will be something else and something else. You really need someone who understands both this code and temp file/writable-dir TOCTOU race vulnerabilities to work with you on the fix. Short of that, the only thing I can say with confidence is that the chmod/chown behavior should be removed entirely (and even then I'm not sure it'd be safe to run in directories other users can write to, but at least it wouldn't explicitly be offering a feature meant only for that use case and encouraging users to use it that way). On major bug I will comment on individually -- in smart_rename you added a line: to_fd = open (to, O_WRONLY | O_TRUNC | O_BINARY, 0777); I don't understand the motivation for that at all, but it's creating a *completely new vulnerability* of the type we're discussing here. (And even when it's not being maliciously exploited, it will cause data loss whenever the file is a hardlink!) It looks like you're trying to avoid calling stat on the target because I told you that's unsafe, but instead you're truncating the target, which might be a symlink or hardlink to any file on the whole filesystem, *then* checking, after truncating it, whether it has any hardlinks. Here you really do want to stick with lstat. You're not using the result to copy permissions, just to see if the target you're about to replace would be a hard link or symlink, in which case I think the idea is to overwrite the existing file rather than replacing it so the linked status is preserved (at the cost of atomicity). There inherently will be races where you do "the wrong thing" here, and opening the file first doesn't do anything to avoid that. But they should not be "exploitable" for anything beyond annoyance. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 --- Comment #11 from Rich Felker --- Yes, see my footnote in comment 4. That works just as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 --- Comment #9 from Rich Felker --- > > 1. make_tempname with fd_return==NULL is *always* a bug, > Well, I would argue that it is only a bug if the temporary file is going to be manipulated by other system functions. Are you going to create a temp file but never write anything to it? That seems pointless. As soon as you open it for write, you have bug, and probably an exploitable one. There is fundamentally no way of knowing it's the same temp file you created anymore since the only reference you retained to it is a name, which is ephemeral. > > 2. smart_rename needs(*) *two* fds, not just one > Actually it does this. It is just that only one fd is passed in (the open > temporary file). The function itself opens the destination file before it attempts to perform any other operations on it. It doesn't. The second file descriptor I'm talking about is the one to the original file that was read from, that will be replaced by the rename. This is the one you need to read old ownership/mode from with fstat. Using the name here is not safe (wrt using the right data). As long as you use O_NOFOLLOW and check that the link count is 1, I don't think it's *exploitably* wrong, but I wouldn't want to bet on that. It's still conceptually wrong and should just be done the right way. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 --- Comment #4 from Rich Felker --- That's a lot to review without being familiar with the code, but a couple things I can tell you right off: 1. make_tempname with fd_return==NULL is *always* a bug, and defeats the whole purpose of mkstemp. It's the same as if you were using the deprecated insecure mktemp. Except in a directory that nobody else can write, or with sticky bit, you can never again be sure the name refers to the file you created. 2. smart_rename needs(*) *two* fds, not just one. It needs the fd of the file you're replacing, to get the ownership and mode from it via fstat, and the fd of the temp file it will be renaming over top of the old name, to set the ownership and mode via fchown and fchmod. If either of these is unavailable it can't safely copy ownership or mode information. * Technically the caller could have called fstat on the original file being replaced already, and pass the owner/mode information (or the whole stat structure) into smart_rename rather than passing the fd, but I think it makes more sense to just pass the fd. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 --- Comment #2 from Rich Felker --- It's not that smart_rename should open it and use fchown+fchmod on the result; indeed as you figured that has the same race. The problem is that you threw away the only safe way to perform modifications on the temp file you just created: the fd returned by mkstemp. In addition to the source and dest names, smart_rename needs to take the already-open file descriptors for source and dest that were used for the objcopy (or whatever) operation. Note: I missed this in the original report, but it's also important to use fstat on the file that will be replaced, rather than lstat on the pathname, to ensure the permissions that will be set on the new file are the ones of the file that was processed, and not some other file that was substituted in its place. Failure to do this right may not be exploitable, since the hard link count is checked, but it's still possibly erroneous. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 Rich Felker changed: What|Removed |Added CC||siddhesh at sourceware dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26945] New: Unsafe chown+chmod in smart_rename, possibly elsewhere
https://sourceware.org/bugzilla/show_bug.cgi?id=26945 Bug ID: 26945 Summary: Unsafe chown+chmod in smart_rename, possibly elsewhere Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: bugdal at aerifal dot cx Target Milestone: --- At least objcopy and perhaps other utilities generate a temp file safely with mkstemp then rename it to atomically replace the original, but the smart_rename function (binutils/rename.c) used to do this then performs chown and chmod on the target pathname rather than fchown/fchmod on the file. This is subject to all the classic symlink race attacks and can be used to get root to chown or chmod arbitrary files. In a worst case, with multiple racing file replacements, it can be used to chmod arbitrary root-owned files suid. This is only an issue if the file being operated on is in a directory writable by the attacker. However, the whole point of the ownership/permissions restoration logic seems to be for the case where root is operating on other users' files, and it seems likely that the directory will also be user-owned. I'm reporting this through public issue rather than security because I don't think there are direct ways to exploit it programmatically in a normal environment. There may be when the affected tools are used in automated scripts acting on user-owned files, though. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25882] .gnu.attributes are not checked for shared libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=25882 --- Comment #9 from Rich Felker --- OK, I should have read more before commenting. My comments in particular pertain specifically to powerpc64 although other archs might be affected too. I see that the error was downgraded to a warning since the breaking change first appeared in a release, which is an improvement, but it's still likely going to lead to people doing very wrong things based on that warning. For example, Alpine Linux got this merge request: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13547 which would have created a broken Frankenstein-ABI to make the error message go away rather than fixing the problem. I can envision folks doing the exact same sort of thing when they see a warning, because I get/see wrong "warning fix" patches all the time for compiler warnings. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25882] .gnu.attributes are not checked for shared libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=25882 --- Comment #8 from Rich Felker --- Also note that while, for musl targets, this issue could also be fixed just by getting gcc not to build its ld128 functions in libgcc_s, there are also people using glibc's ld64 ABI, and glibc necessarily has (as ABI) both ld64 and ld128 functions in the same shared library. So I don't think there's any complete fix without reverting this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25882] .gnu.attributes are not checked for shared libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=25882 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #7 from Rich Felker --- This should be reverted. It breaks linking anything that uses libgcc_s.so.1 on musl libc, since gcc builds ld128 floating point functions into libgcc unconditionally, but musl's ABI does not use them. (And in general it breaks any use of -mlong-double-64 in a setting where shared libgcc will be used.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/26541] New: gold makes incorrect usage of fallocate in fallback path
https://sourceware.org/bugzilla/show_bug.cgi?id=26541 Bug ID: 26541 Summary: gold makes incorrect usage of fallocate in fallback path Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: bugdal at aerifal dot cx CC: ian at airs dot com Target Milestone: --- In gold's output.cc gold_fallocate, after posix_fallocate() fails with a non-fatal error, it tries fallocate(). However, the code assumes fallocate() follows the same contract as posix_fallocate(), returning an error number, rather than behaving as specified in the Linux man page for fallocate and returning -1 with errno set to indicate the error. This makes EOPNOTSUPP into a fatal error, since -1 is not equal EINVAL, ENOSYS, or EOPNOTSUPP. This was likely overlooked because glibc's posix_fallocate (see https://sourceware.org/bugzilla/show_bug.cgi?id=15661) has an unsafe emulation in its own fallback path rather than returning EOPNOTSUPP to the caller. However, it impacts other systems; the problem was reported to me by a musl user on reiserfs, where fallocate is not implemented. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/23825] Linker creates COPY relocs for reference to TLS symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=23825 --- Comment #8 from Rich Felker --- To clarify what I mean about ABI and copy relocations, prior to RISC-V doing this, there was no arch where it was unsafe to have extensible (existing part's meaning remains same, new parts added to end) arrays or structs in shared library TLS. This kind of thing is very useful for dispatch arrays, etc. Copy relocations break that. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/23825] Linker creates COPY relocs for reference to TLS symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=23825 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #7 from Rich Felker --- Please, just teach GCC not to do this! RISC-V has proper PC-relative addressing and thus the GOT access for IE model is essentially free. There is no reason it should be doing a hack with LE model that imposes a need for copy relocations, doubles the size of shared-library TLS that gets referenced in the main program, and (worst of all!) makes the size of TLS arrays/structures into ABI due to the copy relocation. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25184] New: or1k gas errors on any backwards jump on 32-bit host
https://sourceware.org/bugzilla/show_bug.cgi?id=25184 Bug ID: 25184 Summary: or1k gas errors on any backwards jump on 32-bit host Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: bugdal at aerifal dot cx Target Milestone: --- I don't understand the lisp-like language the opcode C files are generated from, so I don't have a root cause for this, but the problem is in opcodes/or1k-ibld.c, or1k_cgen_insert_operand. For at least the DISP26 case, and probably others, arithmetic that's logically signed is performed as unsigned. On 64-bit hosts, prior unsigned arithmetic (long-bfd_vma, where bfd_vma is unsigned long) has left 32 high 1 bits, so that unsigned right-shift followed by truncation gives the right result. But on 32-bit hosts, the top two bits end up zero, causing, for example, an offset of -8 to be interpreted as 0x3ff8, producing an "operand out of range" error. Minimal test case: 1: l.nop l.j 1b There may also be integer overflows in insert_normal (1L shifted left up to 31 bits, I think) but these don't seem to be getting optimized in an unsafe manner with the host compilers I've used. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25184] or1k gas errors on any backwards jump on 32-bit host
https://sourceware.org/bugzilla/show_bug.cgi?id=25184 Rich Felker changed: What|Removed |Added Target||or1k-*-* -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25056] ld fails to bind DTPMOD at link time for pie on arm
https://sourceware.org/bugzilla/show_bug.cgi?id=25056 --- Comment #3 from Rich Felker --- It is a correctness issue for static linking, where my intent (as the one who introduced static pie) was that presence of any unresolved relocations except load-address-relative ones is an error. If you think that's a bad policy and that dtpmod relocations should be accepted (filled in as "1" in self-relocation process), it'd be mildly disappointing but something we could move forward with. -- 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 ld/25056] ld fails to bind DTPMOD at link time for pie on arm
https://sourceware.org/bugzilla/show_bug.cgi?id=25056 --- Comment #1 from Rich Felker --- Link for convenience: https://sourceware.org/bugzilla/show_bug.cgi?id=22570 I suspect there may be other targets with exactly the same issue. There should probably be a generic test for all targets that asserts no DTPMOD type relocations in static PIE output (also, none for locally defined TLS symbols in regular dynamic PIE output). -- 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 ld/25056] New: ld fails to bind DTPMOD at link time for pie on arm
https://sourceware.org/bugzilla/show_bug.cgi?id=25056 Bug ID: 25056 Summary: ld fails to bind DTPMOD at link time for pie on arm Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: bugdal at aerifal dot cx Target Milestone: --- Created attachment 12015 --> https://sourceware.org/bugzilla/attachment.cgi?id=12015=edit patch to fix Identical to #22570 for mips. -- 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 ld/23683] ld --help text misspells -z stack-size=SIZE option
https://sourceware.org/bugzilla/show_bug.cgi?id=23683 --- Comment #2 from Rich Felker --- Thanks. I was still using 2.27 and should have tagged that in the report, and should have checked later history for a fix. -- 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 ld/23683] New: ld --help text misspells -z stack-size=SIZE option
https://sourceware.org/bugzilla/show_bug.cgi?id=23683 Bug ID: 23683 Summary: ld --help text misspells -z stack-size=SIZE option Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: bugdal at aerifal dot cx Target Milestone: --- In the help text (ld --help), -z stack-size=SIZE is misspelled as -z stacksize=SIZE, which does not work. -- 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 ld/23428] ld does not put program headers in a code-only load segment
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 --- Comment #3 from Rich Felker --- I don't object to the patch as-is, but wouldn't it make more sense to make the program headers a first-class section with attribute alloc, so that they're semantically forced to be visible at runtime rather than just happening to fall into a load segment that exists due to other sections? This fix would be target-agnostic and would prevent the issue from ever arising for other targets. -- 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 ld/23428] ld does not put program headers in a load segment when static linking an executable
https://sourceware.org/bugzilla/show_bug.cgi?id=23428 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx -- 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 ld/22263] -fpie -pie generates dynamic relocations in text section
https://sourceware.org/bugzilla/show_bug.cgi?id=22263 --- Comment #17 from Rich Felker --- Yes, see #22570 in the list of duplicates, which includes a proposed patch for MIPS. -- 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 ld/22570] ld fails to bind DTPMOD at link time for pie on mips
https://sourceware.org/bugzilla/show_bug.cgi?id=22570 --- Comment #2 from Rich Felker --- Created attachment 10762 --> https://sourceware.org/bugzilla/attachment.cgi?id=10762=edit proposed fix -- 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 ld/22570] ld fails to bind DTPMOD at link time for pie on mips
https://sourceware.org/bugzilla/show_bug.cgi?id=22570 --- Comment #1 from Rich Felker --- The details of my assessment seem to have been written in terms of 2.25; with the changes from commit 0e1862bb40, the problem is now use of bfd_link_pic where bfd_link_dll was presumably intended. I'm attaching a patch which seems to correct the issue. -- 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 ld/22570] New: ld fails to bind DTPMOD at link time for pie on mips
https://sourceware.org/bugzilla/show_bug.cgi?id=22570
Bug ID: 22570
Summary: ld fails to bind DTPMOD at link time for pie on mips
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
When a symbol is defined and referenced in the main program, DTPMOD relocations
should be bound at ld time to module 1. This is mandatory for static linking
and merely an optimization in the case of dynamic linking. However the logic in
elfxx-mips.c's mips_elf_initialize_tls_slots() function is not pie-aware, and
uses info->shared rather than !info->executable as the condition for "output is
a shared library", thereby disabling the logic to resolve DTPMOD at link time.
As a result, static pie executables contain a DTPMOD relocation and will not
work without spurious runtime code to resolve it.
Note that this would be a non-issue if mips targets had TLS relaxation, but as
far as I can tell they don't. I suspect the same issue may exist on other
targets that lack relaxations but I was not able to find the corresponding
code.
Simple test case:
__thread int x = 42;
int main() { return x; }
The output, compiled with -fPIC (rather than -fPIE, to ensure that GD model
access is generated) and linked with -pie, should not contain any
R_MIPS_TLS_DTPMOD relocations, but does.
--
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 ld/22570] ld fails to bind DTPMOD at link time for pie on mips
https://sourceware.org/bugzilla/show_bug.cgi?id=22570 Rich Felker changed: What|Removed |Added Target||mips*-*-*-* -- 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 ld/21017] [microblaze] ld fails with missing _GLOBAL_OFFSET_TABLE_ symbol when all relocs are @GOTOFF
https://sourceware.org/bugzilla/show_bug.cgi?id=21017 --- Comment #1 from Rich Felker --- Created attachment 9735 --> https://sourceware.org/bugzilla/attachment.cgi?id=9735=edit patch to fix the bug This seems to fix the issue, but there may be additional reloc types that should be checked to fully fix it. -- 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 ld/21017] New: [microblaze] ld fails with missing _GLOBAL_OFFSET_TABLE_ symbol when all relocs are @GOTOFF
https://sourceware.org/bugzilla/show_bug.cgi?id=21017 Bug ID: 21017 Summary: [microblaze] ld fails with missing _GLOBAL_OFFSET_TABLE_ symbol when all relocs are @GOTOFF Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: bugdal at aerifal dot cx Target Milestone: --- When linking a program where all GOT-based relocations are GOT-relative rather than GOT slots, create_got_section is never called and linking fails due to missing _GLOBAL_OFFSET_TABLE_ symbol. This was found to happen when static linking non-PIC code with musl libc's crt1 which contains (gratuitous for non-pie, but not erroneous) logic to compute the address of _DYNAMIC if it's defined, but it probably can also happen in other situations where most object files are non-PIC but one contains PIC code with only GOT-relative relocations. -- 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 gold/17699] incorrect R_386_TLS_DTPMOD32 relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=17699 --- Comment #7 from Rich Felker --- Can you cite any documentation that a non-STT_TLS symbol reference is permissible in a DTPMOD relocation? -- 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 ld/17739] Assertion fail ../../bfd/elf32-sh.c:4504 on sh4 when compiling Qt5
https://sourceware.org/bugzilla/show_bug.cgi?id=17739 --- Comment #11 from Rich Felker --- Ping? -- 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 ld/20360] DT_TEXTREL appearing in output with no textrels on x86_64
https://sourceware.org/bugzilla/show_bug.cgi?id=20360 --- Comment #6 from Rich Felker --- To add some context, I suggested building without -Bsymbolic* in case the cause was relocations that would be textrels before -Bsymbolic* optimized them out. Looking at the source, particularly calls/jmps to C functions from asm source files without @plt, I would expect to see these in the readelf output without -Bsymbolic*, but I don't... -- 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 ld/20360] DT_TEXTREL appearing in output with no textrels on x86_64
https://sourceware.org/bugzilla/show_bug.cgi?id=20360 --- Comment #3 from Rich Felker --- At this point there's no testcase smaller than the dotnet/coreclr build, but I wanted to go ahead and post the bug here to get discussion moved to the tracker where it's relevant. I believe they have a way to slightly reduce the testcase by only linking a subset of what would normally go into the library. Waiting for their followup. -- 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 ld/20360] New: DT_TEXTREL appearing in output with no textrels on x86_64
https://sourceware.org/bugzilla/show_bug.cgi?id=20360 Bug ID: 20360 Summary: DT_TEXTREL appearing in output with no textrels on x86_64 Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: bugdal at aerifal dot cx Target Milestone: --- This is based on a bug report from dotnet CoreCLR: https://github.com/dotnet/coreclr/issues/6211 What seems to be happening is that bfd ld is producing a DT_TEXTREL header in the output shared library despite it not having any actual textrels (according to scanelf and manual reading of readelf output). This results in a library that is not loadable on hardened kernels (due to rejected mprotect operation), despite the fact that no relocations in the writable LOAD segment are actually needed/present. I have reviewed the readelf outputs but not the actual files and I have not performed the build myself. I'm asking the dotnet folks to follow up on this bug report with additional information. -- 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 ld/17739] Assertion fail ../../bfd/elf32-sh.c:4504 on sh4 when compiling Qt5
https://sourceware.org/bugzilla/show_bug.cgi?id=17739 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #10 from Rich Felker --- >From what I can tell, H.J. Lu's proposed fix depends on infrastructure not available in release versions of binutils. Is there any reasonable way to turn this into a fix that works for releases (we're using 2.25.1 now but could move to 2.26 if needed) or do we need some hackish workaround? -- 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 ld/19645] New: STT_COMMON symbols treated as non-data by -dynamic-list-data/-Bsymbolic-functions
https://sourceware.org/bugzilla/show_bug.cgi?id=19645
Bug ID: 19645
Summary: STT_COMMON symbols treated as non-data by
-dynamic-list-data/-Bsymbolic-functions
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: bugdal at aerifal dot cx
Target Milestone: ---
If binutils is built with STT_COMMON support enabled, use of
-Bsymbolic-functions for libraries with visible data subject to copy
relocations produces broken output. Consider for example:
int foo;
int *bar() { return }
When linked as a shared library, there is no GLOB_DAT type relocation for foo.
The problem is in bfd/elflink.c, bfd_elf_link_mark_dynamic_symbol. It only
checks for STT_OBJECT, not STT_COMMON, when marking data as dynamic.
--
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 ld/19516] microblaze: invalid symbol indices in GLOB_DAT relocs
https://sourceware.org/bugzilla/show_bug.cgi?id=19516 Rich Felker changed: What|Removed |Added Target||microblaze*-*-* -- 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 ld/19516] microblaze: invalid symbol indices in GLOB_DAT relocs
https://sourceware.org/bugzilla/show_bug.cgi?id=19516 --- Comment #2 from Rich Felker --- Created attachment 8978 --> https://sourceware.org/bugzilla/attachment.cgi?id=8978=edit proposed fix Producing a symbolic GLOB_DAT relocation for a symbol that has been made local/hidden by setting dynindx to -1 cannot possibly work. It appears the binding of and/or conditions for using a relative relocation rather than a symbolic relocation was just wrong: either symbolic&_regular or already-hidden (dynindx==-1) should be sufficient for using a relative relocation, rather than demanding that the symbol be def_regular even if it was already hidden. -- 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 ld/19091] sh: FDPIC linker fails to produce DT_PLTGOT for some files
https://sourceware.org/bugzilla/show_bug.cgi?id=19091 Rich Felker changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Rich Felker --- Marking this as fixed since the patch was applied. -- 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 ld/19516] New: microblaze: invalid symbol indices in GLOB_DAT relocs
https://sourceware.org/bugzilla/show_bug.cgi?id=19516 Bug ID: 19516 Summary: microblaze: invalid symbol indices in GLOB_DAT relocs Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: bugdal at aerifal dot cx Target Milestone: --- Current git versions of musl libc (since commit ad1cd43a86) are producing a libc.so that crashes during startup due to a bogus GLOB_DAT relocations with symbol index 0xff in libc's dynamic symbol table. I don't have a minimal test case to reproduce it yet, but the problem seems to be an interaction of several features including --gc-sections, -Bsymbolic-functions, and possibly hidden-visibility weak references. I've identified the code that's producing these invalid relocations: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf32-microblaze.c;h=b9c32a4b2e9e09988e2a9e8898ccd888207f8794;hb=HEAD#l3293 The 'if' code path has some exclusions so that the 'else' path can be taken even when h->dynindx==-1, and in this case, it becomes 0xff when limited to the 24-bit symbol index field of r_info. IMO microblaze_elf_output_dynamic_relocation should have an assertion to check for index -1 when producing a relocation that references a symbol, since this is malformed. But I'm not sure whether fixing the above logic is sufficient to fix the bug. It's possible that these GOT slots referencing symbol index -1 should have been removed much earlier in the linking process. I'll try to follow up with a minimal test case or see if one of our users affected by the issue can do so. -- 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 ld/19516] microblaze: invalid symbol indices in GLOB_DAT relocs
https://sourceware.org/bugzilla/show_bug.cgi?id=19516 --- Comment #1 from Rich Felker --- For reference here is the link to the first version of musl affected which can be used to reproduce the bug: http://git.musl-libc.org/cgit/musl/commit/?id=ad1cd43a86645ba2d4f7c8747240452a349d6bc1 -- 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 ld/19091] sh: FDPIC linker fails to produce DT_PLTGOT for some files
https://sourceware.org/bugzilla/show_bug.cgi?id=19091 --- Comment #4 from Rich Felker --- OK. Should I submit a patch or do you just want to make the one-line change yourself? -- 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 ld/19091] sh: FDPIC linker fails to produce DT_PLTGOT for some files
https://sourceware.org/bugzilla/show_bug.cgi?id=19091 --- Comment #2 from Rich Felker --- Even with no GOT, not PLT, and no function descriptors, it's possible to have code which accesses local data via @GOTOFF displacements. If DT_PLTGOT is not emitted in the output _DYNAMIC, there is no way for the caller (which gets the GOT value from the dynamic linker, which in turn gets it from DT_PLTGOT) to provide a correct GOT pointer when calling into the library, and thus any data accesses via @GOTOFF displacements will be wrong. I think DT_PLTGOT simply must always be emitted in FDPIC output. Would something break if the size of the GOT is 0? -- 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 ld/19091] sh: FDPIC linker fails to produce DT_PLTGOT for some files
https://sourceware.org/bugzilla/show_bug.cgi?id=19091 Rich Felker changed: What|Removed |Added CC||kkojima at rr dot iij4u.or.jp -- 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 ld/19091] New: sh: FDPIC linker fails to produce DT_PLTGOT for some files
https://sourceware.org/bugzilla/show_bug.cgi?id=19091 Bug ID: 19091 Summary: sh: FDPIC linker fails to produce DT_PLTGOT for some files Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: bugdal at aerifal dot cx Target Milestone: --- Created attachment 8688 --> https://sourceware.org/bugzilla/attachment.cgi?id=8688=edit minimal test case Under some circumstances, the SH/FDPIC linker fails to produce a DT_PLTGOT in _DYNAMIC for a shared library despite the library containing code which needs a valid GOT pointer to run. This makes it impossible for the dynamic loader to load it correctly since it does not have a GOT pointer value to fill into function descriptors. The attached file is a minimal test case and includes instructions for assembling/linking in the comments. The circumstance triggering the error seems to be the complete lack of GOT or PLT relocations but the presence of static function descriptors. This can happen in a pure-code library which internally uses or returns function pointers to its own static or hidden functions. The problem seems to be in sh_elf_size_dynamic_sections (elf32-sh.c); removing the "&& htab->sgot->size != 0" condition here makes the linker work correctly for me: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf32-sh.c;h=9fa363615ddbb7629628b7fe500df93d0a27a8b0;hb=HEAD#l3612 However I am not sufficiently familiar with the code to know whether this is the correct fix or whether it might break other cases. -- 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 gas/18561] sh assembler wrongly constant-folds address expressions containing weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=18561 --- Comment #13 from Rich Felker bugdal at aerifal dot cx --- Nick, can you confirm that your latest patch does not break typical use of .size like Alan Modra was concerned it would? -- 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 gas/18561] sh assembler wrongly constant-folds address expressions containing weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=18561 --- Comment #15 from Rich Felker bugdal at aerifal dot cx --- Well that's not necessarily a show-stopper if there's a way to make it work (evaluate at as-time) in .size or other contexts that aren't actually section content and where a relocation cannot be emitted. However, some of the older GCC versions I'm using that are affected by this but and not easily patchable with Kazumoto Kojima's proposed patch for the GCC side (GCC issue 66609) are even more broken with respect to this weak+hidden issue even at the compiler level: they're inlining weak definitions! So unless I want to spend a lot of effort fixing bugs that were fixed half a decade ago in mainline GCC I think I just need to turn off all optimization based on visibility, and that should fix this issue. On the bright side, I think Kazumoto Kojima's patch works at least back to GCC 4.7 (with some minor adjustments to make it apply but no actual code changes). TL;DR: I'm okay with closing this issue and dealing with everything on the GCC side. -- 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 gas/18561] sh assembler wrongly constant-folds address expressions containing weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=18561 --- Comment #11 from Rich Felker bugdal at aerifal dot cx --- I filed the corresponding GCC bug, #66609, at the same time I filed this one. Here is the link for reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609 The bug report also contains a suggested fix, but I'm not sure if it's complete. -- 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 gas/18561] sh assembler wrongly constant-folds address expressions containing weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=18561 --- Comment #9 from Rich Felker bugdal at aerifal dot cx --- If this is the intended behavior, it should be documented as such. At the very least it's highly counter-intuitive, and a regression, albeit a very very old one. In any case I'll submit the patch I have for the GCC side. -- 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 gas/18561] sh assembler wrongly constant-folds address expressions containing weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=18561 --- Comment #4 from Rich Felker bugdal at aerifal dot cx --- Indeed, that fixes it. However I'm skeptical of the way you're making the change: 1. S_FORCE_RELOC already has logic to force relocations for weak symbols when the strict argument is nonzero, so I wonder if something is wrongly calling it with strict=0 instead of strict=1? 2. Resolving the value of a weak symbol at as-time is always wrong, regardless of target or 'strictness' (whatever that's intended to mean). If the bug were in an sh-specific file, I would be satisfied with an sh-specific fix, but since it seems to be in symbol.c, this may indicate a bug that's affecting other targets too, and that should be fixed globally rather than via a target-specific optional macro. Thoughts? -- 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 gas/18561] sh assembler wrongly constant-folds address expressions containing weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=18561 --- Comment #7 from Rich Felker bugdal at aerifal dot cx --- I like it, but I think some effort should be put into understanding why the wrong code was there to begin with and what the intent was. Here is the commit that broke it: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=ae6063d440ba5ec28af81e9fc899cc099561339e;hp=f0abc2a11f47c3ecdfe0b54421092d17c70fc5f2 And like all awful GNU changelog messages, there is no explanation whatsoever of the motivation/purpose for the changes, only redundant statements of change content that could be reproduced by the version control logs. To me, the logic in generic_force_reloc looks wrong: non-null fix-fx_subsy is not a valid condition for doing a fixup instead of a relocation. But the problem may be deeper. It looks like many targets are affected, not just sh. -- 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 gas/18561] sh assembler wrongly constant-folds address expressions containing weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=18561 --- Comment #2 from Rich Felker bugdal at aerifal dot cx --- No. I believe I actually tried something near-identical before reporting this bug, but I just tried your patch to be sure, and there is still no relocation in the output object file. -- 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 gas/18561] New: sh assembler wrongly constant-folds address expressions containing weak symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=18561 Bug ID: 18561 Summary: sh assembler wrongly constant-folds address expressions containing weak symbols Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: bugdal at aerifal dot cx Target Milestone: --- Minimal test case: .global a .global b .weak a .align 2 a: .long 0 b: .long a-. The output should contain a R_SH_REL32 relocation, but instead it contains a constant. This bug affects gcc, which produces such expressions for intra-DSO PIC function calls; if the callee has a local weak definition; strong definitions will fail to override at link time. This could be fixed on the GCC side by having gcc explicitly produce @PCREL references rather than using arithmetic with ., but either way I think this is a serious gas bug that needs to be fixed. -- 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 gas/16858] weak external reference has wrong value
https://sourceware.org/bugzilla/show_bug.cgi?id=16858
Rich Felker bugdal at aerifal dot cx changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||bugdal at aerifal dot cx
Resolution|FIXED |---
--- Comment #20 from Rich Felker bugdal at aerifal dot cx ---
The fix that was applied only fixed PC-relative relocations (direct calls).
Global data containing a function pointer to a weak function is still broken
exactly the same way it was broken before: the value is off by the offset of
the definition in the object file's .text section. The proper fix should have
been removing the ENTIRE top-level #if block containing the offending code,
which is wrong in all cases, not simply disabling it in the case
!fixP-fx_pcrel.
Minimal test case (use -O0 to ensure non-reordering so the offset of f in .text
is not 0):
void dummy() {}
void f() {}
void g() __attribute__((weak,alias(f)));
void *p = (void*)f;
void *q = (void*)g;
With the offending code/bug present, p contains f and q contains dummy. With
it removed, both p and q contain f(==g). (Observed with objdump.)
--
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 gold/17699] incorrect R_386_TLS_DTPMOD32 relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=17699 Rich Felker bugdal at aerifal dot cx changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #1 from Rich Felker bugdal at aerifal dot cx --- Some follow-up regarding my (Rich Felker) reasoning for why the reloc gold is producing is wrong: 1. The existing convention for producing a DTPMOD reloc for this DSO itself is to omit the symbol reference. This is what gold does on other archs and what BFD ld has always done. 2. Semantically, a symbol pointing to a section does not even make sense as the target for a TLS relocation. The targeted symbol for such a reloc must be TLS type (STT_TLS). Simply the fact that the targeted section happens to be a TLS-related section does not make it a TLS symbol. If anything, by a principle of least surprise, such a symbol should resolve to the TLS image (but for BSS that doesn't even exist) rather than the resulting thread-local storage. 3. In my opinion, STT_SECTION symbols are not valid in the dynamic symbol table at all. Sections are not meaningful at load/execution time, and it's arguably even valid to strip the section headers if you really want to. I'm not clear on why glibc's dynamic linker accepts this relocation; probably it's simply a consequence of an implementation detail of the order in which operations are performed. But musl's dynamic linker is not accepting it, and I don't see any logically consistent way to accept it short of hacks to just ignore the referenced symbol and treat it as a null symbol reference, so I'd much rather see this fixed in gold than work on hacks to work around it. -- 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/16698] BFD (GNU Binutils) 2.24 assertion fail elf32-arm.c:12387
https://sourceware.org/bugzilla/show_bug.cgi?id=16698 Rich Felker bugdal at aerifal dot cx changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #12 from Rich Felker bugdal at aerifal dot cx --- For musl libc.a, neither stdin.o nor fflush.o should be pulled in unless they're actually used. For stdin.o, that means referencing stdin itself or a function (like scanf or getchar) that explicitly uses stdin. For fflush.o, the users are assert, getpass, fclose, freopen, and the stdio_ext.h functions. So this seems wrong: it seems they're getting pulled in via crt1.o - __libc_start_main - exit As for: if i can find a way to get ld to list all the object files it pulls in from libc.a, i could extract those and attach them here. Won't -Wl,-M do this? Or you could just look at a non-stripped output binary with debug symbols, which should show the object file filenames that were linked. -- 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 ld/17057] New: Production of DSOs using TLSDESC is utterly broken on i386
https://sourceware.org/bugzilla/show_bug.cgi?id=17057
Bug ID: 17057
Summary: Production of DSOs using TLSDESC is utterly broken on
i386
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: bugdal at aerifal dot cx
Attempting to compile/link the following program:
__thread int my_tls = 1;
int *my_tls_addr() { return my_tls; }
with the following gcc command line:
gcc -shared -mtls-dialect=gnu2 -fPIC -o foo.so foo.c
results in the following error message (details vary by version; I also tried
two different builds of 2.24, my own and Debian's):
/usr/bin/ld: BFD (GNU Binutils) 2.23.2 assertion fail elf32-i386.c:3922
The problem seems to be a miscomputation of the size of .got.plt needed for the
TLSDESC entries. Incidentally, if there are no PLT entries at all (this can be
achieved with the above program by -nostartfiles), the error goes away, but the
resulting DSO is unusable; it contains no DT_JMPREL in the DYNAMIC, so TLSDESC
relocations don't happen and naturally this results in a crash when the program
attempts to access the TLS.
Is this code completely untested? I can't seem to figure out how to produce any
usable/testable TLSDESC-using DSO.
--
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/12549] --as-needed should ignore weak references
http://sourceware.org/bugzilla/show_bug.cgi?id=12549 --- Comment #9 from Rich Felker bugdal at aerifal dot cx 2013-01-14 15:50:47 UTC --- I agree there's room for different opinions here, but I believe --as-needed should not include the library when all it does is resolve weak references. This matches the static-linking behavior and, perhaps more importantly, matches the purpose of making the reference weak: the fact that you don't need or want the actual implementation linked in unless you're also linking something else that depended on it being present. If it's not acceptable for --as-needed to have this behavior, then a different option to achieve the same thing is needed, and gcc needs to use that option with libgcc_s to prevent it from being linked unconditionally. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12549] --as-needed should ignore weak references
http://sourceware.org/bugzilla/show_bug.cgi?id=12549 --- Comment #11 from Rich Felker bugdal at aerifal dot cx 2013-01-14 17:22:10 UTC --- I agree that's possible as a workaround, but it seems to change the ABI for libgcc_s, which is probably not acceptable. And it's an extra layer of hackery needed to achieve the normal, sane result anybody would expect from --as-needed. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gas/14798] New: gas mips target generates badly typed symbols
http://sourceware.org/bugzilla/show_bug.cgi?id=14798 Bug #: 14798 Summary: gas mips target generates badly typed symbols Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassig...@sourceware.org ReportedBy: bug...@aerifal.cx Classification: Unclassified Symptom: failure of -Bsymbolic-functions to resolve libgcc references at link-time under certain circumstances. In particular, Sabotage Linux (https://github.com/rofl0r/sabotage) ends up building a broken musl libc.so on MIPS; its dynamic linker attempts to call libgcc functions before symbolic relocations have been processed. Cause: When gcc generates calls to libgcc functions for long division, etc., it adds a .globl directive to the output asm for those functions. This is entirely unnecessary, but should be harmless. However, the mips target for gas, upon seeing a .globl directive, adds OBJECT type to the undefined symbol reference unless there is a .type directive. On other targets, the type remains UNKNOWN. This in turn prevents the linker's -Bsymbolic-functions option from resolving the symbol reference at link-time. Assuming libgcc was compiled correctly with visibility, these functions have hidden visibility and thus they get resolved at link time anyway; however, if libgcc was built with --disable-shared, they don't. Really, this bug is an interaction of 3 separate issues in 3 pieces of software: 1. gcc: outputting useless .globl 2. gas mips target: treating .globl as implying type==OBJECT 3. libgcc: failure to use visibility when --disable-shared is specified I believe at least numbers 2 and 3, and maybe all three of them, should be fixed, but only 2 pertains to binutils. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 ld/13600] protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600 --- Comment #15 from Rich Felker bugdal at aerifal dot cx 2012-10-12 19:48:59 UTC --- Ping. Is anybody willing to look at this? This bug has been open 10 months now and fixing it is as simple as removing the offending code that's enforcing policy to protest a GCC bug. The relocations are semantically valid in ELF (even if the object code was not correctly generated from the C, which is GCC's responsibility), so binutils should allow them to be processed. Short of a good argument why the current behavior should be kept, I think the change should just be reverted. I can go lookup the commit where it changed and make a patch reverting it if anybody is willing to look at it (and I might do this anyway since I want this patch for local use, and people packaging musl-based distributions/base-systems are also interested in the patch which would allow us to safely use -fvisibility=protected to achieve significant size and performance gains). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 gas/14640] New: gas generates broken relocations for symbols with weak defs on microblaze
http://sourceware.org/bugzilla/show_bug.cgi?id=14640 Bug #: 14640 Summary: gas generates broken relocations for symbols with weak defs on microblaze Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassig...@sourceware.org ReportedBy: bug...@aerifal.cx Classification: Unclassified See this thread for a description of the issue and a patch, which is in Xilinx's fork of binutils but does not seem to have made it upstream: http://permalink.gmane.org/gmane.linux.uclinux.microblaze/11155 Basically, the issue is that gas thinks it can generate a 16-bit relative jump when there's a local definition of the function, even if that definition is weak and might be overridden by a strong definition that's outside of the 16-bit jump range. I'm in the process of porting musl libc to microblaze, and this issue is a show-stopper since we make heavy use of weak definitions. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 ld/14512] New: -z nodelete should be default for shared libraries
http://sourceware.org/bugzilla/show_bug.cgi?id=14512 Bug #: 14512 Summary: -z nodelete should be default for shared libraries Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sourceware.org ReportedBy: bug...@aerifal.cx Classification: Unclassified See glibc bug #14511: http://sourceware.org/bugzilla/show_bug.cgi?id=14511 If this can't/won't be fixed at the dynamic linker level, it should be fixed in binutils. Relying on every library, which might not even be intended for use with dlopen but might get loaded implicitly as a dependency of a dlopened library, is unsafe and unpractical; it leads to obscure crash bugs that may only arise for certain configurations of the underlying dependencies of a library. Since unloading a library is unsafe by default unless it was explicitly designed to be unloadable, -z nodelete should be the default option and -z delete should be needed to override it and specify that a .so being generated is intended for use as an unloadable plugin. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 ld/13600] protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600 Rich Felker bugdal at aerifal dot cx changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #14 from Rich Felker bugdal at aerifal dot cx 2012-05-28 15:27:40 UTC --- Binutils' 2.17 ld did not have this issue; it accepted the relocations and generated working binaries (albeit with the function pointer mismatch issue, which is a GCC issue, not binutils' responsibility). I think rejecting semantically valid ELF relocations solely for the purpose of preventing potentially-buggy code generated by GCC from getting linked is bad policy, and the behavior should be reverted. GCC can be fixed to lookup protected function pointers through the GOT, and perhaps even add a new visibility variant for the old behavior (which is highly desirable if you don't intend to pass function pointers in and out of the library). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 ld/14156] New: --sort-section=alignment trashes init/fini sections, and anything similar
http://sourceware.org/bugzilla/show_bug.cgi?id=14156 Bug #: 14156 Summary: --sort-section=alignment trashes init/fini sections, and anything similar Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sourceware.org ReportedBy: bug...@aerifal.cx Classification: Unclassified This bug came up from a user of musl libc (my project) building busybox (which has --sort-section=alignment in its makefile) on arm. He was experiencing crashes in busybox and nothing else, and upon examining the binary, found that the _init label (from crti.o) was getting reordered *after* the return code (from crtn.o), causing the call to _init to run off into other unrelated code. The problem has not been observed on any other systems (non-arm) with musl, nor with other libc implementations, but as far as I can tell, --sort-section=alignment is only working BY CHANCE on these systems due to the section sizes/alignments happening to keep the parts in the right order. I'm not sure what the right fix for this is, but I think the linker scripts should do something to ensure that sections which are pieced-together in a particular link order (init/fini and probably also ctors/dtors, and perhaps others) never get reordered. If that's not possible, then this option should be documented as dangerous/broken so that projects don't put it in their makefiles. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/14037] Bogus global symbol ABS redefinition when linking PIC app to eh_frame-stripped shared library
http://sourceware.org/bugzilla/show_bug.cgi?id=14037 Rich Felker bugdal at aerifal dot cx changed: What|Removed |Added Component|ld |binutils --- Comment #2 from Rich Felker bugdal at aerifal dot cx 2012-05-01 14:18:18 UTC --- Thanks for getting to the bottom of this so quickly. That makes it a strip bug, then. If strip is going to renumber the sections, it needs to fix the section numbers in the symbol table too. Or it could just leave the section numbers alone and replace the stripped sections with dummy zero-length sections with unobtrusive names to avoid the problem. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/14037] Bogus global symbol ABS redefinition when linking PIC app to eh_frame-stripped shared library
http://sourceware.org/bugzilla/show_bug.cgi?id=14037 --- Comment #3 from Rich Felker bugdal at aerifal dot cx 2012-05-01 18:37:16 UTC --- Another way of looking at the issue is that, if strip is going to break things like this, the default linker scripts should order the sections such that mandatory sections like text/data/bss all come before (in the section table, not necessarily in the file) optional sections like dwarf2 unwind tables rather than interspersed. --- Comment #4 from Rich Felker bugdal at aerifal dot cx 2012-05-01 18:37:16 UTC --- Another way of looking at the issue is that, if strip is going to break things like this, the default linker scripts should order the sections such that mandatory sections like text/data/bss all come before (in the section table, not necessarily in the file) optional sections like dwarf2 unwind tables rather than interspersed. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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 ld/14037] New: Bogus global symbol ABS redefinition when linking PIC app to eh_frame-stripped shared library
http://sourceware.org/bugzilla/show_bug.cgi?id=14037
Bug #: 14037
Summary: Bogus global symbol ABS redefinition when linking PIC
app to eh_frame-stripped shared library
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassig...@sourceware.org
ReportedBy: bug...@aerifal.cx
Classification: Unclassified
When the following 3 conditions are satisfied:
1. Main program is built with -fPIC.
2. Main program uses global variables from the shared library.
3. Shared library has been stripped with the command:
strip --strip-unneeded -R .eh_frame -R .eh_frame_hdr
the GNU binutils linker generates incorrect symbol definitions for the affected
global variable. Instead of generating a copy relocation (which it would do for
non-PIC main program) or leaving the symbol undefined in the main program so
that both the main program and shared library's GOT entries for the variable
get resolved to the original copy of the variable in the shared library, it
generates a nonsensical ABSOLUTE symbol definition in the main program whose
value is the library-load-address-relative address of the variable in the
shared library. For example, instead of (readelf output for the application):
5: 0 OBJECT GLOBAL DEFAULT UND global
we get:
5: 15f8 4 OBJECT GLOBAL DEFAULT ABS global
This in turn causes either the main app or the library to crash when trying to
access the global variable, since both GOT entries get resolved to this invalid
absolute address.
At least x86 and x86_64 are affected.
I encountered this issue when systems integrators using musl (my libc) were
trying to use the above strip command to debloat their libc file on disk. I
believe it's a valid optimization since musl does not use unwind tables
whatsoever, and in fact at first I suspected this was a bug on my side (in my
dynamic linker code perhaps), but I've created a minimal test case that
reproduces the issue with just binutils.
libfoo.c:
int global;
void setit(int x) { global = x; }
app.c:
void setit(int);
extern int global;
int main() { setit(42); return global; }
build:
gcc -fPIC -g libfoo.c -shared -o libfoo.so
strip -R .eh_frame -R .eh_frame_hdr libfoo.so
gcc -fPIC app.c -L. -lfoo
Compare results with and without the strip command to see the bug.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- 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/13891] Binutils is impossible to static link due to broken libtool behavior
http://sourceware.org/bugzilla/show_bug.cgi?id=13891 --- Comment #4 from Rich Felker bugdal at aerifal dot cx 2012-03-24 21:06:21 UTC --- Mike, a link to the workaround would be really helpful to anyone dealing with this bug or trying to evaluate whether it's worth fixing/working around in binutils. Personally I don't believe it's a bug in libtool is a valid excuse not to fix a major deficiency in a package that uses libtool as part of its build process. I could see that argument if libtool were an installed component of the user's system (analogously to applications should not be expected to work around glibc bugs) but since libtool is shipped with binutils as part of the build system, a buggy libtool in binutils at least largely binutils' responsibility. In fact if it were easy to do, I'd be quite happy with a --disable-libtool option that would just avoid using libtool at all for linking. With that said, I filed a libtool bug (#11064) and it's being taken seriously, so maybe it will be fixed upstream. In that case, having the bug report against binutils open will be a good reminder to upgrade to latest upstream libtool if/when it's fixed upstream. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12549] --as-needed should ignore weak references
http://sourceware.org/bugzilla/show_bug.cgi?id=12549 Rich Felker bugdal at aerifal dot cx changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #1 from Rich Felker bugdal at aerifal dot cx 2012-03-22 03:19:00 UTC --- Ping. I am the author of musl libc and this issue is seriously affecting myself and users of musl (on Linux); dynamic-linked programs intended to be extremely dependency-free (operate with only the musl loader/libc present on the target system) are getting an unwanted dependency on libgcc_s, and startup overhead is doubled even if it's present. The proposed patch seems correct, so if it is, could it be committed and included in the next binutils release? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/13891] New: Binutils is impossible to static link due to broken libtool behavior
http://sourceware.org/bugzilla/show_bug.cgi?id=13891 Bug #: 13891 Summary: Binutils is impossible to static link due to broken libtool behavior Product: binutils Version: unspecified Status: NEW Severity: critical Priority: P2 Component: binutils AssignedTo: unassig...@sourceware.org ReportedBy: bug...@aerifal.cx Classification: Unclassified I need static linked binutils, but libtool is intercepting and disabling any -static I add to CFLAGS or LDFLAGS. According to the libtool documentation, -all-static is required in place of -static to get the same behavior, but -all-static is not usable in CFLAGS or LDFLAGS because the binutils build process also invokes the compiler/linker without libtool on many occasions, and the unknown option -all-static will result in an error that stops the build. As far as I can tell, the only solution is to fix the broken libtool behavior. I'm filing a bug report with libtool as well, but as this seems to be the intended behavior (despite the impossibility of it working), I'm not optimistic about getting a fix. My fix is changing -all-static) on line 4562 of ltmain.sh to -all-static|-static) -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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
