On x86-solaris 10, we noticed that starting a program would sometimes cause the debugger to crash. For instance: % gdb a (gdb) break adainit Breakpoint 1 at 0x8051f03 (gdb) run Starting program: /[...]/a [Thread debugging using libthread_db enabled] zsh: 24398 segmentation fault (core dumped) /[...]/gdb a The exception occurs in dtrace_process_dof_probe, while trying to process each probe referenced by a DTRACE_DOF_SECT_TYPE_PROVIDER DOF section from /lib/libc.so.1. For reference, the ELF section in that shared library providing the DOF data has the following characteristics: Idx Name Size VMA LMA File off Algn 14 .SUNW_dof 0000109d 000b4398 000b4398 000b4398 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA The function dtrace_process_dof gets passed the contents of that ELF section, which allows it to determine the location of the table where all DOF sections are described. I dumped the contents of each DOF section as seen by GDB, and it seemed to be plausible, because the offset of each DOF section was pretty much equal to the sum of the offset and size of the previous DOF section. Also, the offset + sum of the last section corresponds to the size of the .SUNW_dof section. Things start to break down when processing one of the DOF sections that has a type of DTRACE_DOF_SECT_TYPE_PROVIDER. It gets the contents of this DOF section via: struct dtrace_dof_provider *provider = (struct dtrace_dof_provider *) DTRACE_DOF_PTR (dof, DOF_UINT (dof, section->dofs_offset)); Said more simply, the struct dtrace_dof_provider data is at section->dofs_offset of the entire DOF contents. Given that the contents of SECTION seemed to make sense, so far so good. However, what SECTION tells us is that our DOF provider section is 40 bytes long: (gdb) print *section $36 = {dofs_type = 15, dofs_align = 4, dofs_flags = 1, dofs_entsize = 0, dofs_offset = 3264, dofs_size = 40} ^^^^^^^^^^^^^^ But on the other hand: (gdb) p sizeof (struct dtrace_dof_provider) $54 = 44 In other words GDB expected a bigger DOF section and when we try to fetch the value of the last field of that DOF section (dofpv_prenoffs)... eoffsets_s = DTRACE_DOF_SECT (dof, DOF_UINT (dof, provider->dofpv_prenoffs)); ... we end up reading data that actually belongs to another DOF section, and therefore irrelevant. This in turn means that the value of eofftab gets incorrectly set, since it depends on eoffsets_s: eofftab = DTRACE_DOF_PTR (dof, DOF_UINT (dof, eoffsets_s->dofs_offset)); This invalid address quickly catches up to us when we pass it to dtrace_process_dof_probe shortly after, where we crash because we try to subscript it: Program received signal SIGSEGV, Segmentation fault. 0x08155bba in dtrace_process_dof_probe ([...]) at [...]/dtrace-probe.c:378 378 = ((uint32_t *) eofftab)[...]; This patch fixes the issue by detecting provider DOF sections that are smaller than expected, and discarding the DOF data. gdb/ChangeLog: * dtrace-probe.c (dtrace_process_dof): Ignore the objfile's DOF data if a DTRACE_DOF_SECT_TYPE_PROVIDER section is found to be smaller than expected. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
COPYING | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
COPYING3 | ||
COPYING3.LIB | ||
ChangeLog | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
README | ||
README-maintainer-mode | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
lt~obsolete.m4 | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
ylwrap |
README
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.