My 2017-01-24 patch (commit f0158f44) wrongly applied an optimization
of GOT entries for the __tls_get_addr_opt stub, to shared libraries.
When the TLS segment layout is known, as it is for the executable and
shared libraries loaded at initial program start, powerpc supports a
__tls_get_addr optimization. On the first call to __tls_get_addr for
a given __tls_index GOT entry, the DTPMOD word is set to zero and the
DTPREL word to the thread pointer offset to the thread variable. This
allows the __tls_get_addr_opt stub to return that value immediately
without making a call into glibc for any subsequent __tls_get_addr
calls using that __tls_index GOT entry.
That's all fine, but I thought I'd be clever and when the thread
variable is local, set up the GOT entry as if __tls_get_addr had
already been called. Which is good only for the executable, since ld
cannot know the TLS layout for shared libraries.
Of course, if this only applies to executables there isn't much point
to the optimization. Normally, GD and LD code in an executable will
be converted to IE or LE, losing the __tls_get_addr call. So the only
time it will trigger is with --no-tls-optimize. Thus, revert all
support.
* elf64-ppc.c (ppc64_elf_relocate_section): Don't optimize
__tls_index GOT entries when using __tls_get_addr_opt stub.
* elf32-ppc.c (ppc_elf_relocate_section): Likewise.
Make sure all of the tests have unique names in
gdb.mi/mi-vla-fortran.exp.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-vla-fortran.exp: Make test names unique.
PR rust/21764 notes that "sizeof" does not work correctly for all types
in Rust. The bug turns out to be an error in the conversion of the AST
to gdb expressions. This patch fixes the bug and also avoids generating
incorrect expressions in another case.
Tested on the buildbot. I'm checking this in.
2017-07-14 Tom Tromey <tom@tromey.com>
PR rust/21764:
* rust-exp.y (convert_ast_to_expression): Add "want_type"
parameter.
<UNOP_SIZEOF>: Split into separate case.
<UNOP_VAR_VALUE>: Handle want_type. Add error case.
2017-07-14 Tom Tromey <tom@tromey.com>
PR rust/21764:
* gdb.rust/simple.exp: Add tests.
PR rust/21763 points out that gdb.lookup_typename does not work properly
for (some) Rust types. I tracked this down to a missing case in
symbol_matches_domain.
Tested by the buildbot.
2017-07-14 Tom Tromey <tom@tromey.com>
PR rust/21763:
* symtab.c (symbol_matches_domain): Add language_rust to special
case.
* rust-exp.y (convert_ast_to_expression) <OP_VAR_VALUE>: Don't
treat LOC_TYPEDEF symbols as variables.
2017-07-14 Tom Tromey <tom@tromey.com>
* gdb.rust/simple.exp: Add regression test for PR rust/21763.
This is the same patch as posted at
<https://sourceware.org/ml/gdb-patches/2017-02/msg00644.html>, with
the test at
<https://sourceware.org/ml/gdb-patches/2017-02/msg00687.html> squashed
in.
This patch fixes:
-FAIL: gdb.base/completion.exp: tab complete break break.c:ma (timeout)
-FAIL: gdb.base/completion.exp: complete break break.c:ma
+PASS: gdb.base/completion.exp: tab complete break break.c:ma
+PASS: gdb.base/completion.exp: delete breakpoint for tab complete break break.c:ma
+PASS: gdb.base/completion.exp: complete break break.c:ma
When run with --target_board=dwarf4-gdb-index.
The issue here is that make_file_symbol_completion_list_1, used when
completing a symbol restricted to a given source file, uses
lookup_symtab to look up the symtab with the given name, and search
for matching symbols inside. This assumes that there's only one
symtab for the given source file. This is an incorrect assumption
with (for example) -fdebug-types-section, where we'll have an extra
extra symtab containing the types. lookup_symtab finds that symtab,
and inside that symtab there are no functions...
gdb/ChangeLog:
2017-07-14 Pedro Alves <palves@redhat.com>
* symtab.c (make_file_symbol_completion_list_1): Iterate over
symtabs matching all symtabs with SRCFILE as file name instead of
only considering the first hit, with lookup_symtab.
gdb/testsuite/ChangeLog:
2017-07-14 Pedro Alves <palves@redhat.com>
* gdb.linespec/base/one/thefile.cc (z1): New function.
* gdb.linespec/base/two/thefile.cc (z2): New function.
* gdb.linespec/linespec.exp: Add tests.
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.
