[Bug binutils/19659] [libopcodes] Segmentation fault on print_insn_i386
https://sourceware.org/bugzilla/show_bug.cgi?id=19659 --- Comment #2 from njholcomb at wi dot rr.com --- Created attachment 9200 --> https://sourceware.org/bugzilla/attachment.cgi?id=9200&action=edit File causes Abort by objdump This file contains bytes that objdump fails to decode using "objdump -d" because it aborts during decoding. -- 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/19660] [libopcodes] [x86] REP prefixes shown incorrectly
https://sourceware.org/bugzilla/show_bug.cgi?id=19660 --- Comment #2 from njholcomb at wi dot rr.com --- Created attachment 9201 --> https://sourceware.org/bugzilla/attachment.cgi?id=9201&action=edit Shows rep prefixes on non-string instructions -- 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/19661] [libopcodes] [x86] Lock prefixes are allowed even when they SIGILL
https://sourceware.org/bugzilla/show_bug.cgi?id=19661 --- Comment #2 from njholcomb at wi dot rr.com --- Created attachment 9202 --> https://sourceware.org/bugzilla/attachment.cgi?id=9202&action=edit File displays locking without a memory operand. objdump -d lock_no_mem.o lock_no_mem.o: file format elf64-x86-64 Disassembly of section .text: : 0: 55 push %rbp 1: 48 89 e5mov%rsp,%rbp 4: f0 b7 9flock mov $0x9f,%bh 7: 96 xchg %eax,%esi 8: 00 00 add%al,(%rax) a: 00 b8 00 00 00 00 add%bh,0x0(%rax) 10: 5d pop%rbp 11: c3 retq -- 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/19965] New: Copy relocation leads to change in read-only data
https://sourceware.org/bugzilla/show_bug.cgi?id=19965 Bug ID: 19965 Summary: Copy relocation leads to change in read-only data Product: binutils Version: 2.27 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: hjl.tools at gmail dot com Target Milestone: --- Target: x86 [hjl@gnu-6 relro-9]$ cat x.c int const p1[1] = { -1 }; [hjl@gnu-6 relro-9]$ cat foo.c #include extern int const p1[1]; void foo (void) { if (p1[0] != -1) abort (); } [hjl@gnu-6 relro-9]$ cat m.c #include extern void foo (void); extern int p1[1]; int main () { foo (); printf ("%d\n", p1[0]); p1[0] = 0; foo (); return 0; } [hjl@gnu-6 relro-9]$ make gcc -O2 -g -c -o m.o m.c gcc -O2 -g -fPIC -c -o x.o x.c gcc -O2 -g -fPIC -c -o foo.o foo.c ld -shared --gc-sections -z relro -o libx.so x.o foo.o gcc -o x -O2 -g m.o libx.so -Wl,-R,. ./x -1 Makefile:10: recipe for target 'all' failed make: *** [all] Aborted [hjl@gnu-6 relro-9]$ -- 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/19660] [libopcodes] [x86] REP prefixes shown incorrectly
https://sourceware.org/bugzilla/show_bug.cgi?id=19660 --- Comment #3 from H.J. Lu --- (In reply to njholcomb from comment #2) > Created attachment 9201 [details] > Shows rep prefixes on non-string instructions I got : 0: 55 push %rbp 1: 48 89 e5mov%rsp,%rbp 4: f3 e0 58repz loopne 5f 7: f2 00 00repnz add %al,(%rax) a: 00 b8 00 00 00 00 add%bh,0x0(%rax) 10: 5d pop%rbp 11: c3 retq repz is nop before loopne. repnz is UD before add: Program received signal SIGSEGV, Segmentation fault. 0x0040048f in main () (gdb) disass Dump of assembler code for function main: 0x00400488 <+0>: push %rbp 0x00400489 <+1>: mov%rsp,%rbp 0x0040048c <+4>: repz loopne 0x4004e7 <__libc_csu_init+71> => 0x0040048f <+7>: repnz add %al,(%rax) 0x00400492 <+10>:add%bh,0x0(%rax) 0x00400498 <+16>:pop%rbp 0x00400499 <+17>:retq End of assembler dump. (gdb) Disassembler output looks OK to me. -- 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/19659] [libopcodes] Segmentation fault on print_insn_i386
https://sourceware.org/bugzilla/show_bug.cgi?id=19659 H.J. Lu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from H.J. Lu --- ./objdump -dwr x.o x.o: file format elf64-x86-64 Disassembly of section .text: : 0: 55 push %rbp 1: 48 89 e5mov%rsp,%rbp 4: 8f (bad) 5: eb 5c jmp63 7: ec in (%dx),%al 8: 00 00 add%al,(%rax) a: 00 b8 00 00 00 00 add%bh,0x0(%rax) 10: 5d pop%rbp 11: c3 retq [hjl@gnu-6 pr19659]$ -- 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/19661] [libopcodes] [x86] Lock prefixes are allowed even when they SIGILL
https://sourceware.org/bugzilla/show_bug.cgi?id=19661 H.J. Lu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from H.J. Lu --- (In reply to njholcomb from comment #2) > Created attachment 9202 [details] > File displays locking without a memory operand. > > objdump -d lock_no_mem.o > > lock_no_mem.o: file format elf64-x86-64 > > > Disassembly of section .text: > > : >0: 55 push %rbp >1: 48 89 e5mov%rsp,%rbp >4: f0 b7 9flock mov $0x9f,%bh >7: 96 xchg %eax,%esi >8: 00 00 add%al,(%rax) >a: 00 b8 00 00 00 00 add%bh,0x0(%rax) > 10: 5d pop%rbp > 11: c3 retq It looks OK to me. You get UD because LOCK prefix is used on non-memory operand: (gdb) disass Dump of assembler code for function main: 0x00400488 <+0>: push %rbp 0x00400489 <+1>: mov%rsp,%rbp => 0x0040048c <+4>: lock mov $0x9f,%bh 0x0040048f <+7>: xchg %eax,%esi 0x00400490 <+8>: add%al,(%rax) 0x00400492 <+10>:add%bh,0x0(%rax) 0x00400498 <+16>:pop%rbp 0x00400499 <+17>:retq End of assembler dump. (gdb) -- 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/19965] Copy relocation leads to change in read-only data
https://sourceware.org/bugzilla/show_bug.cgi?id=19965 --- Comment #1 from Andreas Schwab --- And how is that a bug? The program invokes undefined behavior. -- 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/19965] Copy relocation leads to change in read-only data
https://sourceware.org/bugzilla/show_bug.cgi?id=19965 --- Comment #2 from H.J. Lu --- (In reply to Andreas Schwab from comment #1) > And how is that a bug? The program invokes undefined behavior. Linker should generate copy relocation against read-only symbol in .data.rel.ro section, instead of .bss section, so that the copy of read-only symbol is also read-only after relocation at run-time. -- 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/19722] [libopcodes] [Aarch64] Undefined SIMD instruction not marked undefined
https://sourceware.org/bugzilla/show_bug.cgi?id=19722 --- Comment #4 from njholcomb at wi dot rr.com --- This may not be a valid output from the libopcodes disassembler, but there are a lot of tools out there, and not all of them may produce expected instructions. People can also edit binaries themselves, placing arbitrary bytes. Furthermore, this instruction executes without any signal on at least one chip, where it both loads a word into x6 and applies the post-fix after loading in the word, a completely unspecified (though maybe predictable) behavior. Identifying invalid instructions like this is essential to debugging code that behaves unexpectedly. -- 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/19891] arm: The order of IFUNC (R_ARM_IRELATIVE and R_ARM_JUMP_SLOT) relocations is incorrect
https://sourceware.org/bugzilla/show_bug.cgi?id=19891 Han Shen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Han Shen --- Discussed with reporter. This is not caused by the order of R_ARM_IRELATIVE. I'll mark this as WONTFIX. Thanks, Han -- 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/19965] Copy relocation leads to change in read-only data
https://sourceware.org/bugzilla/show_bug.cgi?id=19965 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from Alan Modra --- Here's a testcase that I think does not invoke any undefined behaviour, and shows various inconsistencies with protected variables and copy relocs. Depending on the version of gcc (and glibc!) you may see &x != x or no segfault. Compile protmain with -fPIC to see correct behaviour. cat > prot.h <<\EOF extern void *x; extern void aprint (void); extern void boom (void); EOF cat > prota.c <<\EOF #include "prot.h" void __attribute__ ((visibility ("protected"), section(".data.rel.ro"))) *x = &x; void aprint (void) { __builtin_printf ("A: &x = %p, x = %p\n", &x, x); } EOF cat > protb.c <<\EOF #include "prot.h" void boom (void) { x = 0; } EOF cat > protmain.c <<\EOF #include "prot.h" int main (void) { __builtin_printf ("main: &x = %p, x = %p\n", &x, x); aprint (); boom (); return 0; } EOF gcc -O2 -fPIC -shared -o liba.so prota.c protb.c -Wl,-z,relro gcc -O2 -o protmain protmain.c -L. -la -Wl,-rpath,. ./protmain -- 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/19965] Copy relocation leads to change in read-only data
https://sourceware.org/bugzilla/show_bug.cgi?id=19965 --- Comment #4 from Alan Modra --- BTW, the testcase in comment #3 (and yours too!) show just how difficult it is to fix this problem. When the main program is *not* relro you don't have anywhere to put the new .dynbss.ro or whatever you want to call the internal linker generated section for read-only .dynbss variables. You don't have a .data.rel.ro in the main executable and can't tack them on to .rodata, because then ld.so will segfault when applying the copy 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