[Bug gprof/22549] Gprof prints an empty profile including no data
https://sourceware.org/bugzilla/show_bug.cgi?id=22549 --- Comment #3 from Andreas Schwab --- *** Bug 22548 has been marked as a duplicate of this bug. *** -- 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 gprof/22548] Sorry, I posted it twice due to internet problems.
https://sourceware.org/bugzilla/show_bug.cgi?id=22548 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andreas Schwab --- . *** This bug has been marked as a duplicate of bug 22549 *** -- 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/22532] objdump doesn't disassemble dwarf opcodes for DW_AT_byte_size
https://sourceware.org/bugzilla/show_bug.cgi?id=22532 Nick Clifton changed: What|Removed |Added Status|NEW |ASSIGNED CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Tom, > I have a file that uses a location expression in DW_AT_byte_size. Could you upload a copy of this file please ? Cheers Nick -- 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/22493] push {sp} fails on mcpu=cortex-a7
https://sourceware.org/bugzilla/show_bug.cgi?id=22493
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #1 from Nick Clifton ---
Hi Reporter,
Please could you give me more details of how you generated this bug ?
I tried the following test:
% cat pr22493.s
.text
push {sp}
% arm-none-eabi-as -march=armv7-a pr22493.s -o pr22493.o
% arm-none-eabi-objdump -d pr22493.o
Disassembly of section .text:
<.text>:
0: e52dd004push{sp}; (str sp, [sp, #-4]!)
So, the correct STMDB encoding is being used, although the disassembler does
have an incorrect comment describing the instruction.
Cheers
Nick
--
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/20642] internal error in get_section_contents, at icf.cc:467 with --icf=safe
https://sourceware.org/bugzilla/show_bug.cgi?id=20642 --- Comment #7 from Guillaume Morin --- fwiw I can't reproduce this anymore with 2.29.1 (using clang 5.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 binutils/22532] objdump doesn't disassemble dwarf opcodes for DW_AT_byte_size
https://sourceware.org/bugzilla/show_bug.cgi?id=22532 --- Comment #2 from Tom Tromey --- > Could you upload a copy of this file please ? Sure. FWIW it comes from an Ada test case that Joel Brobecker sent 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/22532] objdump doesn't disassemble dwarf opcodes for DW_AT_byte_size
https://sourceware.org/bugzilla/show_bug.cgi?id=22532 --- Comment #3 from Tom Tromey --- Created attachment 10666 --> https://sourceware.org/bugzilla/attachment.cgi?id=10666&action=edit 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/22493] push {sp} fails on mcpu=cortex-a7
https://sourceware.org/bugzilla/show_bug.cgi?id=22493
--- Comment #2 from bugzi...@fritzler-avr.de ---
Hello,
of course I will give you more details.
At first "y52d" ist not stm it is str ;)
stm is "y92d".
Therefore I repeated your test but with two more instructions.
Now you can see the difference.
$ cat pr22493.s
.text
label:
stmfd sp!, {sp}
push {sp}
str sp, [sp, #-4]! //this line(5) is the warning!
$ arm-none-eabi-as -march=armv7-a pr22493.s -o pr22493.o
pr22493.s: Assembler messages:
pr22493.s:5: Warning: source register same as write-back base
$ ./arm-none-eabi-objdump -d pr22493.o
pr22493.o: file format elf32-littlearm
Disassembly of section .text:
:
0: e92d2000stmfd sp!, {sp}
4: e52dd004push{sp}; (str sp, [sp, #-4]!)
8: e52dd004push{sp}; (str sp, [sp, #-4]!)
$ arm-none-eabi-as -v
GNU assembler version 2.29.1 (arm-none-eabi) using BFD version (GNU Binutils)
2.29.1
$ arm-none-eabi-objdump -v
GNU objdump (GNU Binutils) 2.29.1
Now the details HOW the bug was generated:
In our course the students have to write some exceptionhandlers and print all
registers if an exception happens.
Therefore a student used push {sp} and nothing worked because his undef handler
wasnt finished and the -as didnt throw a warning.
Greetings
Martin
--
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/22552] New: readelf - heap buffer overflow in load_debug_section()
https://sourceware.org/bugzilla/show_bug.cgi?id=22552 Bug ID: 22552 Summary: readelf - heap buffer overflow in load_debug_section() Product: binutils Version: 2.29 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: jonghyk.song at gmail dot com Target Milestone: --- Created attachment 10667 --> https://sourceware.org/bugzilla/attachment.cgi?id=10667&action=edit crafted_elf_file Dear all, I found this bug with AFL fuzzer(2.52b). My fuzzing environments are as follows: 1. $ uname -an Linux jhsong-ubuntu 4.10.0-40-generic #44~16.04.1-Ubuntu SMP Thu Nov 9 15:37:44 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux 2. git commit: 8fbc617a46b015098876a7515c3a7ad6d1682876 3. build CC="afl-gcc" CXX="afl-g++" CFLAGS="-fsanitize=address -ggdb -lpthread" CXXFLAGS="-fsanitize=address -ggdb" LDFLAGS='-ldl' LIBS="-ldl" ./configure To reproduce: 1. download the attached file 2. ./readelf -a [attached file] Thank you. ==1204==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6120c3e0 at pc 0x004a59ed bp 0x7fffce243f00 sp 0x7fffce243ef0 READ of size 8 at 0x6120c3e0 thread T0 #0 0x4a59ec in load_debug_section /home/jhsong/fuzzing/binutils/binutils-gdb/binutils/readelf.c:13588 #1 0x538a91 in load_separate_debug_file /home/jhsong/fuzzing/binutils/binutils-gdb/binutils/dwarf.c:9839 #2 0x49c347 in process_object /home/jhsong/fuzzing/binutils/binutils-gdb/binutils/readelf.c:18580 #3 0x404c5c in process_file /home/jhsong/fuzzing/binutils/binutils-gdb/binutils/readelf.c:19004 #4 0x404c5c in main /home/jhsong/fuzzing/binutils/binutils-gdb/binutils/readelf.c:19063 #5 0x7f885963b82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #6 0x405988 in _start (/home/jhsong/fuzzing/binutils/binutils-gdb/binutils/readelf+0x405988) AddressSanitizer can not describe address in more detail (wild memory access suspected). SUMMARY: AddressSanitizer: heap-buffer-overflow /home/jhsong/fuzzing/binutils/binutils-gdb/binutils/readelf.c:13588 load_debug_section Shadow bytes around the buggy address: 0x0c247fff9820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fff9830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fff9840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fff9850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fff9860: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c247fff9870: fa fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa 0x0c247fff9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fff9890: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fff98a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fff98b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c247fff98c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe ==1204==ABORTING -- 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/22553] New: .largecomm, .lbss, .ldata, and .lrodata are still not documented after many, many years
https://sourceware.org/bugzilla/show_bug.cgi?id=22553 Bug ID: 22553 Summary: .largecomm, .lbss, .ldata, and .lrodata are still not documented after many, many years Product: binutils Version: 2.29 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: john at buu dot ac.th Target Milestone: --- .largecomm is not documented, but gcc emits it for some >64K objects in medium model code on x86-64. .ldata, .lbss, and .lrodata are also undocumented, but emitted by gcc for the medium model in some cases. The texinfo manual outright fails to document the required directives for medium model x86-64 (AMD64/INTEL64) code. The man page hints that the texinfo is the cannonical documentation which should be used. I'm using GNU info in an xterm with the search operator / and cannot find any of the 4 directives explained. I also tried the index search operator i and tried all 4 directives (both with and without the leading dot) and got absolutely nothing. In desperation, I decompressed the as.info.gz file and used grep, but still got no matches for the directives either with or without the leading dot. The rather ancient email from 2011 archived here: https://cygwin.com/ml/binutils/2011-05/msg00152.html proves that .largecomm is supposed to be supported, but it is wrong to have something supported but not documented. I verified gcc-7.2.0 will generate .lbss, .ldata, and .lrodata in some cases for medium model, and it also will generate .largecomm in some cases. Testing was on an Ubuntu 17.10 system if it matters. I am actually using binutils 2.29.1, but in bugzilla there is no 'Version:' tag for that, so I chose 2.29 as the closest released version. I'm having a hard time getting some compiler authors to generate medium model code using these directives since they rightly state these directives are undocumented and thus not really supported whole-heartedly by the upstream gas developers. The people I correspond with said they don't want to emit code that depends on undocumented, unsupported, or poorly-supported features of the GNU gas assembler, and that maybe these things are 'gcc only'. But I think if they don't use at least the 3 .lbss, .ldata, and .lrodata sections, the code they generate might link and run, but it violates at least the spirit of the ABI. If this stuff was documented, at least I could point to that documentation and they could read it and realize it is actually supported and necessary to use for correct medium-model AMD64 code generation. -- 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/22554] New: .largecomm, .lbss, .ldata, and .lrodata are still not documented after many, many years
https://sourceware.org/bugzilla/show_bug.cgi?id=22554 Bug ID: 22554 Summary: .largecomm, .lbss, .ldata, and .lrodata are still not documented after many, many years Product: binutils Version: 2.29 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: john at buu dot ac.th Target Milestone: --- .largecomm is not documented, but gcc emits it for some >64K objects in medium model code on x86-64. .ldata, .lbss, and .lrodata are also undocumented, but emitted by gcc for the medium model in some cases. The texinfo manual outright fails to document the required directives for medium model x86-64 (AMD64/INTEL64) code. The man page hints that the texinfo is the cannonical documentation which should be used. I'm using GNU info in an xterm with the search operator / and cannot find any of the 4 directives explained. I also tried the index search operator i and tried all 4 directives (both with and without the leading dot) and got absolutely nothing. In desperation, I decompressed the as.info.gz file and used grep, but still got no matches for the directives either with or without the leading dot. The rather ancient email from 2011 archived here: https://cygwin.com/ml/binutils/2011-05/msg00152.html proves that .largecomm is supposed to be supported, but it is wrong to have something supported but not documented. I verified gcc-7.2.0 will generate .lbss, .ldata, and .lrodata in some cases for medium model, and it also will generate .largecomm in some cases. Testing was on an Ubuntu 17.10 system if it matters. I am actually using binutils 2.29.1, but in bugzilla there is no 'Version:' tag for that, so I chose 2.29 as the closest released version. I'm having a hard time getting some compiler authors to generate medium model code using these directives since they rightly state these directives are undocumented and thus not really supported whole-heartedly by the upstream gas developers. The people I correspond with said they don't want to emit code that depends on undocumented, unsupported, or poorly-supported features of the GNU gas assembler, and that maybe these things are 'gcc only'. But I think if they don't use at least the 3 .lbss, .ldata, and .lrodata sections, the code they generate might link and run, but it violates at least the spirit of the ABI. If this stuff was documented, at least I could point to that documentation and they could read it and realize it is actually supported and necessary to use for correct medium-model AMD64 code generation. -- 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/22552] readelf - heap buffer overflow in load_debug_section()
https://sourceware.org/bugzilla/show_bug.cgi?id=22552 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-12-06 Assignee|unassigned at sourceware dot org |amodra at gmail dot com Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22552] readelf - heap buffer overflow in load_debug_section()
https://sourceware.org/bugzilla/show_bug.cgi?id=22552 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9c1ce1085070f42718e341d89a28881edd96161f commit 9c1ce1085070f42718e341d89a28881edd96161f Author: Alan Modra Date: Wed Dec 6 17:32:48 2017 +1030 PR22552, readelf heap buffer overflow in load_debug_section PR 22552 * readelf.c (process_file_header): Don't assume XINDEX case value for e_shstrndx is within bounds. (load_debug_section): Sanity test e_shstrndx before attempting to read .shstrtab. Wrap long lines. -- 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
