When elf section size is beyond unsigned int max value, objdump fails
to disassemble from that section. Ex on PowerPC,
$ objdump -h /proc/kcore
Idx Name Size VMA
4 load2 100000000 c000000000000000
Here, size of load2 section is 0x100000000. Also note that, 0xc00....
address range is kernel space for PowerPC. Now let's try to disassemble
do_sys_open() using /proc/kcore.
$ cat /proc/kallsyms | grep -A1 -w do_sys_open
c00000000036c000 T do_sys_open
c00000000036c2d0 T SyS_open
Before patch:
$ objdump -d --start-address=0xc00000000036c000 --stop-address=0xc00000000036c2d0 /proc/kcore
/proc/kcore: file format elf64-powerpcle
Disassembly of section load2:
c00000000036c000 <load2+0x36c000>:
c00000000036c000: Address 0xc00000000036c000 is out of bounds.
Fix this by changing type of 'buffer_length' from unsigned int to
size_t. After patch:
$ objdump -d --start-address=0xc00000000036c000 --stop-address=0xc00000000036c2d0 /proc/kcore
/proc/kcore: file format elf64-powerpcle
Disassembly of section load2:
c00000000036c000 <load2+0x36c000>:
c00000000036c000: fc 00 4c 3c addis r2,r12,252
c00000000036c004: 00 53 42 38 addi r2,r2,21248
c00000000036c008: a6 02 08 7c mflr r0
include/
* dis-asm.h (struct disassemble_info): Change type of buffer_length
field to size_t.
opcodes/
* dis-buf.c (buffer_read_memory): Change type of end_addr_offset,
max_addr_offset and octets variables to size_t.
These all were odd in that they used r13 as the GOT pointer. That
didn't matter for the purpose of testing, but would never occur in
practice. Also, the tlsopt5 tests could have their global dynamic
sequences optimized to initial exec, so link with -shared.
* testsuite/ld-powerpc/powerpc.exp: Add -shared to tlsop5 tests.
* testsuite/ld-powerpc/tlsopt5.d: Adjust.
* testsuite/ld-powerpc/tlsopt1_32.s: Use r30 as GOT pointer.
* testsuite/ld-powerpc/tlsopt2_32.s: Likewise.
* testsuite/ld-powerpc/tlsopt3_32.s: Likewise.
* testsuite/ld-powerpc/tlsopt4_32.s: Likewise.
* testsuite/ld-powerpc/tlsopt5_32.s: Rewrite.
* testsuite/ld-powerpc/tlsopt1_32.d: Adjust.
* testsuite/ld-powerpc/tlsopt2_32.d: Adjust.
* testsuite/ld-powerpc/tlsopt3_32.d: Adjust.
* testsuite/ld-powerpc/tlsopt5_32.d: Adjust.
Complement commit d940949881 ("Add a testcase for PR ld/21529") and
use a linker script to prevent an inter-segment gap arranged by the
default linker script associated with some targets such as `rx-elf':
$ ld -e main -o tmpdir/dump-elf tmpdir/pr21529.o
$ readelf -l tmpdir/dump-elf
Elf file type is EXEC (Executable file)
Entry point 0x10000004
There are 2 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0x10000000 0x10000000 0x00008 0x00008 R E 0x1000
LOAD 0x001ffc 0xbffffffc 0xbffffffc 0x00004 0x00004 RW 0x1000
Section to Segment mapping:
Segment Sections...
00 .text
01 .stack
$
and converted to padding with the use of the binary BFD for output from
producing unreasonably large files.
ld/
* testsuite/ld-unique/pr21529.ld: New test linker script.
* testsuite/ld-unique/pr21529.d: Use it.
In multiple places, we pass the gdbarch as an argument to some
functions, even though it's available in the agent_expr structure also
passed to the same functions. Remove these arguments and replace their
usage with accesses to agent_expr::gdbarch.
gdb/ChangeLog:
* dwarf2loc.h (dwarf2_compile_expr_to_ax): Remove gdbarch
parameter.
* symtab.h (struct symbol_computed_ops::tracepoint_var_ref):
Likewise.
* dwarf2loc.c (dwarf2_compile_expr_to_ax): Remove gdbarch
parameter, use agent_expr::gdbarch instead, update function
calls.
(locexpr_tracepoint_var_ref): Likewise.
(loclist_tracepoint_var_ref): Likewise.
* ax-gdb.c (gen_trace_static_fields): Likewise.
(gen_traced_pop): Likewise.
(gen_frame_args_address): Likewise.
(gen_frame_locals_address): Likewise.
(gen_var_ref): Likewise.
(gen_struct_ref_recursive): Likewise.
(gen_static_field): Likewise.
(gen_maybe_namespace_elt): Likewise.
(gen_expr): Likewise.
(gen_trace_for_var): Likewise.
(gen_trace_for_expr): Likewise.
(gen_trace_for_return_address): Likewise.
In many ax generation functions, the "expression *exp" parameter is only
used to access the gdbarch. The same value can be found in the
"agent_expr *ax" parameter, which needs to be passed in any case. By
using ax->gdbarch instead of exp->gdbarch, we can avoid passing exp in
many of these functions.
gdb/ChangeLog:
* ax-gdb.c (gen_usual_unary): Remove exp parameter, get gdbarch
from ax, update calls.
(gen_usual_arithmetic): Likewise.
(gen_integral_promotions): Likewise.
(gen_bitfield_ref): Likewise.
(gen_primitive_field): Likewise.
(gen_struct_ref_recursive): Likewise.
(gen_struct_ref): Likewise.
(gen_maybe_namespace_elt): Likewise.
(gen_struct_elt_for_reference): Likewise.
(gen_namespace_elt): Likewise.
(gen_aggregate_elt_ref): Likewise.
(gen_expr): Get gdbarch from ax, update calls.
(gen_expr_binop_rest): Likewise.
In the test gdb.mi/mi-vla-fortran.exp the parameters passed to
mi_create_breakpoint are passed in the wrong order. By good luck the
tests still passes, however the wrong test name is used. All fixed in
this commit.
A previous commit fixed most of these, but I missed this last one.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-vla-fortran.exp: Correct even more parameter passing
to mi_create_breakpoint.
Ref: https://sourceware.org/ml/gdb-patches/2017-07/msg00162.html
Debugging x86-64 GNU/Linux programs currently crashes GDB in
tdesc_use_registers during gdbarch initialization:
Program received signal SIGSEGV, Segmentation fault.
0x0000000001093eaf in htab_remove_elt_with_hash (htab=0x2ef9fa0, element=0x26af960, hash=557151073) at src/libiberty/hashtab.c:728
728 if (*slot == HTAB_EMPTY_ENTRY)
(top-gdb) p slot
$1 = (void **) 0x0
(top-gdb) bt
#0 0x0000000001093eaf in htab_remove_elt_with_hash (htab=0x2ef9fa0, element=0x26af960, hash=557151073) at src/libiberty/hashtab.c:728
#1 0x0000000001093e79 in htab_remove_elt (htab=0x2ef9fa0, element=0x26af960) at src/libiberty/hashtab.c:714
#2 0x00000000009121b0 in tdesc_use_registers (gdbarch=0x3001240, target_desc=0x2659cb0, early_data=0x2881cb0)
at src/gdb/target-descriptions.c:1328
#3 0x000000000047c93e in i386_gdbarch_init (info=..., arches=0x0) at src/gdb/i386-tdep.c:8634
#4 0x0000000000818d5f in gdbarch_find_by_info (info=...) at src/gdb/gdbarch.c:5394
#5 0x00000000007198a8 in set_gdbarch_from_file (abfd=0x2f48250) at src/gdb/arch-utils.c:618
#6 0x00000000007f21cb in exec_file_attach (filename=0x7fffffffddb0 "/home/pedro/gdb/tests/threads", from_tty=1) at src/gdb/exec.c:380
#7 0x0000000000865c18 in catch_command_errors_const (command=0x7f1d83 <exec_file_attach(char const*, int)>, arg=0x7fffffffddb0 "/home/pedro/gdb/tests/threads",
from_tty=1) at src/gdb/main.c:403
#8 0x00000000008669cf in captured_main_1 (context=0x7fffffffd860) at src/gdb/main.c:1035
#9 0x0000000000866de2 in captured_main (data=0x7fffffffd860) at src/gdb/main.c:1142
#10 0x0000000000866e24 in gdb_main (args=0x7fffffffd860) at src/gdb/main.c:1160
#11 0x000000000041312d in main (argc=3, argv=0x7fffffffd968) at src/gdb/gdb.c:32
The direct cause of the crash is that we tried to remove an element
from the hash which supposedly exists, but does not. (htab_remove_elt
shouldn't really crash in this case, but that's secondary.)
The real problem is that early_data passed to tdesc_use_registers
includes regs from a target description that is not the target_desc,
which violates its assumptions. The registers in question are the
fs_base/gs_base registers, added by amd64_init_abi:
tdesc_numbered_register (feature, tdesc_data_segments,
AMD64_FSBASE_REGNUM, "fs_base");
tdesc_numbered_register (feature, tdesc_data_segments,
AMD64_GSBASE_REGNUM, "gs_base");
and that happens because amd64_linux_init_abi uses amd64_init_abi as
helper, but they don't coordinate on which fallback tdesc to use.
amd64_init_abi does:
if (! tdesc_has_registers (tdesc))
tdesc = tdesc_amd64;
and then adds the fs_base/gs_base registers of the "tdesc_amd64" tdesc
to the tdesc_arch_data.
After amd64_init_abi returns, amd64_linux_init_abi does:
if (! tdesc_has_registers (tdesc))
tdesc = tdesc_amd64_linux;
tdep->tdesc = tdesc;
and we end up tdesc_amd64_linux installed in tdep->tdesc.
The fix is to make sure that amd64_linux_init_abi and amd64_init_abi
agree on default tdesc, by adding a "default tdesc" parameter to
amd64_init_abi, instead of having amd64_init_abi hardcode a default.
With this, amd64_init_abi creates the fs_base/gs_base registers using
the tdesc_amd64_linux tdesc.
Tested on x86-64 GNU/Linux, -m64. I don't have an x32 setup handy.
Thanks to John Baldwin, Yao Qi and Simon Marchi for the investigation.
gdb/ChangeLog:
2017-07-13 Pedro Alves <palves@redhat.com>
* amd64-darwin-tdep.c (x86_darwin_init_abi_64): Pass tdesc_amd64
as default tdesc.
* amd64-dicos-tdep.c (amd64_dicos_init_abi):
* amd64-fbsd-tdep.c (amd64fbsd_init_abi):
* amd64-linux-tdep.c (amd64_linux_init_abi): Pass
tdesc_amd64_linux as default tdesc. Get final tdesc from the
tdep.
(amd64_x32_linux_init_abi): Pass tdesc_x32_linux as default tdesc.
Get final tdesc from the tdep.
* amd64-nbsd-tdep.c (amd64nbsd_init_abi): Pass tdesc_amd64 as
default tdesc.
* amd64-obsd-tdep.c (amd64obsd_init_abi): Likewise.
* amd64-sol2-tdep.c (amd64_sol2_init_abi): Likewise.
* amd64-tdep.c (amd64_init_abi): Add 'default_tdesc' parameter.
Use it as default tdesc.
(amd64_x32_init_abi): Add 'default_tdesc' parameter, and pass it
down to amd_init_abi. No longer handle fallback tdesc here.
* amd64-tdep.h (tdesc_x32): Declare.
(amd64_init_abi, amd64_x32_init_abi): Add 'default_tdesc'
parameter.
* amd64-windows-tdep.c (amd64_windows_init_abi): Pass tdesc_amd64
as default tdesc.
In the test gdb.mi/mi-vla-fortran.exp the parameters passed to
mi_create_breakpoint are passed in the wrong order. By good luck the
tests still passes, however the wrong test name is used. All fixed in
this commit.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-vla-fortran.exp: Correct parameter passing to
mi_create_breakpoint.
Support record/replay of the z/Architecture instructions that were
introduced with arch12.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_process_record): Add support for
instructions new in arch12.
bfd * elf32-xtensa.c (elf_xtensa_get_plt_section): Increase length of
plt_name buffer.
(elf_xtensa_get_gotplt_section): Increase length of got_name
buffer.
* mach-o-arm.c (bfd_mach_o_arm_canonicalize_one_reloc): Add a
default return of FALSE.
* mach-o-i386.c (bfd_mach_o_i386_canonicalize_one_reloc): Add a
default return of FALSE.
binutils * dwarf.c (dwarf_vmatoa_1): Do not pass a NULL string pointer to
sprintf.
* srconv.c (walk_tree_type): Initialise the spare field of the
IT_dty structure.
gas * config/tc-pru.c (md_assemble): Add continue statement after
handling 'E' operand character.
* config/tc-v850.c (md_assemble): Initialise the 'insn' variable.
The problem is caused by the fact that gold is relocating the stubs
for an entire output section when it processes the relocations for a
particular input section that happened to be designated as the stub
table "owner". The Relocate_task for that input section may or may not
run before the Relocate_task for another input section that contains
the code that needs the erratum fix, but doesn't "own" the stub
table. If it runs before (or might even race with) that other task, it
ends up with a copy of the unrelocated original instruction.
In other words - when calling fix_errata() from
do_relocate_sections(), gold is going through the list of errata stubs
that are associated only with that object. This routine updates the
stored original instruction and replaces it in the output view with a
branch to the stub. Later, as gold is going through the object file's
input sections, it then checks for stub tables "owned" by each input
section, and writes out all the stubs from that stub table, regardless
of what object file each stub is associated with.
Fixed by relocating the erratum stub only after the corresponding
errata spot is fixed. That is to have fix_errata() call
Stub_table::relocate_erratum_stub() for each stub.
gold/ChangeLog
2017-07-06 Han Shen <shenhan@google.com>
PR gold/21491
* aarch64.cc (Erratum_stub::invalidate_erratum_stub): New method.
(Erratum_stub::is_invalidated_erratum_stub): New method.
(Stub_table::relocate_reloc_stub): Renamed from "relocate_stub".
(Stub_table::relocate_reloc_stubs): Renamed from "relocate_stubs".
(Stub_table::relocate_erratum_stub): New method.
(AArch64_relobj::fix_errata_and_relocate_erratum_stubs): Renamed from
"fix_errata".
(Target_aarch64::relocate_reloc_stub): Renamed from "relocate_stub".
Use ptrace operations to fetch and store the fs_base and gs_base registers
for FreeBSD/amd64 processes. Note that FreeBSD does not currently store the
value of these registers in core dumps, so these registers are only
available when inspecting a running process.
gdb/ChangeLog:
* amd64-bsd-nat.c (amd64bsd_fetch_inferior_registers): Use
PT_GETFSBASE and PT_GETGSBASE.
(amd64bsd_store_inferior_registers): Use PT_SETFSBASE and
PT_SETGSBASE.
On Fedora 26, "g++ -dumpversion" displays "7", instead of "7.1.1".
Update selective.exp to support single digit GCC version. Also
remove duplicated [4-9] version check.
* testsuite/ld-selective/selective.exp: Support single digit
GCC version.
Rationale behind the change instead of adding a `.init$' postfix being
that "initializer for symbol" is much more informative when inspecting D
runtime type information in gdb, which is the only place where you would
encounter references to this compiler-generated symbol.
gdb/testsuite/ChangeLog:
* gdb.dlang/demangle.exp: Update for demangling changes.
This patch supersedes
https://sourceware.org/ml/gdb-patches/2017-07/msg00009.html
---
Patch [1] broke a build on MinGW hosts, because MinGW doesn't provide POSIX
functions setenv () and unsetenv (). This can be fixed by using
implementations from gnulib.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9a6c7d9c0
gdb/ChangeLog
yyyy-mm-dd Anton Kolesov <Anton.Kolesov@synopsys.com>
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add setenv and
unsetenv.
* gnulib/aclocal.m4: Regenerate.
* gnulib/config.in: Regenerate.
* gnulib/configure: Regenerate.
* gnulib/import/Makefile.am: Regenerate.
* gnulib/import/Makefile.in: Regenerate.
* gnulib/import/m4/gnulib-cache.m4: Regenerate.
* gnulib/import/m4/gnulib-comp.m4: Regenerate.
* gnulib/import/m4/environ.m4: New file.
* gnulib/import/m4/setenv.m4: New file.
* gnulib/import/setenv.c: New file.
* gnulib/import/unsetenv.c: New file.
Compiling with clang gives this warning/error:
/home/emaisin/src/binutils-gdb/gdb/compile/compile-loc2c.c:731:6: error: variable 'uoffset' is uninitialized when used here [-Werror,-Wuninitialized]
uoffset += dwarf2_per_cu_text_offset (per_cu);
^~~~~~~
/home/emaisin/src/binutils-gdb/gdb/compile/compile-loc2c.c:669:23: note: initialize the variable 'uoffset' to silence this warning
uint64_t uoffset, reg;
^
= 0
I am really not sure if what this patch does is good, but it is my best
guess. DW_OP_addr means that there's an constant address provided by
the DWARF bytecode that should be pushed on the stack. That address is
considered skipped by the "op_ptr += addr_size", but it is never read.
uoffset is indeed read just after, without having been assigned first.
So I think the intent is to read the address, it was just omitted.
gdb/ChangeLog:
* compile/compile-loc2c.c (do_compile_dwarf_expr_to_c): Read
address when op is DW_OP_addr.
This Rust bug report:
https://github.com/rust-lang/rust/issues/41970
noted an error from gdb. What is happening here (for me, the original
report had a different error) is that a pieced DWARF expression is not
writing to every byte in the resulting value. GDB errors in this
case. However, it seems to me that it is always valid to write fewer
bytes; the issue comes from writing too many -- that is, the test is
reversed. The test was also checking the sub-object, but this also
seems incorrect, as it's expected for the expression to write the
entirety of the enclosing object. So, this patch reverses the test
and applies it to the outer type, not the subobject type.
Regtested on the buildbot.
gdb/ChangeLog
2017-07-09 Tom Tromey <tom@tromey.com>
* dwarf2loc.c (dwarf2_evaluate_loc_desc_full): Reverse size
check and apply to outer type.
gdb/testsuite/ChangeLog
2017-07-09 Tom Tromey <tom@tromey.com>
* gdb.dwarf2/shortpiece.exp: New file.
FreeBSD recently added a new ELF core note which dumps the entire LWP
info structure (the same structure returned by the ptrace PT_LWPINFO
operation) for each thread. The plan is for this note to eventually
supplant the older "thrmisc" ELF core note as it contains more
information and it permits new information to be exported via both
ptrace() and core dumps using the same structure.
For signal information, the implementation is similar to the native
implementation for FreeBSD processes. The PL_FLAG_SI flag must be
checked to determine if the embedded siginfo_t structure is valid, and
if so it is transferred into the caller's buffer.
gdb/ChangeLog:
* fbsd-tdep.c (LWPINFO_OFFSET, LWPINFO_PL_FLAGS)
(LWPINFO64_PL_SIGINFO, LWPINFO32_PL_SIGINFO, PL_FLAG_SI)
(SIZE64_SIGINFO_T, SIZE32_SIGINFO_T, fbsd_core_xfer_siginfo): New.
(fbsd_init_abi): Install gdbarch "core_xfer_siginfo" method.
This core dump note contains the same information returned by the
ptrace PT_LWPINFO operation for each LWP belonging to a process.
binutils/ChangeLog:
* readelf.c (get_freebsd_elfcore_note_type): Handle
NT_FREEBSD_PTLWPINFO.
include/ChangeLog:
* elf/common.h (NT_FREEBSD_PTLWPINFO): Define.
Previously the core_xfer_partial method used core_get_siginfo to handle
TARGET_OBJECT_SIGNAL_INFO requests. However, core_get_siginfo looked for
Linux-specific sections in the core file. To support fetching siginfo
from cores on other systems, add a new gdbarch method (`core_xfer_siginfo`)
and move the body of the existing core_get_siginfo into a
linux_core_xfer_siginfo implementation of this method in linux-tdep.c.
gdb/ChangeLog:
* corelow.c (get_core_siginfo): Remove.
(core_xfer_partial): Use the gdbarch "core_xfer_siginfo" method
instead of get_core_siginfo.
* gdbarch.sh (core_xfer_siginfo): New gdbarch callback.
* gdbarch.h: Re-generate.
* gdbarch.c: Re-generate.
* linux-tdep.c (linux_core_xfer_siginfo): New.
(linux_init_abi): Install gdbarch "core_xfer_siginfo" method.
Use the `pl_siginfo' field in the `struct ptrace_lwpinfo' object returned
by the PT_LWPINFO ptrace() request to supply the current contents of
$_siginfo for each thread. Note that FreeBSD does not supply a way to
modify the signal information for a thread, so $_siginfo is read-only for
FreeBSD.
To handle 32-bit processes on a 64-bit host, define types for 32-bit
compatible siginfo_t and convert the 64-bit siginfo_t to the 32-bit
equivalent when supplying information for a 32-bit process.
gdb/ChangeLog:
* fbsd-nat.c [PT_LWPINFO && __LP64__] (union sigval32)
(struct siginfo32): New.
[PT_LWPINFO] (fbsd_siginfo_size, fbsd_convert_siginfo): New.
(fbsd_xfer_partial) [PT_LWPINFO]: Handle TARGET_OBJECT_SIGNAL_INFO
via ptrace(PT_LWPINFO).
