[PATCH] Note that .rela.debug* sections are debuginfo sections.
by Nick Alcock
Without this fix, strip -g misbehaves when stripping object files
and other ELF objects containing debuginfo relocation sections,
preserving all debuginfo sections in the output file because the
.rela.debug* sections reference them.
Signed-off-by: Nick Alcock <nick.alcock(a)oracle.com>
---
The selection of sections to RELAFY here is pretty much arbitrary,
covering everything I've seen .rela.* created for and anything else that
seems likely to need it.
Testing is trivial: try to strip -g a Linux kernel module (or any other
object file containing debug info) and observe the .debug* and
.rela.debug* sections turning up in the stripped output rather than (if
specified) the -f file. binutils behaves correctly in this area.
I haven't considered DWARF 1 sections not shared with DWARF 2+ at all
because I have no way to generate such sections for testing.
libebl/ChangeLog | 5 +++++
libebl/eblopenbackend.c | 36 +++++++++++++++++++-----------------
2 files changed, 24 insertions(+), 17 deletions(-)
diff --git a/libebl/ChangeLog b/libebl/ChangeLog
index af819a2..c6204c6 100644
--- a/libebl/ChangeLog
+++ b/libebl/ChangeLog
@@ -1,3 +1,8 @@
+2012-09-18 Nick Alcock <nick.alcock(a)oracle.com>
+
+ * eblopenbackend.c (default_debugscn_p): Add .rela.* versions of
+ many DWARF 2+ debuginfo sections.
+
2012-08-22 Jeff Kenton <jkenton(a)tilera.com>
* eblopenbackend.c (machines): Add tilegx.
diff --git a/libebl/eblopenbackend.c b/libebl/eblopenbackend.c
index 89e5da5..d10b0d0 100644
--- a/libebl/eblopenbackend.c
+++ b/libebl/eblopenbackend.c
@@ -619,6 +619,7 @@ default_object_note (const char *name __attribute__ ((unused)),
static bool
default_debugscn_p (const char *name)
{
+#define RELAFY(x) x, ".rela" x
/* We know by default only about the DWARF debug sections which have
fixed names. */
static const char *dwarf_scn_names[] =
@@ -630,31 +631,32 @@ default_debugscn_p (const char *name)
".debug_srcinfo",
".debug_sfnames",
/* DWARF 1.1 and DWARF 2 */
- ".debug_aranges",
- ".debug_pubnames",
+ RELAFY(".debug_aranges"),
+ RELAFY(".debug_pubnames"),
/* DWARF 2 */
- ".debug_info",
- ".debug_abbrev",
- ".debug_line",
- ".debug_frame",
- ".debug_str",
- ".debug_loc",
- ".debug_macinfo",
+ RELAFY(".debug_info"),
+ RELAFY(".debug_abbrev"),
+ RELAFY(".debug_line"),
+ RELAFY(".debug_frame"),
+ RELAFY(".debug_str"),
+ RELAFY(".debug_loc"),
+ RELAFY(".debug_macinfo"),
/* DWARF 3 */
- ".debug_ranges",
- ".debug_pubtypes",
+ RELAFY(".debug_ranges"),
+ RELAFY(".debug_pubtypes"),
/* DWARF 4 */
- ".debug_types",
+ RELAFY(".debug_types"),
/* GDB DWARF 4 extension */
".gdb_index",
/* GNU/DWARF 5 extension/proposal */
- ".debug_macro",
+ RELAFY(".debug_macro"),
/* SGI/MIPS DWARF 2 extensions */
- ".debug_weaknames",
- ".debug_funcnames",
- ".debug_typenames",
- ".debug_varnames"
+ RELAFY(".debug_weaknames"),
+ RELAFY(".debug_funcnames"),
+ RELAFY(".debug_typenames"),
+ RELAFY(".debug_varnames")
};
+#undef RELAFY
const size_t ndwarf_scn_names = (sizeof (dwarf_scn_names)
/ sizeof (dwarf_scn_names[0]));
for (size_t cnt = 0; cnt < ndwarf_scn_names; ++cnt)
--
1.7.12.156.gd7c4257
--
NULL && (void)
10 years
Strip on mips
by Kurt Roeckx
Hi,
I'm trying to debug why strip on mips isn't working properly.
What I see is that for the debug sections, sh_type is not set to
SHT_PROGBITS but to SHT_MIPS_DWARF.
The stripped file still ends up with the debug information it it,
and the file that is supposed to have the debug symbols in it
has it set to SHT_NOBITS, and is rather small.
I'm assuming this is because of the SHT_MIPS_DWARF. I'm not sure
how to find where it's going wrong.
Kurt
10 years, 11 months
[Patch] Add configure --enable-valgrind option to run all tests under valgrind.
by Mark Wielaard
Hi,
It seems beneficial to run the testcases under valgrind to find some
memory issues. This patch adds a new configure option --enable-valgrind
that makes it so that all tests run under valgrind and fail if valgrind
finds an memory issue (it succeeds with my latest two patches).
It is disabled by default since running make check becomes too slow
for normal use. But I enabled it for the make distcheck case, which
seems a good time to double check all tests are clean.
Comments?
Mark
10 years, 11 months
run-elf_cntl_gelf_getshdr.sh fails if '--enable-thread-safety' is used
by da jian
Hi
I am trying to compile elfutils 0.155. I have found that the selftest 'run-elf_cntl_gelf_getshdr.sh' fails, if elfutils is configured with option '--enable-thread-safety'. The error message is listed below.
Could anybody figure out if the failure is ignorable?
Thanks
...
PASS: run-low_high_pc.sh
PASS: run-macro-test.sh
--- test-elf_cntl_gelf_getshdr.out 2012-09-26 00:15:47.271257265 +0200
+++ - 2012-09-26 00:15:47.273064259 +0200
@@ -1,2 +1,35 @@
-test-elf_cntl_gelf_getshdr: elf_readall.c:73: __libelf_readall: Unexpected error: Resource deadlock avoided.
-./test-subr.sh: line 73: 9214 Aborted LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH" "$@"
+Section at offset 0x200
+Section at offset 0x21c
+Section at offset 0x240
+Section at offset 0x2e8
+Section at offset 0x510
+Section at offset 0x63e
+Section at offset 0x670
+Section at offset 0x6b0
+Section at offset 0x6e0
+Section at offset 0x890
+Section at offset 0x8b0
+Section at offset 0x9e0
+Section at offset 0xda4
+Section at offset 0xdb0
+Section at offset 0xed8
+Section at offset 0xf08
+Section at offset 0x1000
+Section at offset 0x1008
+Section at offset 0x1010
+Section at offset 0x1018
+Section at offset 0x11f8
+Section at offset 0x1200
+Section at offset 0x12a8
+Section at offset 0x12b8
+Section at offset 0x12b8
+Section at offset 0x12c9
+Section at offset 0x12f9
+Section at offset 0x1de1
+Section at offset 0x201e
+Section at offset 0x21d8
+Section at offset 0x265a
+Section at offset 0x2a93
+Section at offset 0x2ae3
+Section at offset 0x3530
+Section at offset 0x3d10
FAIL: run-elf_cntl_gelf_getshdr.sh
PASS: run-test-archive64.sh
PASS: msg_tst
...
11 years
[Patch] derelocate.c find_section must check next section exists
by Mark Wielaard
Hi,
While playing with valgrind I saw this:
==28430== Invalid read of size 8
==28430== at 0x4E48AC5: find_section (derelocate.c:321)
==28430== by 0x4E48D58: dwfl_module_address_section (derelocate.c:366)
==28430== by 0x400B06: main (dwfl-addr-sect.c:38)
==28430== Address 0x62a9a48 is not stack'd, malloc'd or (recently) free'd
Valgrind is right, there is an off-by-one check failure that can mean we
access beyond the end of an array. The following fixes it:
2012-09-25 Mark Wielaard <mjw(a)redhat.com>
* derelocate.c (find_section): Check next section exists before
accessing it.
Cheers,
Mark
11 years
[Patch] libdwfl/cu.c cudie_offset relies on uninitialized type_sig8
by Mark Wielaard
Hi,
Another thing valgrind caught:
==19596== Conditional jump or move depends on uninitialised value(s)
==19596== at 0x4E4E8F1: compare_cukey (cu.c:154)
==19596== by 0x536949E: tsearch (tsearch.c:260)
==19596== by 0x4E4E9DB: intern_cu (cu.c:173)
==19596== by 0x4E4EC4D: __libdwfl_nextcu (cu.c:265)
==19596== by 0x4E4EFF0: dwfl_nextcu (dwfl_nextcu.c:51)
==19596== by 0x400AFB: main (low_high_pc.c:99)
==19596== Uninitialised value was created by a stack allocation
==19596== at 0x4E4E980: intern_cu (cu.c:167)
Again valgrind is right, in libdwfl/cu.c cudie_offset () we use the cu
die type_sig8, which is never setup for the tsearch search key. The
simplest fix seems to be to just say this is never a TU here (the
alternative fix would be to initialize dwkey.type_sig8 to zero in
intern_cu).
2012-09-25 Mark Wielaard <mjw(a)redhat.com>
* cu.c (cudie_offset): Don't use type_sig8, it might not be
initialized and these are always real CUs, never TUs.
Cheers,
Mark
11 years
[PATCH 0/5] NT_ARM_VFP support and related patches
by Petr Machata
This is updated according to comments that I got (namely, NT_ARM_VFP
uses core note items to dump fpscr).
Two test cases were introduced for dumping core notes. Both are partial
core dumps with only headers and NOTE segment included, so that
potentially GPL'd stuff is not included.
Thanks,
PM
Petr Machata (5):
Test elfutils output of VMCOREINFO note.
Allow including core items in register sets.
Add back end code for interpreting NT_ARM_VFP core note.
In mixed core notes, don't let handle_core_item repeat.
Test elfutils output of a mixed core note.
backends/ChangeLog | 9 +++
backends/arm_corenote.c | 20 ++++++-
backends/linux-core-note.c | 11 ++++
src/readelf.c | 6 ++-
tests/ChangeLog | 14 ++++
tests/Makefile.am | 7 ++-
tests/run-readelf-mixed-corenote.sh | 87 ++++++++++++++++++++++++++
tests/run-readelf-vmcoreinfo.sh | 114 +++++++++++++++++++++++++++++++++++
tests/testfile62.bz2 | Bin 0 -> 3506 bytes
tests/testfile63.bz2 | Bin 0 -> 457 bytes
10 files changed, 264 insertions(+), 4 deletions(-)
create mode 100755 tests/run-readelf-mixed-corenote.sh
create mode 100755 tests/run-readelf-vmcoreinfo.sh
create mode 100644 tests/testfile62.bz2
create mode 100644 tests/testfile63.bz2
--
1.7.6.5
11 years
[patch] Support --enable-static
by Jan Kratochvil
Hi,
I do not see an easy way how to build elfutils statically and it also does not
use -rpath, therefore one needs to fiddle with LD_LIBRARY_PATH.
(Moreover I find shared libraries build inconvenient for debugging as GDB does
not pre-load before 'run' DT_NEEDED libraries which it could.)
OK for check-in?
Thanks,
Jan
elfutils/
2012-09-14 Jan Kratochvil <jan.kratochvil(a)redhat.com>
* configure.ac: New option --enable-static. Default to the
BUILD_STATIC conditional.
(BUILD_STATIC): Use $enable_static.
diff --git a/configure.ac b/configure.ac
index adec1c1..8e6e2db 100644
--- a/configure.ac
+++ b/configure.ac
@@ -190,8 +190,19 @@ if test "$use_gcov" = yes; then
fi
AM_CONDITIONAL(GCOV, test "$use_gcov" = yes)
-AM_CONDITIONAL(BUILD_STATIC, [dnl
-test "$use_mudflap" = yes -o "$use_gprof" = yes -o "$use_gcov" = yes])
+AC_ARG_ENABLE([static],[dnl
+AS_HELP_STRING([--enable-static], [build static binaries @<:@default=no@:>@])],[dnl
+case $enableval in
+ yes) enable_static=yes ;;
+ no) enable_static=no ;;
+ *) AC_MSG_ERROR([invalid --enable-static option $enableval]) ;;
+esac],[dnl
+if test "$use_mudflap" = yes -o "$use_gprof" = yes -o "$use_gcov" = yes; then
+ enable_static=yes
+else
+ enable_static=no
+fi])
+AM_CONDITIONAL(BUILD_STATIC, [test "$enable_static" = yes])
AC_ARG_ENABLE([tests-rpath],
AS_HELP_STRING([--enable-tests-rpath],[build $ORIGIN-using rpath into tests]),
11 years
[PATCH] Add back end code for interpreting NT_ARM_VFP core note
by Petr Machata
Signed-off-by: Petr Machata <pmachata(a)redhat.com>
---
backends/ChangeLog | 5 +++++
backends/arm_corenote.c | 13 ++++++++++++-
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/backends/ChangeLog b/backends/ChangeLog
index 0d51e73..1038fcb 100644
--- a/backends/ChangeLog
+++ b/backends/ChangeLog
@@ -1,3 +1,8 @@
+2012-09-17 Petr Machata <pmachata(a)redhat.com>
+
+ * arm_corenote.c (vfp_regs): New const variable.
+ (EXTRA_NOTES): Use it for NT_ARM_VFP.
+
2012-08-22 Jeff Kenton <jkenton(a)tilera.com>
* Makefile.am (modules): Add tilegx.
diff --git a/backends/arm_corenote.c b/backends/arm_corenote.c
index f73ab89..0784617 100644
--- a/backends/arm_corenote.c
+++ b/backends/arm_corenote.c
@@ -1,5 +1,5 @@
/* ARM specific core note handling.
- Copyright (C) 2009 Red Hat, Inc.
+ Copyright (C) 2009, 2012 Red Hat, Inc.
This file is part of elfutils.
This file is free software; you can redistribute it and/or modify
@@ -73,4 +73,15 @@ static const Ebl_Register_Location fpregset_regs[] =
#define TYPE_UID_T ELF_T_HALF
#define TYPE_GID_T ELF_T_HALF
+#define ARM_VFPREGS_SIZE ( 32 * 8 /*fpregs*/ + 4 /*fpscr*/ )
+static const Ebl_Register_Location vfp_regs[] =
+ {
+ { .offset = 0, .regno = 256, .count = 32, .bits = 64 }, /* fpregs */
+ /* 4-byte fpscr follows the set of 32 VFP registers, but that has
+ no assigned Dwarf register number. */
+ };
+
+#define EXTRA_NOTES \
+ EXTRA_REGSET (NT_ARM_VFP, ARM_VFPREGS_SIZE, vfp_regs)
+
#include "linux-core-note.c"
--
1.7.6.5
11 years
Value of FPREGSET_SIZE for ARM backend
by Petr Machata
Hi there,
currently that value is 140. This was introduced in eb9ba470ff on
2009-04-15 by Roland. But the floating point register file comes in
116-byte NT_FPREGSET note in ARM core files. Which is the size of
struct user_fp (arch/arm/include/asm/user.h) in kernels all the way back
to at least 2.5.0. Roland, do you know where the value of 140 comes
from? I'm inclined to guess at a typo or thinko of some sort.
Thank you,
PM
11 years