Because target_section_table only holds a vector, and because it is
used in an "open" way, this patch makes it just be an alias for the
std::vector specialization. This makes the code less wordy. If we do
ever want to add more specialized behavior to this type, it's simple
enough to convert it back to a struct with the few needed methods
implied by this change.
gdb/ChangeLog
2020-10-12 Tom Tromey <tom@tromey.com>
* target.h (struct target_ops) <get_section_table>: Update.
(target_get_section_table): Update.
* target.c (target_get_section_table, target_section_by_addr)
(memory_xfer_partial_1): Update.
* target-section.h (target_section_table): Now an alias.
* target-delegates.c: Rebuild.
* target-debug.h (target_debug_print_target_section_table_p):
Rename from target_debug_print_struct_target_section_table_p.
* symfile.c (build_section_addr_info_from_section_table): Update.
* solib.c (solib_map_sections, solib_contains_address_p): Update.
* solib-svr4.c (scan_dyntag): Update.
* solib-dsbt.c (scan_dyntag): Update.
* remote.c (remote_target::remote_xfer_live_readonly_partial):
Update.
* record-full.c (record_full_core_target::xfer_partial): Update.
* progspace.h (struct program_space) <target_sections>: Update.
* exec.h (print_section_info): Update.
* exec.c (exec_target::close, build_section_table)
(add_target_sections, add_target_sections_of_objfile)
(remove_target_sections, exec_on_vfork)
(section_table_available_memory)
(section_table_xfer_memory_partial)
(exec_target::get_section_table, exec_target::xfer_partial)
(print_section_info, set_section_command)
(exec_set_section_address, exec_target::has_memory): Update.
* corelow.c (core_target::build_file_mappings)
(core_target::xfer_partial, core_target::info_proc_mappings)
(core_target::info_proc_mappings): Update.
* bfd-target.c (class target_bfd): Update
The call to clear_section_table in ~program_space is now clearly not
needed -- the section table will clear itself. This patch removes
this call and then inlines the one remaining call to
clear_section_table.
gdb/ChangeLog
2020-10-12 Tom Tromey <tom@tromey.com>
* progspace.c (program_space::~program_space): Don't call
clear_section_table.
* exec.h (clear_section_table): Don't declare.
* exec.c (exec_target::close): Update.
(clear_section_table): Remove.
Now that target_section_table uses std::vector,
add_target_sections_of_objfile does not need to loop twice. This
patch simplifies this code to have just a single loop. Also, the
passed-in objfile can never be NULL, so this changes this function to
assert that.
gdb/ChangeLog
2020-10-12 Tom Tromey <tom@tromey.com>
* exec.c (add_target_sections_of_objfile): Simplify.
I noticed that build_section_table cannot fail. This patch changes it
to return a target_section_table and then removes the dead code.
gdb/ChangeLog
2020-10-12 Tom Tromey <tom@tromey.com>
* solib.c (solib_map_sections): Update.
* record-full.c (record_full_core_open_1): Update.
* exec.h (build_section_table): Return a target_section_table.
* exec.c (exec_file_attach): Update.
(build_section_table): Return a target_section_table.
* corelow.c (core_target::core_target): Update.
* bfd-target.c (target_bfd::target_bfd): Update.
This changes target_section_table to wrap a std::vector. This
simplifies some code, and also enables the simplifications coming in
the subsequent patches.
Note that for solib, I chose to have it use a pointer to a
target_section_table. This is more convoluted than would be ideal,
but I didn't want to convert solib to new/delete as a prerequisite for
this series.
gdb/ChangeLog
2020-10-12 Tom Tromey <tom@tromey.com>
* target.c (target_section_by_addr, memory_xfer_partial_1):
Update.
* target-section.h (struct target_section_table): Use
std::vector.
* symfile.h (build_section_addr_info_from_section_table): Take a
target_section_table.
* symfile.c (build_section_addr_info_from_section_table): Take a
target_section_table.
* solist.h (struct so_list) <sections>: Change type.
<sections_end>: Remove.
* solib.c (solib_map_sections, clear_so, solib_read_symbols)
(solib_contains_address_p): Update.
* solib-svr4.c (scan_dyntag): Update.
* solib-dsbt.c (scan_dyntag): Update.
* remote.c (remote_target::remote_xfer_live_readonly_partial):
Update.
* record-full.c (record_full_core_start, record_full_core_end):
Remove.
(record_full_core_sections): New global.
(record_full_core_open_1, record_full_core_target::xfer_partial):
Update.
* exec.h (build_section_table, section_table_xfer_memory_partial)
(add_target_sections): Take a target_section_table.
* exec.c (exec_file_attach, clear_section_table): Update.
(resize_section_table): Remove.
(build_section_table, add_target_sections): Take a
target_section_table.
(add_target_sections_of_objfile, remove_target_sections)
(exec_on_vfork): Update.
(section_table_available_memory): Take a target_section_table.
(section_table_read_available_memory): Update.
(section_table_xfer_memory_partial): Take a target_section_table.
(print_section_info, set_section_command)
(exec_set_section_address, exec_target::has_memory): Update.
* corelow.c (class core_target) <m_core_section_table,
m_core_file_mappings>: Remove braces.
<~core_target>: Remove.
(core_target::core_target): Update.
(core_target::~core_target): Remove.
(core_target::build_file_mappings)
(core_target::xfer_memory_via_mappings)
(core_target::xfer_partial, core_target::info_proc_mappings):
Update.
* bfd-target.c (target_bfd::xfer_partial): Update.
(target_bfd::target_bfd): Update.
(target_bfd::~target_bfd): Remove.
This introduces a new target-section.h file. This makes some of the
later patches in this series a bit cleaner, because new includes of
target.h won't be required. Also I think it's better to have small
header files for each separate data structure.
gdb/ChangeLog
2020-10-12 Tom Tromey <tom@tromey.com>
* target.h (struct target_section, struct target_section_table):
Move to target-section.h.
* target-section.h: New file.
Commit ccb9eba6a2 updated the testsuite for some targets without
running the testsuite on those targets. This patch corrects the
update, in most cases just adding the expected full-stop.
On powerpc64le-linux, fixes these:
FAIL: gdb.arch/powerpc-d128-regs.exp: checking for PPC arch
FAIL: gdb.arch/powerpc-disassembler-options.exp: set architecture powerpc:common64
FAIL: gdb.arch/powerpc-disassembler-options.exp: set architecture rs6000:6000
FAIL: gdb.arch/ppc64-symtab-cordic.exp: show architecture
I also verified that arm-linuxeabi and s390x-linux cross-builds now
pass their disassembler-options.exp tests.
* gdb.arch/arm-disassembler-options.exp: Adjust expected
"target architecture" output.
* gdb.arch/powerpc-d128-regs.exp: Likewise.
* gdb.arch/powerpc-disassembler-options.exp: Likewise.
* gdb.arch/ppc64-symtab-cordic.exp: Likewise.
* gdb.arch/s390-disassembler-options.exp: Likewise.
The gdb.cp/ambiguous.exp testcase had been disabled for many years,
but recently it was re-enabled. However, it is failing everywhere.
That is because it is testing an old feature that is gone from GDB.
The testcase is expecting to see an ambiguous field warning, like:
# X is derived from A1 and A2; both A1 and A2 have a member 'x'
send_gdb "print x.x\n"
gdb_expect {
-re "warning: x ambiguous; using X::A2::x. Use a cast to disambiguate.\r\n\\$\[0-9\]* = \[-\]*\[0-9\]*\r\n$gdb_prompt $" {
pass "print x.x"
}
-re "warning: x ambiguous; using X::A1::x. Use a cast to disambiguate.\r\n\\$\[0-9\]* = \[-\]*\[0-9\]*\r\n$gdb_prompt $" {
pass "print x.x"
}
-re ".*$gdb_prompt $" { fail "print x.x" }
timeout { fail "(timeout) print x.x" }
}
However, GDB just accesses one of the candidates without warning or
error:
print x.x
$1 = 1431655296
(gdb) FAIL: gdb.cp/ambiguous.exp: print x.x
(The weird number is because the testcase does not initialize the
variables.)
The testcase come in originally with the big HP merge:
+Sun Jan 10 23:44:11 1999 David Taylor <taylor@texas.cygnus.com>
+
+
+ The following files are part of the HP merge; some had longer
+ names at HP, but have been renamed to be no more than 14
+ characters in length.
Looking at the tree back then, we find that warning:
/* Helper function used by value_struct_elt to recurse through baseclasses.
Look for a field NAME in ARG1. Adjust the address of ARG1 by OFFSET bytes,
and search in it assuming it has (class) type TYPE.
If found, return value, else return NULL.
If LOOKING_FOR_BASECLASS, then instead of looking for struct fields,
look for a baseclass named NAME. */
static value_ptr
search_struct_field (name, arg1, offset, type, looking_for_baseclass)
char *name;
register value_ptr arg1;
int offset;
register struct type *type;
int looking_for_baseclass;
{
int found = 0;
char found_class[1024];
value_ptr v;
struct type *vbase = NULL;
found_class[0] = '\000';
v = search_struct_field_aux (name, arg1, offset, type, looking_for_baseclass, &found, found_class, &vbase);
if (found > 1)
warning ("%s ambiguous; using %s::%s. Use a cast to disambiguate.",
name, found_class, name);
return v;
}
However, in current GDB, search_struct_field does not handle the
ambiguous field case, nor is that warning found anywhere. Somehow it
got lost over the years. That seems like a regression, because the
compiler (as per language rules) rejects the ambiguous accesses as
well. E.g.:
gdb.cp/ambiguous.cc:98:5: error: request for member 'x' is ambiguous
98 | x.x = 1;
| ^
gdb.cp/ambiguous.cc:10:7: note: candidates are: 'int A2::x'
10 | int x;
| ^
gdb.cp/ambiguous.cc:4:7: note: 'int A1::x'
4 | int x;
| ^
This patch restores the feature, though implemented differently and
with better user experience, IMHO. An ambiguous access is now an
error instead of a warning, and also GDB shows you all the candidates,
like:
(gdb) print x.x
Request for member 'x' is ambiguous in type 'X'. Candidates are:
'int A1::x' (X -> A1)
'int A2::x' (X -> A2)
(gdb) print j.x
Request for member 'x' is ambiguous in type 'J'. Candidates are:
'int A1::x' (J -> K -> A1)
'int A1::x' (J -> L -> A1)
Users can then fix their commands by casting or by specifying the
baseclass explicitly, like:
(gdb) p x.A1::x
$1 = 1
(gdb) p x.A2::x
$2 = 2
(gdb) p ((A1) x).x
$3 = 1
(gdb) p ((A2) x).x
$4 = 2
(gdb) p j.K::x
$12 = 1
(gdb) p j.L::x
$13 = 2
(gdb) p j.A1::x
base class 'A1' is ambiguous in type 'J'
The last error I've not touched; could be improved to also list the
baseclass candidates.
The showing the class "path" for each candidate was inspired by GCC's
output when you try an ambiguous cast:
gdb.cp/ambiguous.cc:161:8: error: ambiguous conversion from derived class 'const JVA1' to base class 'const A1':
class JVA1 -> class KV -> class A1
class JVA1 -> class A1
(A1) jva1;
^~~~
I did not include the "class" word as it seemed unnecessarily
repetitive, but I can include it if people prefer it:
(gdb) print j.x
Request for member 'x' is ambiguous in type 'J'. Candidates are:
'int A1::x' (class J -> class K -> class A1)
'int A1::x' (class J -> class L -> class A1)
The testcase is adjusted accordingly. I also took the chance to
modernize it at the same time.
Also, as mentioned above, the testcase doesn't currently initialize
the tested variables. This patch inializes them all, giving each
field a distinct value, so that we can be sure that GDB is accessing
the right fields / offsets. The testcase is extended accordingly.
Unfortunately, this exposes a bug, not addressed in this patch. The
bug is around a class that inherits from A1 directly and also inherits
from two other distinct base classes that inherit virtually from A1 in
turn:
print jva1.KV::x
$51 = 1431665544
(gdb) FAIL: gdb.cp/ambiguous.exp: all fields: print jva1.KV::x
print jva1.KV::y
$52 = 21845
(gdb) FAIL: gdb.cp/ambiguous.exp: all fields: print jva1.KV::y
(gdb) print /x (KV)jva1
$4 = {<A1> = <invalid address>, _vptr.KV = 0x555555557b88 <vtable for JVA1+24>, i = 0x457}
(gdb) print /x (A1)(KV)jva1
Cannot access memory at address 0x0
Since that's an orthogonal issue, I filed PR c++/26550 and kfailed the
tests that fail because of it.
gdb/ChangeLog:
PR exp/26602
* valops.c (struct struct_field_searcher): New.
(update_search_result): Rename to ...
(struct_field_searcher::update_result): ... this. Simplify
prototype. Record all found fields.
(do_search_struct_field): Rename to ...
(struct_field_searcher::search): ... this. Simplify prototype.
Maintain stack of visited baseclass path. Call update_result for
fields too. Keep searching fields in baseclasses instead of
stopping at the first found field.
(search_struct_field): Use struct_field_searcher. When looking
for fields, report ambiguous access attempts.
gdb/testsuite/ChangeLog:
PR exp/26602
PR c++/26550
* gdb.cp/ambiguous.cc (marker1): Delete.
(main): Initialize all the fields of the locals. Replace marker1
call with a "set breakpoint here" marker.
* gdb.cp/ambiguous.exp: Modernize. Use gdb_continue_to_breakpoint
instead of running to marker1. Add tests printing all the
variables and all the fields of the variables.
(test_ambiguous): New proc, expecting the new GDB output when a
field access is ambiguous. Change all "warning: X ambiguous"
tests to use it.
A number of testcases define variables and/or functions which are
referenced by GDB during the test, but which are not referenced from
within the test executable. Clang correctly recognizes that these
variables and functions are unused, and optimizes them out, causing
the testcases in question to fail. This commit adds __attribute__
((used)) in various places to prevent this.
gdb/testsuite/ChangeLog:
* gdb.base/msym-bp.c (foo): Add __attribute__ ((used)).
* gdb.base/msym-bp-2.c (foo): Likewise.
* gdb.base/msym-lang.c (foo): Likewise.
* gdb.base/msym-lang-main.c (foo): Likewise.
* gdb.base/symtab-search-order-1.c (static_global): Likewise.
* gdb.guile/scm-pretty-print.c (eval_func): Likewise.
* gdb.mi/mi-sym-info-1.c (global_f1): Likewise.
* gdb.mi/mi-sym-info-2.c (global_f1, var1, var2): Likewise.
* gdb.multi/watchpoint-multi-exit.c (globalvar): Likewise.
* gdb.python/py-as-string.c (enum_valid, enum_invalid): Likewise.
* gdb.python/py-objfile.c (static_var): Likewise.
* gdb.python/py-symbol.c (rr): Likewise.
* gdb.python/py-symbol-2.c (anon, rr): Likewise.
* gdb.mi/mi-sym-info.exp (lineno1, lineno2): Updated.
Currently, GDB will only stop the backtrace at the main function if
there is a minimal symbol with the matching name. In Fortran programs
compiled with gfortran this is not the case. The main function is
present in the DWARF, and as marked as DW_AT_main_subprogram, but
there's no minimal symbol.
This commit extends `inside_main_func` to check the full symbols if no
matching minimal symbol is found.
There's an updated test case that covers this change.
gdb/ChangeLog:
* frame.c (inside_main_func): Check full symbols as well as
minimal symbols.
gdb/testsuite/ChangeLog:
* gdb.fortran/mixed-lang-stack.exp (run_tests): Update expected
output of backtrace.
This commit fixes the type of one of the parameters as well as a couple
of temporaries.
While at it, the function's description is slightly rewritten to make it
a little clearer what the function does.
gdb/ChangeLog:
* ada-lang.c (advance_wild_match): Rewrite the function's
description. Change the type of target0, t0 and t1 to char.
The type-safe attribute patch introduced a regression that can occur
when the DW_AT_bit_offset value is negative. This can happen with
some Ada programs.
This patch fixes the problem. It also fixes a minor oddity in the
existing scalar storage test -- this test was intended to assign a
smaller number of bits to the field.
2020-10-09 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (dwarf2_add_field): Handle signed offsets.
gdb/testsuite/ChangeLog
2020-10-09 Tom Tromey <tromey@adacore.com>
* gdb.ada/scalar_storage/storage.adb (Another_Range): New type.
(Rec): Add field. Fix range.
* gdb.ada/scalar_storage.exp: Update.
This changes ada_encode to return a std::string. This simplifies it
somewhat, removes a use of GROW_VECT, and is also simpler for callers
to use.
gdb/ChangeLog
2020-10-09 Tom Tromey <tromey@adacore.com>
* ada-lang.h (ada_encode): Return std::string.
* ada-lang.c (ada_encode_1): Return std::string.
(ada_encode): Likewise.
(type_from_tag, ada_lookup_name_info::ada_lookup_name_info):
Update.
* ada-exp.y (block_lookup, write_var_or_type): Update.
Calling non-pcrel functions from pcrel code requires a stub to set up
r2. Gold created the stub, but an "optimisation" made the stub jump
to the function local entry, ie. r2 was not initialised.
This patch fixes that long branch stub problem, and another that might
occur for plt call stubs to local functions.
bfd/
* elf64-ppc.c (write_plt_relocs_for_local_syms): Don't do local
entry offset optimisation.
gold/
* powerpc.cc (Powerpc_relobj::do_relocate_sections): Don't do
local entry offset optimisation for lplt_section.
(Target_powerpc::Branch_info::make_stub): Don't add local
entry offset to long branch dest passed to
add_long_branch_entry. Do pass st_other bits.
(Stub_table::Branch_stub_ent): Add "other_" field.
(Stub_table::add_long_branch_entry): Add "other" param, and
save.
(Stub_table::branch_stub_size): Adjust long branch offset.
(Stub_table::do_write): Likewise.
(Target_powerpc::Relocate::relocate): Likewise.
GOT relocations can refer directly to a function in a fixed position
executable, unlike ADDR64 which needs a global entry stub, or branch
relocs, which need PLT stubs.
* powerpc.cc (is_got_reloc): New function.
(Target_powerpc::Relocate::relocate): Use it here, exclude GOT
relocs when looking for stubs.
When printing void results without any format letter, they are output
as expected:
(gdb) p $abcd
$1 = void
(gdb) p (void)10
$2 = void
But if any format letter (besides s) is used, it always outputs zero:
(gdb) p/x $abcd
$3 = 0x0
(gdb) p/x (void)10
$4 = 0x0
So this adds void results to the types handled like unformatted prints.
gdb/ChangeLog:
2020-10-09 Hannes Domani <ssbssa@yahoo.de>
PR exp/26714
* printcmd.c (print_formatted): Handle void results as
unformatted prints.
gdb/testsuite/ChangeLog:
2020-10-09 Hannes Domani <ssbssa@yahoo.de>
PR exp/26714
* gdb.base/printcmds.exp: Add tests for void results.
After commit:
commit 51a948fdf0
Date: Mon Jul 20 14:18:04 2020 +0100
gdb: Have allocate_target_description return a unique_ptr
There were a few places where we could (should?) have delayed
releasing the target_desc_up until a little later. This commit
catches these cases.
In the case of ARC, the target_desc_up is now exposed right out to
gdbserver, which means making a small change there too.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* arch/aarch32.c (aarch32_create_target_description): Release the
target_desc_up as late as possible.
* arch/aarch64.c (aarch64_create_target_description): Likewise.
* arch/amd64.c (amd64_create_target_description): Likewise.
* arch/arc.c (arc_create_target_description): Return a
target_desc_up, don't release it.
* arch/arc.h (arc_create_target_description): Update declaration.
(arc_lookup_target_description): Move target_desc_up into the
cache, and return a borrowed pointer.
* arch/arm.c (arm_create_target_description): Release the
target_desc_up as late as possible.
* arch/i386.c (i386_create_target_description): Likewise.
* arch/riscv.h (riscv_create_target_description): Update
declaration to match definition.
* arch/tic6x.c (tic6x_create_target_description): Release the
target_desc_up as late as possible.
gdbserver/ChangeLog:
* linux-arc-low.cc (arc_linux_read_description): Release the
unique_ptr returned from arc_create_target_description.
An issue was reported here related to building GDB on MinGW:
https://sourceware.org/pipermail/gdb/2020-September/048927.html
It was suggested here:
https://sourceware.org/pipermail/gdb/2020-September/048931.html
that the solution might be to make use of $(LIB_GETRANDOM), a variable
defined in the gnulib makefile, when linking GDB.
In fact I think the issue is bigger than just LIB_GETRANDOM. When
using the script binutils-gdb/gnulib/update-gnulib.sh to reimport
gnulib there is a lot of output from gnulib's gnulib-tool. Part of
that output is this:
You may need to use the following makefile variables when linking.
Use them in <program>_LDADD when linking a program, or
in <library>_a_LDFLAGS or <library>_la_LDFLAGS when linking a library.
$(FREXPL_LIBM)
$(FREXP_LIBM)
$(INET_NTOP_LIB)
$(LIBTHREAD)
$(LIB_GETLOGIN)
$(LIB_GETRANDOM)
$(LIB_HARD_LOCALE)
$(LIB_MBRTOWC)
$(LIB_SETLOCALE_NULL)
$(LTLIBINTL) when linking with libtool, $(LIBINTL) otherwise
What I think this is telling us is that we should be including the
value of all these variables on the link line for gdb and gdbserver.
The problem though is that these variables are define in gnulib's
makefile, but are not (necessarily) defined in GDB's makefile.
One solution would be to recreate the checks that gnulib performs in
order to recreate these variables in both gdb's and gdbserver's
makefile. Though this shouldn't be too hard, most (if not all) of
these checks are in the form macros defined in m4 files in the gnulib
tree, so we could just reference these as needed. However, in this
commit I propose a different solution.
Currently, in the top level makefile, we give gdb and gdbserver a
dependency on gnulib. Once gnulib has finished building gdb and
gdbserver can start, these projects then have a hard coded (relative)
path to the compiled gnulib library in their makefiles.
In this commit I extend the gnulib configure script to install a new
makefile fragment in the gnulib build directory. This new file will
have the usual variable substitutions applied to it, and so can
include the complete list (see above) of all the extra libraries that
are needed when linking against gnulib.
In fact the new makefile fragment defines three variables, these are:
LIBGNU: The path to the archive containing gnulib. Can be used as a
dependency as when this file changes gdb/gdbserver should be
relinked.
LIBGNU_EXTRA_LIBS: A list of linker -l.... flags that should be
included in the link line of gdb/gdbserver. These are
libraries that $(LIBGNU) depends on. This list is taken from
the output of gnulib-tool, which is run by our
gnulib/update-gnulib.sh script.
INCGNU: A list of -I.... include paths that should be passed to the
compiler, these are where the gnulib headers can be found.
Now both gdb and gdbserver can include the makefile fragment and make
use of these variables.
The makefile fragment relies on the variable GNULIB_BUILDDIR being
defined. This is checked for in the fragment, and was already defined
in the makefiles of gdb and gdbserver.
gdb/ChangeLog:
* Makefile.in: Include Makefile.gnulib.inc. Don't define LIBGNU
or INCGNU. Make use of LIBGNU_EXTRA_LIBS when linking.
gdbserver/ChangeLog:
* Makefile.in: Include Makefile.gnulib.inc. Don't define LIBGNU
or INCGNU. Make use of LIBGNU_EXTRA_LIBS when linking.
gnulib/ChangeLog:
* Makefile.gnulib.inc.in: New file.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Install the new file.
gdb/ChangeLog
* source.c (directory_command): Notify observers that "directories"
parameter has changed.
gdb/testsuite/ChangeLog
* gdb.mi/mi-cmd-param-changed.exp: Check that notification is
is emmited for both 'set directories' and 'directory' commands.
I noticed a couple of spots where the "disassemble" could style its
output, but currently does not. This patch adds styling to the
function name at the start of the disassembly, and any addresses
printed there.
gdb/ChangeLog
2020-10-08 Tom Tromey <tom@tromey.com>
* cli/cli-cmds.c (print_disassembly): Style function name and
addresses. Add _() wrappers.
gdb/testsuite/ChangeLog
2020-10-08 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Check that "main"'s name is styled.
For functions with small (< 256 bytes) stack frames, the current x86
do_calls_non_split ignores --split-stack-adjust-size and, in
combination with __morestack_non_split, supplies a non-split-stack
function with at least 0x100000 (1M) available stack. On powerpc64, a
default of 0x4000 is not large enough to reliably work with the golang
testsuite. This increase the default size to the defacto x86 value.
* options.h (split_stack_adjust_size): Default to 0x100000.
Update property tests for glibc compiled by Fedora binary annotation
plugin for GCC, which may insert additonal GNU properties:
x86 ISA needed: SSE, SSE2
* testsuite/ld-i386/property-3.r: Updated for Fedora binary
annotation plugin for GCC.
* testsuite/ld-i386/property-4.r: Likewise.
* testsuite/ld-i386/property-5.r: Likewise.
* testsuite/ld-x86-64/property-3.r: Likewise.
* testsuite/ld-x86-64/property-4.r: Likewise.
* testsuite/ld-x86-64/property-5.r: Likewise.
This adds some unit tests for simple_search_memory. I tried here to
reproduce some bugs (PR gdb/11158 and PR gdb/17756), but was unable
to.
gdb/ChangeLog
2020-10-07 Tom Tromey <tromey@adacore.com>
* unittests/search-memory-selftests.c: New file.
* Makefile.in (SELFTESTS_SRCS): Add
unittests/search-memory-selftests.c.
PR gdb/16930 points out that the "find" command uses an inclusive
range; but this is not documented in the "help". This patch updates
the help text.
gdb/ChangeLog
2020-10-07 Tom Tromey <tromey@adacore.com>
PR gdb/16930:
* findcmd.c (_initialize_mem_search): Mention that the range is
inclusive.
handle_search_memory had some code after a call to error. This code
is dead, and this patch removes it.
gdbserver/ChangeLog
2020-10-07 Tom Tromey <tromey@adacore.com>
* server.cc (handle_search_memory): Remove dead code.
This replaces gdbserver's memory-searching function with
simple_search_memory.
gdbserver/ChangeLog
2020-10-07 Tom Tromey <tromey@adacore.com>
* server.cc (handle_search_memory_1): Remove.
(handle_search_memory): Use simple_search_memory.
This moves the simple_search_memory function to a new file,
gdbsupport/search.cc. The API is slightly changed to make it more
general. This generality is useful for wiring it to gdbserver, and
also for unit testing.
gdb/ChangeLog
2020-10-07 Tom Tromey <tromey@adacore.com>
* target.h (simple_search_memory): Don't declare.
* target.c (simple_search_memory): Move to gdbsupport.
(default_search_memory): Update.
* remote.c (remote_target::search_memory): Update.
gdbsupport/ChangeLog
2020-10-07 Tom Tromey <tromey@adacore.com>
* Makefile.in: Rebuild.
* Makefile.am (libgdbsupport_a_SOURCES): Add search.cc.
* search.h: New file.
* search.cc: New file.
This renames some tests in find.exp, to avoid duplicate test names.
gdb/testsuite/ChangeLog
2020-10-07 Tom Tromey <tromey@adacore.com>
* gdb.base/find.exp: Rename some tests.
GDB currently doesn't build cleanly with clang (a -Wdeprecated-copy-dtor
error). I configured my clang-based GDB build with
CXXFLAGS="-Wno-error=deprecated-copy-dtor", so I can use it despite that
problem. However, I found that it had no effect. This is because my
-Wno-error=Wdeprecated-copy-dtor switch is followed by -Werror in the
command line, which switches back all warnings to be errors.
If we want the user-supplied C(XX)FLAGS to be able to override flags
added by our configure script, the user-supplied C(XX)FLAGS should
appear after the configure-supplied flags.
This patch moves the user-supplied CXXFLAGS at the very end of the
compilation command line, which fixes the problem described above. This
means moving it out of INTERNAL_CFLAGS and inlining it in the users of
INTERNAL_CFLAGS.
I observed the problem when building GDB, but the same problem could
happen with GDBserver, so the change is done there too.
In GDBserver, INTERNAL_CFLAGS is passed when linking
gdb/ChangeLog:
* Makefile.in (COMPILE): Add CXXFLAGS.
(INTERNAL_CFLAGS_BASE): Remove CXXFLAGS.
(check-headers): Add CXXFLAGS.
gdbserver/ChangeLog:
* Makefile.in (COMPILE): Add CXXFLAGS.
(INTERNAL_CFLAGS_BASE): Remove CXXFLAGS.
(gdbserver$(EXEEXT)): Add CXXFLAGS.
(gdbreplay$(EXEEXT)): Add CXXFLAGS.
($(IPA_LIB)): Add CXXFLAGS.
(IPAGENT_COMPILE): Add CXXFLAGS.
Change-Id: I00e054506695e0e9536095c6d14827e48abd8f69
The support is on par with NetBSD/amd64, thus GPR works,
single step and software breakpoint are operational, and the
SVR4 r_debug integration is functional.
gdbserver/ChangeLog:
* netbsd-aarch64-low.cc: Add.
* Makefile.in (SFILES): Register "netbsd-aarch64-low.c".
* configure.srv: Add aarch64*-*-netbsd*.
Becausae of a copy/paste, I've put myself as the author of the
following patch which was not true:
6d2d7c5668 gdbserver: Add GNU/Linux support for ARC
This change will place the correct date and author in the ChangeLog.
With the implemenations in this patch, ARC gdb can handle
coredump related matters. The binutils counter part of
this patch has already been pushed [1].
v2 [2]:
- arc_linux_collect_gregset: Use "reg <= ARC_LAST_REGNUM" instead of
"reg < ARC_LAST_REGNUM" for the condition check of the for-loop.
- arc-linux-tdep.c: Use "ARC_LAST_REGNUM < ARRAY_SIZE (...)" instead of
"ARC_LAST_REGNUM <= ARRAY_SIZE (...)" for the "asserts".
- Use "buf + arc_linux_core_reg_offsets[ARC_ERET_REGNUM]" instead of
"buf + REG_OFF (6)".
- Fix a few typos/indentation.
v3 [3]:
- Use gdb_assert_not_reached(text) instead of gdb_assert (!text).
- Remove unnecessary braces in the for loop.
[1] arc: Add support for ARC HS extra registers in core files
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2745674244d6aecddcf636475034bdb9c0a6b4a0
[2] First remarks
https://sourceware.org/pipermail/gdb-patches/2020-September/171912.html
[3] Second remarks
https://sourceware.org/pipermail/gdb-patches/2020-October/172302.html
gdb/ChangeLog:
* arc-linux-tdep.h: New file.
* arc-linux-tdep.c (arc_linux_core_reg_offsets,
arc_linux_supply_gregset, arc_linux_supply_v2_regset,
arc_linux_collect_gregset, arc_linux_collect_v2_regset,
arc_linux_gregset, arc_linux_v2_regset,
arc_linux_iterate_over_regset_sections,
arc_linux_core_read_description): Implement.
(arc_linux_init_osabi): Set iterate_over_regset_sections.
* arc-tdep.h (ARC_OFFSET_NO_REGISTER): Declare.
(arc_gdbarch_features_create): Add.
* arc-tdep.c (arc_gdbarch_features_create): Not static anymore.
This gdbserver implementation supports ARC ABI v3 and v4 (older ARC ABI
versions are not supported by other modern GNU tools or Linux itself).
Gdbserver supports inspection of ARC HS registers R30, R58 and R59 - feature
that has been added to Linux 4.12. Whether gdbserver build will actually
support this feature depends on the version of Linux headers used to build
the server.
v2 [1]:
- Use "this->read_memory ()" instead of "the_target->read_memory ()".
- Remove the unnecessary "arch-arc.o:" target from the "Makefile.in".
- Got rid of "ntohs()" function and added lots of comments about
endianness.
- Clarify why "pc" value is read from and saved to different fields
in user regs struct.
- In function "is_reg_name_available_p()", use a range-based iterator
to loop over the registers.
- Removed mentioning of issue number that was not related to sourceware.
- A few typo's fixed.
[1] Remarks
https://sourceware.org/pipermail/gdb-patches/2020-September/171911.htmlhttps://sourceware.org/pipermail/gdb-patches/2020-September/171919.html
gdbserver/ChangeLog:
* configure.srv: Support ARC architecture.
* Makefile.in: Add linux-arc-low.cc and arch/arc.o.
* linux-arc-low.cc: New file.
"arc_gdbarch_features" is a data structure containing information
about the ARC architecture: ISA version, register size, etc.
This name is misleading, because although it carries the phrase
"gdbarch", it has nothing to do with the type/interface in GDB.
Traditionaly, "gdbarch" structures are only used for that purpose.
To rectify this, this patch changes the name to "arc_arch_features".
gdb/ChangeLog:
* arch/arc.h: Rename "arc_gdbarch_features" to
"arc_arch_features".
* arc-tdep.h: Likewise.
* arc-tdep.c: Likewise.
Switch from target->read_memory to netbsd_nat::read_memory and
cleanup the code.
No functional change.
gdbserver/ChangeLog:
* netbsd-low.cc (get_dynamic, get_r_debug, read_one_ptr)
(netbsd_qxfer_libraries_svr4): Remove "target" argument and update.
(netbsd_process_target::qxfer_libraries_svr4): Update.
In `attach_command`, there is a call to `init_wait_for_inferior`
followed by a call to `clear_proceed_status`. However,
`init_wait_for_inferior` already calls `clear_proceed_status`. Remove
the redundant call.
Regression-tested on X86_64 Linux.
gdb/ChangeLog:
2020-10-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infcmd.c (attach_command): Remove the redundant call to
`clear_proceed_status`.
In case of repeated ptrace PT_IO call and returning the value of
transferred bytes equal to 0, do not return without setting
xfered_len.
gdb/ChangeLog:
* nat/netbsd-nat.c (write_memory, read_memory): Update.
