[Bug binutils/16682] New: segmentation fault in bfd/elf.c
https://sourceware.org/bugzilla/show_bug.cgi?id=16682 Bug ID: 16682 Summary: segmentation fault in bfd/elf.c Product: binutils Version: 2.24 Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: antiagainst at gmail dot com Created attachment 7460 --> https://sourceware.org/bugzilla/attachment.cgi?id=7460&action=edit 32-bit ELF containing a SHT_GNU_verdef section The following is based on objdump 2.24. I built it on Ubuntu 13.10 with GCC 4.8.1. There is a segmentation fault problem when processing SHT_GNU_verdef sections. A small problem is attached to help reproduce the bug. The command is `objdump -p A`. The program will exit with segmentation fault. For the attached program, I tried to analyze it using gdb, but I cannot figure it out clearly. What I currently have is the following: gdb output: Program received signal SIGSEGV, Segmentation fault. 0x2af35f90 in _IO_vfprintf_internal (s=, format=, ap=ap@entry=0x7fffcfa8) at vfprintf.c:1655 1655vfprintf.c: No such file or directory. #0 0x2af35f90 in _IO_vfprintf_internal (s=, format=, ap=ap@entry=0x7fffcfa8) at vfprintf.c:1655 #1 0x2af3cf57 in __fprintf (stream=, format=) at fprintf.c:32 #2 0x004e5f06 in _bfd_elf_print_private_bfd_data (abfd=0x96a1c0, farg=0x2b2ab280 <_IO_2_1_stdout_>) at ../../bfd/elf.c:1351 #3 0x0040b604 in dump_bfd_private_header (abfd=0x96a1c0) at ../../binutils/objdump.c:2643 #4 0x0040d96c in dump_bfd (abfd=0x96a1c0) at ../../binutils/objdump.c:3214 #5 0x0040e0fd in display_object_bfd (abfd=0x96a1c0) at ../../binutils/objdump.c:3313 #6 0x0040e563 in display_any_bfd (file=0x96a1c0, level=0) at ../../binutils/objdump.c:3387 #7 0x0040e656 in display_file (filename=0x7fffd90d "objdump-3-244-A", target=0x0) at ../../binutils/objdump.c:3408 #8 0x0040f635 in main (argc=3, argv=0x7fffd3a8) at ../../binutils/objdump.c:3690 In _bfd_elf_slurp_version_tables() of bfd/elf.c, starting from line 7253, contents_end_def and is smaller than contents, and contents_end_aux is the same as contents. This seems not correct. Besides, It seems after `abfd->tdata.elf_obj_data->verdef` gets its memory from bfd_zalloc2() at line 7286, `verdef[0].vd_nodename` is just `0x34 ` and never get changed until hitting fprintf() at line 1351 which tries to access it and segfault. I don't know whether this is because the memory allocated for `->verdef` is not enough (`maxidx` passed in to bfd_zalloc2() is 0) because the logic behind the macros at line 87 of include/objalloc.h is not clear to me. I would greatly appreciate it if you guys can also explain the reason while fixing the problem. Thanks! -- 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/16685] New: Read-only data sections should not be executable
https://sourceware.org/bugzilla/show_bug.cgi?id=16685 Bug ID: 16685 Summary: Read-only data sections should not be executable Product: binutils Version: unspecified Status: NEW Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: zackw at panix dot com The usual ELF linker scripts lump a variety of "read-only data" sections into the same program segment as the actual code ("text"), thus allowing data in those sections to be executed, if by chance the PC is misdirected there. As a somewhat silly demonstration, compile and run const char main[] = "1\300\303"; on an x86/elf system, and it will execute successfully! (Remove the 'const' and it will crash, because modifiable data is in a different segment which does not have execute permission.) In principle, fixing this is as simple as defining an additional LOAD segment in the linker script, and moving all of the sections that contain read-only data but not machine code there. The details might get a little hairy. -- 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/16682] segmentation fault in bfd/elf.c
https://sourceware.org/bugzilla/show_bug.cgi?id=16682 Alan Modra changed: What|Removed |Added Priority|P2 |P3 CC||amodra at gmail dot com Severity|normal |minor --- Comment #1 from Alan Modra --- Reducing importance. Looks to be a randomly generated binary, ie. headers with random garbage. -- 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/16686] New: PowerPC build of binutils fails due to coffcode.h
https://sourceware.org/bugzilla/show_bug.cgi?id=16686 Bug ID: 16686 Summary: PowerPC build of binutils fails due to coffcode.h Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: kallisti5 at unixzen dot com Created attachment 7461 --> https://sourceware.org/bugzilla/attachment.cgi?id=7461&action=edit patch to add stdint.h coffcode.h uses intptr_t without including stdint.h. This results in a build failure on recent PowerPC / GCC. (not sure why it didn't fail before, maybe gcc 4.8 is more strict?) -- 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/16686] PowerPC build of binutils fails due to coffcode.h
https://sourceware.org/bugzilla/show_bug.cgi?id=16686 --- Comment #1 from cvs-commit at gcc dot gnu.org --- This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via 3c865fca872570ba07c4a16fb262e0487b66bf0a (commit) from c1966e261a3c0e0a32639d464a5ebee83aa31144 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3c865fca872570ba07c4a16fb262e0487b66bf0a commit 3c865fca872570ba07c4a16fb262e0487b66bf0a Author: Alan Modra Date: Tue Mar 11 15:42:46 2014 +1030 intptr_t type definition needed coffcode.h uses an intptr_t cast inside an #ifdef RS6000COFF_C, so ensure that intptr_t is defined. We don't see this when cross-compiling from linux due to intptr_t being provided by unistd.h. PR 16686 * coff-rs6000.c: Include stdint.h. * coff64-rs6000.c: Likewise. --- Summary of changes: bfd/ChangeLog |6 ++ bfd/coff-rs6000.c |1 + bfd/coff64-rs6000.c |1 + 3 files changed, 8 insertions(+), 0 deletions(-) -- 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/16686] PowerPC build of binutils fails due to coffcode.h
https://sourceware.org/bugzilla/show_bug.cgi?id=16686 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED CC||amodra at gmail dot com Resolution|--- |FIXED --- Comment #2 from Alan Modra --- In future, please specify host and target when reporting bugs. I can guess that your target is rs6000 and host is not linux, because on linux I get intptr_t defined in unistd.h due to sbrk using an intptr_t argument. -- 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