[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Segfault in objdump?
From: |
Barret Rhoden |
Subject: |
Segfault in objdump? |
Date: |
Sat, 1 Jun 2013 10:21:16 -0700 |
Hi -
objdump 2.23.1 seems to segfault when called with -S on a large binary,
when called from a Makefile that modifies one of its 'include' files.
It does not fail on a simple hello-world binary. It does not fail if
we do not have -S (-d works). It does not fail if the Makefile doesn't
modify a file that it includes.
Here's a test makefile:
-----------------------------
# Force olderfile to be newer than newerfile,
# to trigger the newerfile: target.
dummy-1 := $(shell touch olderfile)
FILE ?= akaros-kernel
# This maketarget fails with the kernel binary
source:
objdump -S $(FILE) > $(FILE).asm
# This one succeeds
dump:
objdump -d $(FILE) > $(FILE).asm
clean:
rm -f *.asm
newerfile: olderfile
@touch $@
include newerfile
-----------------------------
Here's the failure message:
/bin/sh: line 1: 27981 Segmentation fault objdump -S akaros-kernel
> akaros-kernel.asm
make: *** [source] Error 139
Is this something triggered by the Makefile? Or is -S having issues
with files being updated concurrently? Or something particular about
the binary?
The pattern of including files that get modified is the same as is done
with Linux's kbuild/kconfig with auto.conf and .config. You can
replicate this bug by putting the objdump targets on the same binary in
Linux's makefile and running $ touch .config ; make source.
I uploaded the test programs and large binary here: (7MB compressed)
http://www.eecs.berkeley.edu/~brho/downloads/binutils-debug.tbz
Thanks,
Barret
- Segfault in objdump?,
Barret Rhoden <=
- Re: Segfault in objdump?, Alan Modra, 2013/06/02
- Re: Segfault in objdump?, Barret Rhoden, 2013/06/02
- Re: Segfault in objdump?, Alan Modra, 2013/06/02
- Re: Segfault in objdump?, Barret Rhoden, 2013/06/02
- Re: Segfault in objdump?, Alan Modra, 2013/06/02
- Re: Segfault in objdump?, Alan Modra, 2013/06/03
- Re: Segfault in objdump?, Barret Rhoden, 2013/06/03