Issue 31168 in oss-fuzz: binutils:fuzz_readelf: Timeout in fuzz_readelf
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #6 on issue 31168 by sheriffbot: binutils:fuzz_readelf: Timeout in fuzz_readelf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31168#c6 This bug has exceeded our disclosure deadline. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599 --- Comment #13 from dave.anglin at bell dot net --- On 2021-05-21 12:15 p.m., jvb at cyberscience dot com wrote: > I will test movl, break.x and nop.x. They have operands of 64, 62 and 62 bits, > with very different layout to brl, so PCREL60 won't apply. One potential > candidate is PCREL64 against a movl, I'll see if I can generate and test this > and anything else I can find (it will be next week though). Could you test the testcase with HP assembler and compare with GAS using objdump -r? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/27897] gold generates wrong TLS relocation for IE access model
https://sourceware.org/bugzilla/show_bug.cgi?id=27897 --- Comment #1 from Luo Bo --- > Further investigation suggests that gold is somehow confused by > `_ZL6value1@tlsgd(%rip)` generated by GCC (for accessing `value`). Oops, sorry, I meant "for accessing `value1`". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/27897] New: gold generates wrong TLS relocation for IE access model
https://sourceware.org/bugzilla/show_bug.cgi?id=27897
Bug ID: 27897
Summary: gold generates wrong TLS relocation for IE access
model
Product: binutils
Version: 2.36
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: luobodi at hotmail dot com
CC: ian at airs dot com
Target Milestone: ---
Test code (I'm using GCC 11.1 with binutils 2.36):
```cpp
static thread_local int value1
__attribute__((tls_model("global-dynamic"))) = 10;
int Get1() { return value1; }
static thread_local int value2
__attribute__((tls_model("initial-exec")));
int Get2() { return value2; }
```
When compiled with `g++ something.cc -std=c++2a -fPIC -shared -o something.so
-fuse-ld=gold -save-temps`, `readelf -a --wide something.so |grep value2` shows
a relocation of type `R_X86_64_DTPMOD64` for `value2`.
Since `value2` is annotated as `initial-exec`, I would expected an
`R_X86_64_TPOFF64` be emitted instead.
Further investigation suggests that gold is somehow confused by
`_ZL6value1@tlsgd(%rip)` generated by GCC (for accessing `value`).
If I either:
- Remove `value1` from the source (there won't be `value1@tlsgd` then), or
- Specify `initial-exec` on `value1` (hence avoid `value1@tlsgd`), or
- Manually replace `tlsgd` with `tlsld` in `something.so-something.s` (produced
by `-save-temps`)
gold can emit an `R_X86_64_TPOFF64` for `value2` correctly.
`something.so-something.s` is attached below if it helps:
```asm
.file "something.cc"
.text
.section.tdata,"awT",@progbits
.align 4
.type _ZL6value1, @object
.size _ZL6value1, 4
_ZL6value1:
.long 10
.text
.globl _Z4Get1v
.type _Z4Get1v, @function
_Z4Get1v:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
data16 leaq_ZL6value1@tlsgd(%rip), %rdi
.value 0x
rex64
call__tls_get_addr@PLT
movl(%rax), %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size _Z4Get1v, .-_Z4Get1v
.section.tbss,"awT",@nobits
.align 4
.type _ZL6value2, @object
.size _ZL6value2, 4
_ZL6value2:
.zero 4
.text
.globl _Z4Get2v
.type _Z4Get2v, @function
_Z4Get2v:
.LFB1:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movq_ZL6value2@gottpoff(%rip), %rax
movl%fs:(%rax), %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1:
.size _Z4Get2v, .-_Z4Get2v
.ident "GCC: (GNU) 11.1.0"
.section.note.GNU-stack,"",@progbits
```
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599 --- Comment #12 from dave.anglin at bell dot net --- On 2021-05-21 12:15 p.m., jvb at cyberscience dot com wrote: > Specifying a slot value for a 2 slot instruction + immediate is clearly > ambiguous without further clarification. HP interprets it one way, other > platforms differently. I'd say neither is really right or wrong, it's > unfortunate that there are differences but we're stuck with it now. I agree. On page 3:294 of the architecture, I see that the .mlx template has the X unit instruction in slot 2. However, the IP value used with the immediate is the address of the bundle which contains the current executing instruction (page 1:27). So, the immediate value doesn't depend on slot. But I still think it makes sense to apply the relocation to the X unit instruction as it determines the X3, X4 immediate encoding. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599 --- Comment #11 from John Buddery --- I will test movl, break.x and nop.x. They have operands of 64, 62 and 62 bits, with very different layout to brl, so PCREL60 won't apply. One potential candidate is PCREL64 against a movl, I'll see if I can generate and test this and anything else I can find (it will be next week though). I see your point about the test - we could be checking for PCREL relocations for an L+X instruction class, rather than PCREL60 relocations. Although the P calculation is bundle based, the r_offset uses 2 bits for the slot, as stated above. It's the r_offset we're adjusting. The info I've been using is on pages 4-6 to 4-8 of the relocation reference you provided a link for. Specifying a slot value for a 2 slot instruction + immediate is clearly ambiguous without further clarification. HP interprets it one way, other platforms differently. I'd say neither is really right or wrong, it's unfortunate that there are differences but we're stuck with it now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599 --- Comment #10 from dave.anglin at bell dot net --- I think the test is wrong. The brl instruction is comprised of two instruction slots (L+X). For brl, the imm39 field and a 2-bit Ignored field occupy the L instruction slot. The actual branch instruction is in the second (X) slot. The PCREL relocation needs to be computed relative to this slot, so it makes sense that the relocation would be specified relative to this slot. The psABI says "P" is the address of the bundle containing the instruction. However, the brl instruction was introduced in itanium2 and it uses two instruction slots. I think the other L+X instructions (movl, break.x and nop.x) need checking with the PCREL60B and other relocations involving instruction placement. John, could you look at this? This is failing test: .text .proc foo# foo: .mlx mov r25 = r0 brl.call.sptk.many b0 = bar# .endp foo# I agree comment in the change needs an update. Even if the HP linker is wrong, it's important that we get the brl instruction working on HPUX so that current versions of gcc will build. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27837] Consider allowing mix of -r / --relax by ignoring --relax.
https://sourceware.org/bugzilla/show_bug.cgi?id=27837 --- Comment #3 from Nick Clifton --- Unfortunately I have discovered a problem with the patch: The PowerPC target does allow -r and --relax to be combined. So it is not correct to just globally disable the combination. (There may be other architectures that also allow it, but the PowerPC is the only that has tests in the linker testsuite to make sure that it works). So now I am wondering if the linker is the correct place to resolve this problem. If a build system is triggering error messages from the linker, then shouldn't that system be corrected ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25599] gas generates invalid PCREL60B relocation offset with brl.call
https://sourceware.org/bugzilla/show_bug.cgi?id=25599 --- Comment #9 from John Buddery --- Thanks very much for the analysis - I agree, this is about slot numbers not offsets and the comment is inaccurate. I too found the HP behaviour odd, when considering the instruction as using slots 1 and 2. Possibly the reasoning is that the actual instruction really occupies slot 2, with slot 1 containing 39 bits of the immediate. So, HP could argue that the instruction slot is 2, even though the relocation starts at slot 1. In any case, the HP tool chain generates the relocation that way. For this reason, HP would effectively be unable to make a linker change without breaking the existing library codebase. It's also vanishingly unlikely they will make further changes as the OS is end of life in 2025. The binutils linker does not support HP, otherwise of course the preferred solution would be to use that So, the only possibility to get a working gas is compatibility with the HP linker, and I would ask you to please consider keeping this change - with an improved comment to say this is a workaround for the HP linker using slot 2 as the target. As far as I can tell, it is only the immediate-60 relocation that has problems on HP. I have not seen issues with any of the immediate-64 relocations, at least not in any of the instructions gcc generates. -- You are receiving this mail because: You are on the CC list for the bug.
