Tom Tromey [Fri, 8 Sep 2017 21:38:12 +0000 (15:38 -0600)]
Make it simpler to add events to Python
The first patch in this series went through several iterations as I'd
forgotten how many places had to be touched to add a new event and a
new event type.
This patch simplifies the process using two new ".def" files. Now, a
new event type can be added by adding a line to "py-event-types.def",
and a new event registry can be added by adding a line to
"py-all-events.def".
ChangeLog
2017-09-11 Tom Tromey <tom@tromey.com>
* python/python.c (do_start_initialization): Use
py-event-types.def to initialize types.
Define all object type structures.
* python/python-internal.h: Don't declare event initialization
functions.
* python/py-threadevent.c (thread_event_object_type): Don't
define.
* python/py-stopevent.c (stop_event_object_type): Don't define.
* python/py-signalevent.c (signal_event_object_type): Don't
declare or define.
* python/py-newobjfileevent.c (new_objfile_event_object_type)
(clear_objfiles_event_object_type): Don't declare or define.
* python/py-infevents.c (inferior_call_pre_event_object_type)
(inferior_call_post_event_object_type)
(register_changed_event_object_type)
(memory_changed_event_object_type): Don't declare or define.
* python/py-inferior.c (new_thread_event_object_type)
(new_inferior_event_object_type)
(inferior_deleted_event_object_type): Don't declare or define.
* python/py-exitedevent.c (exited_event_object_type): Don't
declare or define.
* python/py-evts.c (gdbpy_initialize_py_events): Use
py-all-events.def.
* python/py-events.h (thread_event_object_type): Don't declare.
(events_object): Use py-all-events.def.
* python/py-event.h (GDBPY_NEW_EVENT_TYPE): Remove. Use
py-event-types.def.
* python/py-event-types.def: New file.
* python/py-continueevent.c (create_continue_event_object): Don't
declare or define.
* python/py-bpevent.c (breakpoint_event_object_type): Don't
declare or define.
* python/py-all-events.def: New file.
Tom Tromey [Fri, 8 Sep 2017 20:26:43 +0000 (14:26 -0600)]
Small event ownership clean up in Python layer
It seems cleaner to me for functions like create_thread_event_object,
which pass object ownership to their callers, to directly return a
gdb_ref<>. This way the ownership transfer is part of the API. This
patch makes this change.
Tom Tromey [Tue, 5 Sep 2017 18:07:00 +0000 (12:07 -0600)]
Add new_inferior, inferior_deleted, and new_thread events
This adds a few new events to gdb's Python layer: new_inferior,
inferior_deleted, and new_thread. I wanted to be able to add a
combined inferior/thread display window to my GUI, and I needed a few
events to make this work. This is PR python/15622.
The last commit unfortunately was not enough to fix the build breakage
on AArch64. I made a mistake and did not test it alone on BuildBot,
but along with another patch that was responsible for fixing the
breakage.
The failure is:
In file included from /usr/include/string.h:640:0,
from build-gnulib-gdbserver/import/string.h:41,
from ../../../binutils-gdb/gdb/gdbserver/../common/common-defs.h:56,
from ../../../binutils-gdb/gdb/gdbserver/server.h:22,
from ../../../binutils-gdb/gdb/gdbserver/regcache.c:19:
In function ‘void* memset(void*, int, size_t)’,
inlined from ‘regcache* init_register_cache(regcache*, const target_desc*, unsigned char*)’ at ../../../binutils-gdb/gdb/gdbserver/regcache.c:150:50:
/usr/include/aarch64-linux-gnu/bits/string3.h:81:32: error: call to ‘__warn_memset_zero_len’ declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [-Werror]
__warn_memset_zero_len ();
^
In function ‘void* memset(void*, int, size_t)’,
inlined from ‘regcache* get_thread_regcache(thread_info*, int)’ at ../../../binutils-gdb/gdb/gdbserver/regcache.c:57:60:
/usr/include/aarch64-linux-gnu/bits/string3.h:81:32: error: call to ‘__warn_memset_zero_len’ declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [-Werror]
__warn_memset_zero_len ();
This is likely due to a GCC bug, because for some reason the compiler
assumes that the third argument to the memset:
And the underlying problem is that the code is not calling the new
function "allocate_target_description" to allocate the "struct
target_desc" using "new" instead of XNEW, which end up not properly
initializing the fields of the structure.
The problem is that this is undefined if current_ui is NULL, which can
happen early on during gdb start up.
If we run into an error during early gdb start up then we write the
error message to gdb_stderr. However, if we are too early during the
start up then current_ui is NULL, and using the gdb_stderr macro
triggers undefined behaviour.
We try to avoid this using a check 'gdb_stderr == NULL' which was fine
before the recent changes, but now, still triggers undefined behaviour.
A better check is instead 'current_ui == NULL' which is what I use in
this patch.
Triggering this failure is pretty hard, most of the really early errors
are only triggered if pretty basic things are not as expected, for
example, if the default signal handlers are not as expected. Seeing one
of these errors trigger usually means that someone working on gdb has
made an incorrect change. Still, the errors are present in gdb, and
should we ever trigger one it would be nice if gdb didn't crash.
For testing this change I've been applying this patch which adds an
unconditional error into a function called early during gdb start up.
Later in the same function is a real error call which, in some
circumstances could be triggered:
Tom Tromey [Mon, 14 Aug 2017 06:15:33 +0000 (00:15 -0600)]
Use gdb::byte_vector in pascal_object_print_value
This changes pascal_object_print_value to use a gdb::byte_vector.
This removes a cleanup. This change also points out how the previous
code had a possible use-after-free bug.
ChangeLog
2017-09-09 Tom Tromey <tom@tromey.com>
* p-valprint.c (pascal_object_print_value): Use gdb::byte_vector.
Tom Tromey [Thu, 7 Sep 2017 03:41:40 +0000 (21:41 -0600)]
Use ui_out_emit_list and ui_out_emit_tuple with gdb::optional
This changes a few spots to use ui_out_emit_list and/or
ui_out_emit_tuple with gdb::optional, to preserve existing behavior.
This allows for the removal of a few more cleanups.
ChangeLog
2017-09-09 Tom Tromey <tom@tromey.com>
* mi/mi-cmd-var.c (mi_cmd_var_list_children): Use gdb::optional,
ui_out_emit_list, ui_out_emit_tuple.
(mi_cmd_var_update): Likewise.
Tom Tromey [Sat, 9 Sep 2017 15:15:23 +0000 (09:15 -0600)]
Use ui_out_emit_table and ui_out_emit_list in print_thread_info_1
This changes print_thread_info_1 to use ui_out_emit_table and
ui_out_emit_list. Which one is used depends on whether the ui-out is
mi-like; so the emitters are wrapped in gdb::optional.
ChangeLog
2017-09-09 Tom Tromey <tom@tromey.com>
* thread.c (print_thread_info_1): Use ui_out_emit_table,
ui_out_emit_list, gdb::optional.
Alan Modra [Sat, 9 Sep 2017 12:25:22 +0000 (21:55 +0930)]
PowerPC64 --plt-align
This changes the PowerPC64 --plt-align option to perform the usual
alignment of code as suggested by its name, as well as the previous
behaviour of padding so as to reduce boundary crossing. The old
behaviour is had by using a negative parameter.
The default is also changed to align plt stub code by default to 32
byte boundaries, the point being to get better bctr branch prediction
on power8 and power9 hardware.
bfd/
* elf64-ppp.c (plt_stub_pad): Handle positive and negative
plt_stub_align.
ld/
* ld.texinfo (--plt-align): Describe new behaviour of option.
* emultempl/ppc64elf.em (params): Default plt_stub_align to 5.
* testsuite/ld-powerpc/powerpc.exp: Pass --no-plt-align for
selected tests.
* testsuite/ld-powerpc/relbrlt.d: Pass --no-plt-align.
* testsuite/ld-powerpc/elfv2so.d: Adjust expected output.
H.J. Lu [Sat, 9 Sep 2017 14:29:15 +0000 (07:29 -0700)]
x86: Update UNDEFINED_WEAK_RESOLVED_TO_ZERO
Since the only information which SYMBOL_REFERENCES_LOCAL_P doesn't check
is relocations, UNDEFINED_WEAK_RESOLVED_TO_ZERO only needs to check for
relocations with SYMBOL_REFERENCES_LOCAL_P.
H.J. Lu [Sat, 9 Sep 2017 12:31:30 +0000 (05:31 -0700)]
x86: Remove restriction on NOTRACK prefix position
Since the NOTRACK prefix is no longer required to be the last prefix
before the REX prefix, restriction on the NOTRACK prefix position is
removed from assembler as well as disassembler. Assembler encodes the
NOTRACK prefix the same way as the DS segment register, which places
it before other prefixes. Disassembler displays prefixes in the order
they appear.
gas/
* config/tc-i386.c (NOTRACK_PREFIX): Removed.
(REX_PREFIX): Updated.
(MAX_PREFIXES): Likewise.
(parse_insn): Remove restriction on NOTRACK prefix position.
* testsuite/gas/i386/notrack.s: Add tests with NOTRACK prefix
before other prefixes.
* testsuite/gas/i386/x86-64-notrack.s: Likewise.
* testsuite/gas/i386/notrackbad.s: Remove tests with NOTRACK
prefix before other prefixes.
* testsuite/gas/i386/x86-64-notrackbad.s: Likewise.
* testsuite/gas/i386/notrack-intel.d: Updated.
* testsuite/gas/i386/notrack.d: Likewise.
* testsuite/gas/i386/notrackbad.l: Likewise.
* testsuite/gas/i386/x86-64-notrack-intel.d: Likewise.
* testsuite/gas/i386/x86-64-notrack.d: Likewise.
* testsuite/gas/i386/x86-64-notrackbad.l: Likewise.
H.J. Lu [Sat, 9 Sep 2017 12:05:16 +0000 (05:05 -0700)]
x86: Properly handle __ehdr_start
After _bfd_i386_elf_convert_load and _bfd_x86_64_elf_convert_load are
removed, elf_i386_convert_load_reloc and elf_x86_64_convert_load_reloc
see __ehdr_start as an undefined symbol when they are called from
check_relocs to convert GOT relocations against local symbols. But
__ehdr_start will be defined as a hidden symbol by linker at the later
stage if it is referenced. This patch marks __ehdr_start as a defined
local symbol at the start of check_relocs if it is referenced and not
defined.
bfd/
PR ld/22115
* elf32-i386.c (elf_i386_convert_load_reloc): Check linker_def.
Don't use UNDEFINED_WEAK_RESOLVED_TO_ZERO.
* elf64-x86-64.c (elf_x86_64_convert_load_reloc): Check
linker_def. Don't use UNDEFINED_WEAK_RESOLVED_TO_ZERO.
* elfxx-x86.c (_bfd_x86_elf_link_check_relocs): Set local_ref
and linker_def on __ehdr_start if it is referenced and not
defined.
(_bfd_x86_elf_link_symbol_references_local): Also set local_ref
and return TRUE when building executable, if a symbol has
non-GOT/non-PLT relocations in text section or there is no
dynamic linker.
* elfxx-x86.h (elf_x86_link_hash_entry): Add linker_def.
Remove C/C++ relevant code in Fortran specific file.
Remove code relevant for printing C/C++ Integer values in a
Fortran specific file to unify printing of Fortran values.
This does not change the output.
Frank Penczek [Fri, 8 Sep 2017 13:11:47 +0000 (15:11 +0200)]
Fix indentation for printing Fortran types with pointers
Printing the prefix "PTR TO -> (" resp. "REF TO ->(" ignored the active
indentation level. This caused inconsistent appearance of user-defined
Fortran types containing pointers. Fix by using "fprintfi_filtered" with the
current indentation level for outputting the prefix string. Add test case
ptr-indentation.
Example using 'ptype' on object of type:
type TypeWithPointer
integer i
integer, pointer:: p
end type TypeWithPointer
Before:
type = Type typewithpointer
integer(kind=4) :: i
PTR TO -> ( integer(kind=4) :: p)
End Type typewithpointer
After:
type = Type typewithpointer
integer(kind=4) :: i
PTR TO -> ( integer(kind=4) :: p)
End Type typewithpointer
H.J. Lu [Fri, 8 Sep 2017 00:19:10 +0000 (17:19 -0700)]
x86; Don't add elf64-x86-64.lo nor elf64.lo together with elfxx-x86.lo
Don't set r_info and r_sym fields in _bfd_x86_elf_link_hash_table_create.
Instead, set them in _bfd_x86_elf_link_setup_gnu_properties. We can
avoid adding elf64-x86-64.lo and elf64.lo together with elfxx-x86.lo to
bfd_backends.
* configure.ac (bfd_backends): Don't add elf64-x86-64.lo nor
elf64.lo together with elfxx-x86.lo for 64-bit BFD.
* configure: Regenerated.
* elf32-i386.c (elf_i386_link_setup_gnu_properties): Set r_info
and r_sym fields of plt_layout.
* elf64-x86-64.c (elf_x86_64_link_setup_gnu_properties):
Likewise.
* elfxx-x86.c (elf_x86_64_is_reloc_section): Remove BFD64 check.
(_bfd_x86_elf_link_hash_table_create): Likewise. Don't set
r_info nor r_sym fields.
(_bfd_x86_elf_link_setup_gnu_properties): Set r_info and r_sym
fields of htab.
* elfxx-x86.h (elf_x86_plt_layout_table): Add r_info and r_sym.
This ends up manifesting due to the two-byte compressed NOP that's
pessimisticly emitted by the ".align 2", which results in "rvc_boundry"
being 2-byte aligned. frag_align_code() then goes and outputs a 2-byte
NOP (which is invalid in no-RVC mode) to align the code back to a 4-byte
boundry, which can't be relaxed away by the linker as it's not part of
the R_RISCV_RELAX relocation.
The fix is to just always emit the worst case possible alignment into
the output as a single R_RISCV_RELAX, which the linker will then fix up.
With this patch I get the expected code generation
Palmer Dabbelt [Wed, 16 Aug 2017 17:41:56 +0000 (10:41 -0700)]
RISC-V: Support PCREL_* relocations agaist weak undefined symbols
I recently modified our Linux port's base address such the absolute
address 0 is no longer addressable as a 32-bit PC-relative offset.
Since Linux links a weak undefined symbol in an intermediate binary, it
needs to be able to reference absolute address 0.
This patch changes R_RISCV_PCREL_* relocations to absolute relocations
while resolving them in order to allow these symbols to be referenced in
PC-relative programs linked at high addresses. Note that this doesn't
apply to PIC, which also uses PC-relative relocations, just to
position-dependent objects, which we use to allow programs to be linked
at high addresses.
In case some of our embedded users are using R_RISCV_PCREL_* as a hacked
up method of getting position-independent binaries (which can work if
you have very simple programs), we only convert the relocations when the
PC-relative version would overflow.
bfd/ChangeLog:
2017-09-07 Palmer Dabbelt <palmer@dabbelt.com>
* elfnn-riscv.c (riscv_zero_pcrel_hi_reloc): New function.
(riscv_record_pcrel_hi_reloc): Add absolute argument.
(riscv_elf_relocate_section): Call riscv_zero_pcrel_hi_reloc for
R_RISCV_PCREL_HI20 relocs, and pass the result to
riscv_record_pcrel_hi_reloc.
I think the second entry is just a rebase/merge oversight, and it wasn't
meant to be added there, particularly since the 7.11 branch was no longer
active at that time anymore.
This patch just removes the entry.
gdb/ChangeLog:
* NEWS (Changes in GDB 7.11): Remove entry for QStartupWithShell.
H.J. Lu [Thu, 7 Sep 2017 11:03:15 +0000 (04:03 -0700)]
x86: Remove _bfd_{i386,x86_64}_elf_convert_load
Instead of converting GOT relocations when sizing dynamic sections, we
convert GOT relocations during relocation check. Add a field, local_ref,
to elf_x86_link_hash_entry to indicate if symbol references are always
local with a new function to check if symbol references are always local,
which works in check_relocs.
* elf32-i386.c (elf_i386_convert_load_reloc): Add an argument,
r_type_p. Remove the converted argument. Replace
SYMBOL_REFERENCES_LOCAL with SYMBOL_REFERENCES_LOCAL_P. Return
the new relocation type via r_type_p.
(elf_i386_relocate_section): Likewise.
(elf_i386_finish_dynamic_symbol): Likewise.
(need_convert_load): Removed.
(check_relocs_failed): Updated.
(elf_i386_check_relocs): Call elf_i386_convert_load_reloc,
instead of setting need_convert_load.
(_bfd_i386_elf_convert_load): Removed.
* elf64-x86-64.c (need_convert_load): Removed.
(check_relocs_failed): Updated.
(elf_x86_64_convert_load_reloc): Add an argument, r_type_p.
Replace SYMBOL_REFERENCES_LOCAL with SYMBOL_REFERENCES_LOCAL_P.
Return the new relocation type via r_type_p.
(elf_x86_64_check_relocs): Call elf_x86_64_convert_load_reloc,
instead of setting need_convert_load.
(elf_x86_64_check_relocs): Don't check PIC if relocation has
been converted.
(_bfd_x86_64_elf_convert_load): Removed.
(elf_x86_64_relocate_section): Replace SYMBOL_REFERENCES_LOCAL
with SYMBOL_REFERENCES_LOCAL_P.
(elf_x86_64_finish_dynamic_symbol): Likewise.
* elfxx-x86.c (_bfd_x86_elf_link_hash_table_create): Don't
set convert_load.
(_bfd_x86_elf_size_dynamic_sections): Don't call convert_load.
(_bfd_x86_elf_link_symbol_references_local): New function.
* elfxx-x86.h (SYMBOL_REFERENCES_LOCAL_P): New.
(UNDEFINED_WEAK_RESOLVED_TO_ZERO): Replace elf.forced_local with
SYMBOL_REFERENCES_LOCAL_P.
(elf_x86_link_hash_entry): Add local_ref.
(elf_x86_link_hash_table): Remove convert_load.
(_bfd_i386_elf_convert_load): Removed.
(_bfd_x86_64_elf_convert_load): Likewise.
(_bfd_x86_elf_link_symbol_references_local): New.
Tom Tromey [Mon, 4 Sep 2017 03:50:47 +0000 (21:50 -0600)]
Change funcall_chain to be a std::vector
This simplifies the handling of funcall_chain, by changing it to be a
std::vector<int> and then fixing the users. This allows the removal
of a cleanup.
It would be even cleaner to replace this with better logic in the
parsers; but a baby step seemed ok.
gdb/ChangeLog
2017-09-05 Tom Tromey <tom@tromey.com>
* parse.c (funcall_chain): Now a std::vector.
(start_arglist, end_arglist): Simplify.
(free_funcalls): Remove.
(parse_exp_in_context_1): Remove cleanup.
This patch introduces functions to simplify this to:
mangled = dw2_linkage_name (die, cu);
or
attr = dw2_linkage_name_attr (die, cu);
gdb/ChangeLog:
* dwarf2read.c (dw2_linkage_name_attr): New function.
(dw2_linkage_name): New function.
(dwarf2_compute_name, dwarf2_physname, read_call_site_scope)
(guess_full_die_structure_name, dwarf2_name): Use dw2_linkage_name.
(anonymous_struct_prefix, dwarf2_name): Use dw2_linkage_name_attr.
Tests in gdb.arch/thumb2-it.exp call functions defined in assembly
without type debugging information. Since 7022349d5c86bae74b49225515f42d2e221bd368 ("Stop assuming no-debug-info
functions return int") this triggers an error which leads to many tests
to FAIL. This patch cast the call to indicate the return type of the
functions when calling them.
2017-09-06 Thomas Preud'homme <thomas.preudhomme@arm.com>
gdb/testsuite/
* gdb.arch/thumb2-it.exp: Cast call to assembly defined function.
H.J. Lu [Wed, 6 Sep 2017 12:06:35 +0000 (05:06 -0700)]
x86-64: Add R_X86_64_converted_reloc_bit
Add R_X86_64_converted_reloc_bit to relocation type to indicate if a
relocation is converted from a GOTPCREL relocation. Linker now generates
failed to convert GOTPCREL relocation; relink with --no-relax
for all cases, including relocations against local symbols.
bfd/
* elf64-x86-64.c (R_X86_64_converted_reloc_bit): New.
(elf_x86_64_info_to_howto): Get the real relocation type by
masking out R_X86_64_converted_reloc_bit.
(elf_x86_64_check_tls_transition): Get the real relocation type
by masking out R_X86_64_converted_reloc_bit.
(elf_x86_64_convert_load_reloc): Set R_X86_64_converted_reloc_bit
instead of setting converted_reloc.
(elf_x86_64_relocate_section): Check R_X86_64_converted_reloc_bit
instead of converted_reloc. Get the real relocation type by
masking out R_X86_64_converted_reloc_bit.
(elf_x86_64_link_setup_gnu_properties): Verify that the value of
R_X86_64_converted_reloc_bit is valid.
* elfxx-x86.h (converted_reloc): Removed.
H.J. Lu [Wed, 6 Sep 2017 11:49:47 +0000 (04:49 -0700)]
x86: Don't change r_type when performing TLS transitions
Don't change r_type when performing TLS transitions to avoid getting
the relocation type with ELF32_R_TYPE again.
* elf32-i386.c (elf_i386_relocate_section): Don't change r_type
when calling elf_i386_tls_transition. Don't use ELF32_R_TYPE
to get the relocation type again.
* elf64-x86-64.c (elf_x86_64_relocate_section): Don't change
r_type when calling elf_x86_64_tls_transition. Don't use
ELF32_R_TYPE to get the relocation type again.
Jan Kratochvil [Wed, 6 Sep 2017 11:32:46 +0000 (12:32 +0100)]
Fix accessing TLS variables with no debug info
Since 2273f0ac95a7 ("change minsyms not to be relocated at
read-time"), printing TLS symbols of objfiles with a non-zero base
address, without debug info, fails.
The regression is not visible with glibc debuginfo installed.
The problem is that we compute the address of TLS minsyms incorrectly.
To trigger the problem, it is important that the variable is in an
objfile with a non-zero base address. While glibc is a shared library
for 'errno', it's easier for the testcase to use PIE instead of a
shlib. For TLS variables in PT_EXEC the regression obviously does not
happen.
gdb/ChangeLog
2017-09-06 Jan Kratochvil <jan.kratochvil@redhat.com>
* parse.c (find_minsym_type_and_address): Don't relocate addresses
of TLS symbols.
gdb/testsuite/ChangeLog
2017-09-06 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.threads/tls-nodebug-pie.c: New file.
* gdb.threads/tls-nodebug-pie.exp: New file.
Fix leak of auto_obstack objfile_per_bfd_storage->storage_obstack;
commit 23732b1e32dd58f7c731d9aee56ff0b22a645d53
Author: Pedro Alves <palves@redhat.com>
Date: Tue Jun 27 16:22:08 2017 +0100
changed objfile_per_bfd_storage->storage_obstack
from 'struct obstack storage_obstack;'
to 'auto_obstack storage_obstack;'
So the obstack is auto allocated when the objfile_per_bfd_storage ctor is
manually called by get_objfile_bfd_data).
However, the ctor call was still followed by a manual call to
obstack_init (&storage->storage_obstack);
This results in a bunch of leaks detected by valgrind, such as:
==24665== 4,064 bytes in 1 blocks are definitely lost in loss record 11,469 of 11,590
==24665== at 0x4C27BF5: malloc (vg_replace_malloc.c:299)
==24665== by 0x5437B7: xmalloc (common-utils.c:44)
==24665== by 0x77CAA7: _obstack_begin_worker (obstack.c:141)
==24665== by 0x60168F: auto_obstack (gdb_obstack.h:70)
==24665== by 0x60168F: get_objfile_bfd_data(objfile*, bfd*) (objfiles.h:188)
==24665== by 0x601DB6: allocate_objfile(bfd*, char const*, enum_flags<objfile_flag>) (objfiles.c:423)
==24665== by 0x647753: symbol_file_add_with_addrs(bfd*, char const*, enum_flags<symfile_add_flag>, section_addr_info*, enum_flags<objfile_flag>, objfile*) (symfile.c:1158)
==24665== by 0x647C7B: symbol_file_add_separate(bfd*, char const*, enum_flags<symfile_add_flag>, objfile*) (symfile.c:1252)
==24665== by 0x4C7D79: elf_symfile_read(objfile*, enum_flags<symfile_add_flag>) (elfread.c:1270)
==24665== by 0x647CB4: read_symbols(objfile*, enum_flags<symfile_add_flag>) (symfile.c:861)
==24665== by 0x647809: syms_from_objfile_1 (symfile.c:1062)
-> remove the manual call to obstack_init.
Reg-tested on Debian 8/amd64, tests results are the same before/after the patch.
valgrind still show some leaks, but less.
gdb/ChangeLog
2017-09-05 Philippe Waroquiers <philippe.waroquiers@skynet.be>
H.J. Lu [Tue, 5 Sep 2017 18:24:01 +0000 (11:24 -0700)]
x86-64: Improve GOTPCREL relocation conversion
When GOTPCREL relocation conversion leads to relocation overflow, we
may get a mysterious linker message, like
relocation truncated to fit: R_X86_64_32S against symbol `foo'
This patch changes the linker message to
failed to convert GOTPCREL relocation; relink with --no-relax
bfd/
* elf64-x86-64.c (elf_x86_64_convert_load_reloc): Remove the sec
argument. Don't check relocation overflow. Avoid relocation
overflow if --no-relax is used. Set converted_reloc on symbol
if a GOTPCREL relocation is converted.
(elf_x86_64_relocate_section): Issue a fatal error and suggest
--no-relax if GOTPCREL relocation conversion leads to relocation
overflow.
* elfxx-x86.h (elf_x86_link_hash_entry): Add converted_reloc.
Tom Tromey [Mon, 4 Sep 2017 05:15:03 +0000 (23:15 -0600)]
Don't use -fdiagnostics-color=never for rustc
I noticed that the gdb.rust tests fail because the test suite passes
-fdiagnostics-color=never to rustc. This is not a recognized rustc
option, and the test suite already handles passing the appropriate
option to the Rust compiler.
This patch fixes the problem.
testsuite/ChangeLog
2017-09-05 Tom Tromey <tom@tromey.com>
* lib/gdb.exp (gdb_compile): Don't use universal_compile_options
for rust.
Simon Marchi [Tue, 5 Sep 2017 15:40:44 +0000 (17:40 +0200)]
Test different follow-exec-mode settings in gdb.multi/multi-arch-exec.exp
Using follow-exec-mode "new" takes a different code path than "same", so
it's interesting to test this path in combination with a change in
architecture of the inferior. This test fails if you remove the
previous patch.
gdb/testsuite/ChangeLog:
* gdb.multi/multi-arch-exec.exp: Test with different
"follow-exec-mode" settings.
(do_test): New procedure.
Simon Marchi [Tue, 5 Sep 2017 15:30:27 +0000 (17:30 +0200)]
Add thread after updating gdbarch when exec'ing
As mentioned in the previous patch, we should avoid doing register reads
after a process does an exec and before we've updated that inferior's
gdbarch. Otherwise, we may interpret the registers using the wrong
architecture. When a process does an exec with "follow-exec-mode new",
a new inferior is added by follow_exec. The gdbarch of that new
inferior is at first set to some default value, probably specific to the
gdb build (I get "i386" here), which may not be the right one. It is
updated later by the call to target_find_description. Before that
point, if we try to read the inferior's registers, we may not interpret
them correctly. This has been exposed by a failure in
gdb.base/foll-exec-mode.exp after the previous patch, with:
Remote 'g' packet reply is too long (expected 312 bytes, got 816 bytes)
The call to "add_thread" done just after adding the inferior is
problematic, because it ends up reading the registers (because the ptid
is re-used, we end up doing a switch_to_thread to it, which tries to
update stop_pc). The registers returned by gdbserver are the x86-64
ones, while we try to interpret them using the "i386" gdbarch.
Postponing the call to add_thread to until the target
description/gdbarch has been updated seems to fix the issue.
As to why this issue was uncovered by the previous patch: what I think
happened before that patch is that since we were updating stop_pc before
switching to the new inferior, we were filling the regcache associated
to the ptid (this worked fine as long as the architectures of the
previous and new process images were the same). The call to
switch_to_thread then worked, because the register read hit the
regcache. Now, it triggers a register read, while the gdbarch is not
set correctly, leading to the "reply is too long" error. If this is
right, it sounds wrong that we delete and re-add a thread with the same
ptid, and are able to access the registers from the deleted thread.
When we delete a thread, should we clear the regcache associated to that
ptid, so that the new thread starts with a fresh/empty regcache?
gdb/ChangeLog:
* infrun.c (follow_exec): Call add_thread after
target_find_description.
Simon Marchi [Tue, 5 Sep 2017 14:45:10 +0000 (16:45 +0200)]
Read stop_pc after updating the gdbarch when exec'ing
When an inferior execs and changes architecture (e.g. 64 bits to 32
bits), the gdbarch associated to the inferior is updated by the
follow_exec call in handle_inferior_event_1. We should avoid doing any
register read before that point, because the registers sent by the
remote side will be those of the new architecture, but we would
interpret them using the old architecture. We do just that by setting
stop_pc during this window, which obviously requires reading the
registers. This results in gdb.multi/multi-arch-exec.exp failing, GDB
outputting the following error:
Truncated register 50 in remote 'g' packet
This patch fixes that by postponing the setting of stop_pc to after
we've updated the inferior gdbarch.
This bug was hiding another problem, and as such introduces some
failures in gdb.base/foll-exec-mode.exp. The following patch takes care
of that.
gdb/ChangeLog:
* infrun.c (handle_inferior_event_1): When exec'ing, read
stop_pc after follow_exec.
Simon Marchi [Tue, 5 Sep 2017 14:43:07 +0000 (16:43 +0200)]
Improve "'g' reply is is to long" error message
... by adding the expected size, and the received size. I found this
useful when debugging gdbarch/remote issues, since it gives a hint of
what gdb expects and what the remote sent.
Pedro Alves [Tue, 5 Sep 2017 11:13:57 +0000 (12:13 +0100)]
eval.c:evaluate_subexp_standard: Factor out function call handling
While working on the no-debug-info debugging improvements, I found
evaluate_subexp_standard's function call code unnecessarily long and
hard to navigate and debug. The use of goto doesn't help either.
This commit tries to improve things by factoring out the
function-call-related code to separate helper functions.
gdb/ChangeLog:
2017-09-05 Pedro Alves <palves@redhat.com>
* eval.c (eval_call, evaluate_funcall): New functions, factored
out from ...
(evaluate_subexp_standard): ... this.
* configure.srv (srv_i386_regobj): Remove.
(srv_amd64_regobj): Remove.
(srv_regobj): Set it to "" for x86 non-linux targets.
* linux-x86-tdesc.c (i386_linux_read_description):
* lynx-i386-low.c: Include x86-xstate.h and arch/i386.h.
(init_registers_i386): Remove the declaration.
(tdesc_i386): Remove the declaration.
(lynx_i386_arch_setup): Call i386_create_target_description.
* nto-x86-low.c: Likewise.
* win32-i386-low.c [__x86_64__]: include arch/amd64.h.
[!__x86_64__]: include arch/i386.h.
(i386_arch_setup) [__x86_64__]: Call amd64_create_target_description.
Yao Qi [Tue, 5 Sep 2017 08:54:54 +0000 (09:54 +0100)]
[GDBserver] Shorten srv_amd64_linux_xmlfiles
GDBserver now is able to generate target descriptions from features, so
don't need to remember these target description files.
Note that it should be i386/amd64-avx-avx512-linux.xml instead of
i386/amd64-avx-avx512.xml in $srv_amd64_linux_xmlfiles. This patch
removes it anyway.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* configure.srv (srv_amd64_linux_xmlfiles): Remove
i386/amd64-XXX-linux from it.
Yao Qi [Tue, 5 Sep 2017 08:54:53 +0000 (09:54 +0100)]
Centralize amd64-linux target descriptions
This patch adds a new function amd64_linux_read_description, which
creates amd64-linux target descriptions according to its two
arguments, xcr0 and is_x32.
Yao Qi [Tue, 5 Sep 2017 08:54:53 +0000 (09:54 +0100)]
[GDBserver] Use pre-generated tdesc as test
Now, these *-generate.c files are only used in GDBserver for unit test.
If $development is false (in release), these *-generate.c files won't be
used at all.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* configure.srv: Set srv_i386_linux_regobj empty if $development
is false.
* linux-i386-ipa.c (initialize_low_tracepoint): Don't call
initialize_low_tdesc.
* linux-x86-low.c (initialize_low_arch): Wrap initialize_low_tdesc
with #if initialize_low_tdesc.
* linux-x86-tdesc-selftest.c: New file.
* linux-x86-tdesc.c: Move code to linux-x86-tdesc-selftest.c.
Yao Qi [Tue, 5 Sep 2017 08:54:53 +0000 (09:54 +0100)]
Share i386-linux target description between GDB and GDBserver
The code on creating i386-linux target descriptions are quite similar
between GDB and GDBserver, so this patch moves them into a shared file
arch/i386.c. I didn't name it as i386-linux.c, because I want to reuse it
to create other i386 non-linux target descriptions later.
gdb:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* Makefile.in (ALL_TARGET_OBS): Add i386.o.
(SFILES): Add arch/i386.c.
(HFILES_NO_SRCDIR): Add arch/i386.h.
* arch/i386.c: New file.
* arch/i386.h: New file.
* arch/tdesc.h (allocate_target_description): Declare.
(set_tdesc_architecture): Declare.
(set_tdesc_osabi): Declare.
* configure.tgt (i[34567]86-*-linux*): Add i386.o.
* i386-linux-tdep.c: Don't include ../features/i386/32bit-XXX.c.
include arch/i386.h.
(i386_linux_read_description): Remove code and call
i386_create_target_description.
(set_tdesc_architecture): New function.
(set_tdesc_osabi): New function.
* target-descriptions.h (allocate_target_description): Remove.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* Makefile.in (arch-i386.o): New rule.
* configure.srv (i[34567]86-*-linux*): Add arch-i386.o.
(x86_64-*-linux*): Likewise.
* linux-x86-tdesc.c: Don't include ../features/i386/32bit-XXX.c,
include arch/i386.h.
(i386_linux_read_description): Remove code and call
i386_create_target_description.
* tdesc.c (allocate_target_description): New function.
* tdesc.h (set_tdesc_architecture): Remove declaration.
(set_tdesc_osabi): Likewise.
Yao Qi [Tue, 5 Sep 2017 08:54:53 +0000 (09:54 +0100)]
Dynamically composite xml in reply to GDB
GDBserver still uses pre-generated target descriptions in order to
reply to GDB's query on target description (see xml-builtin-generated.c
in GDBserver build directory). This patch teaches GDBserver to
create XML contents according to the target descriptions rather than
using pre-generated ones.
First, change target feature c files to pass the feature xml file
name to tdesc_create_feature, so that target description in GDBserver
can record them, and create XML contents from these features in
buffer, like
Note that this patch reuses target_desc.xmltarget a little bit, which is
to hold the XML contents dynamically generated in tdesc_get_features_xml.
However, it is not xfree'ed in ~target_desc, because we can't tell it is
from xstrdup or a literal string. Since we don't delete target_desc,
there is no memory leak yet. After we change all target descriptions to
the new style, target_desc.xmltarget is from xstrdup, then, we can safely
xfree it in ~target_desc.
Yao Qi [Tue, 5 Sep 2017 08:54:53 +0000 (09:54 +0100)]
[GDBserver] unit test to i386_tdesc
This patch adds a unit test in GDBserver to test dynamically created
target descriptions equal these pre-generated ones.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* linux-x86-tdesc.c: Include selftest.h.
(i386_tdesc_test): New function.
(initialize_low_tdesc): Call selftests::register_test.
* tdesc.h: Include regdef.h.
(target_desc): Override operator == and !=.
gdb:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* regformats/regdef.h (struct reg): Override operator == and !=.
Yao Qi [Tue, 5 Sep 2017 08:54:53 +0000 (09:54 +0100)]
[GDBserver] Centralize tdesc for i386-linux
tdesc_i386_XXX_linux is used in many places in linux-x86-low.c and this
patch adds a new function i386_linux_read_description to return the right
tdesc according to xcr0. i386_linux_read_description is quite similar to
the counterpart in GDB, and the following patch will share the duplicated
code, so this patch adds arch/tdesc.h includes the declarations of various
tdesc apis which are used by the shared code. The generated c feature
files can include arch/tdesc.h only.
Yao Qi [Tue, 5 Sep 2017 08:54:52 +0000 (09:54 +0100)]
Use VEC for target_desc.reg_defs
Nowadays, target_desc.reg_defs is a pointer points to a pre-generated
array, which is not flexible. This patch changes it from an array
to a VEC so that GDBserver can create target descriptions dynamically
later. Instead of using pre-generated array, the -generated.c calls
VEC_safe_push to add each register to vector.
Since target_desc.reg_defs is used in IPA, we need to build common/vec.c
for IPA too.
gdb/gdbserver:
2017-09-05 Yao Qi <yao.qi@linaro.org>
* Makefile.in (IPA_OBJS): Add vec-ipa.o
* regcache.c (get_thread_regcache): Use VEC_length.
(init_register_cache): Likewise.
(regcache_cpy): Likewise.
(registers_to_string): Iterate reg_defs via VEC_iterate.
(find_regno): Likewise.
(find_register_by_number): Use VEC_index.
(register_size): Call find_register_by_number.
(register_data): Call find_register_by_number.
(supply_regblock): Use VEC_length.
(regcache_raw_read_unsigned): Likewise.
* tdesc.c (init_target_desc): Iterate reg_defs via
VEC_iterate.
(default_description): Update initializer.
(copy_target_description): Don't update field num_registers.
* tdesc.h (struct target_desc) <reg_defs>: Change it to VEC.
<num_registers>: Remove.
Yao Qi [Tue, 5 Sep 2017 08:54:52 +0000 (09:54 +0100)]
Adjust code generated by regformats/regdat.sh
regformats/regdat.sh generate some *-generated.c files when GDBserver
is built. Each .c file has some static variables, which are only used
within function init_registers_XXX, like this,
We want GDBserver create target descriptions dynamically in each
init_registers_XXXX functions, so this patch moves all the related code
into function init_registers_XXXX, so that the following patch can easily
change function init_registers_XXXX to create target description
dynamically, rather than using current pre-generated array.
Simon Marchi [Tue, 5 Sep 2017 07:00:42 +0000 (09:00 +0200)]
expprint: Fix format string warning
My compiler (gcc 5.4.0, clang 3.8) gives this warning:
/home/emaisin/src/binutils-gdb/gdb/expprint.c: In lambda function:
/home/emaisin/src/binutils-gdb/gdb/expprint.c:1055:35: error: format not a string literal and no format arguments [-Werror=format-security]
fprintf_filtered (stream, mod);
^
Fix it by not using the passed string as the format string.
gdb/ChangeLog:
* expprint.c (dump_subexp_body_standard): Use constant format
string in fprintf_filtered call.
John Baldwin [Tue, 5 Sep 2017 02:53:50 +0000 (19:53 -0700)]
Define an error function in the PPC simulator library.
Previously this used the error function from GDB directly when linked
against GDB instead of the error method in the host callbacks
structure. This was exposed via a link error when GDB was converted
to C++. The error function invokes the error callback similar to
sim_io_error.
Note that there are also error functions in sim/ppc/main.c and
sim/ppc/misc.c. The ppc libsim.a expects each consumer to provide
several symbols used by the library including "error". sim-calls.c
provides these symbols when the library is linked into gdb. The dgen,
igen, tmp-filter, tmp-ld-decode, tmp-ld-cache, and tmp-ld-insn programs
use the functions from misc.c. psim uses the functions from main.c.
John Baldwin [Tue, 5 Sep 2017 02:34:48 +0000 (19:34 -0700)]
Enable support for x86 debug registers on NetBSD.
NetBSD recently added PT_GETDBREGS and PT_SETDBREGS ptrace operations
that match the existing ones supported by x86-bsd-nat.c. NetBSD's
headers do not provide the DBREG_DRX helper macro, so define a local
version in x86-bsd-nat.c. In addition, add the x86-nat.o and x86-dregs.o
object files to the native NetBSD x86 build targets.
gdb/ChangeLog:
* configure.nat: Add "x86-nat.o x86-dregs.o" for NetBSD/amd64 and
NetBSD/i386.
* x86-bsd-nat.c [!DBREG_DRX && __NetBSD__]: Define DBREG_DRX.