| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When --gc-sections is in effect, a reference from a retained section
to __start_SECNAME or __stop_SECNAME causes all input sections named
SECNAME to also be retained, if SECNAME is representable as a C
identifier and either __start_SECNAME or __stop_SECNAME is synthesized
by the linker. Add an option to disable that feature, effectively
ignoring any relocation that references a synthesized linker defined
__start_ or __stop_ symbol.
PR 27451
include/
* bfdlink.h (struct bfd_link_info): Add start_stop_gc.
bfd/
* elflink.c (_bfd_elf_gc_mark_rsec): Ignore synthesized linker
defined start/stop symbols when start_stop_gc.
(bfd_elf_gc_mark_dynamic_ref_symbol): Likewise.
(bfd_elf_define_start_stop): Don't modify ldscript_def syms.
* linker.c (bfd_generic_define_start_stop): Likewise.
ld/
* emultempl/elf.em: Handle -z start-stop-gc and -z nostart-stop-gc.
* lexsup.c (elf_static_list_options): Display help for them. Move
help for -z stack-size to here from elf_shlib_list_options. Add
help for -z start-stop-visibility and -z undefs.
* ld.texi: Document -z start-stop-gc and -z nostart-stop-gc.
* NEWS: Mention -z start-stop-gc.
* testsuite/ld-gc/start2.s,
* testsuite/ld-gc/start2.d: New test.
* testsuite/ld-gc/gc.exp: Run it.
|
|
If a weak reference to a __start_foo or __stop_foo symbol ends up
having no definition due to all the foo sections being removed for
some reason, undef_start_stop currently makes the symbol strong
undefined. That risks a linker undefined symbol error. Fix that by
making the symbol undefweak and also undo some dynamic symbol state.
Note that saving the state of the symbol type at the time
lang_init_start_stop runs is not sufficient. The linker may have
merged in a shared library reference by that point and made what was
an undefweak in regular objects, a strong undefined. So it is
necessary to look at the ELF symbol flags to decide whether an
undefweak is the proper resolution.
Something probably should be done for COFF/PE too, but I'm unsure how
to do go about that.
* ldlang.c (undef_start_stop): For ELF make undefined start/stop
symbols undefweak if that was how they were referenced. Undo
dynamic state too.
|
|
Add nm --without-symbol-versions.
binutils/
PR 27128
* doc/binutils.texi: Add nm --with-symbol-versions and
--without-symbol-versions documentation.
* nm.c (with_symbol_versions): New variable.
(enum long_option_values): Delete OPTION_WITH_SYMBOL_VERSIONS.
(long_options): Make --with-symbol-versions entry twiddle the flag.
Add --without-symbol-versions.
(print_symname): Strip version when !with_symbol_versions. Add
dynamic version info under control of with_symbol_versions.
(main): Remove OPTION_WITH_SYMBOL_VERSIONS case.
ld/
* testsuite/ld-elf/pr25708.d: Add --with-symbol-versions to nm.
* testsuite/ld-elf/pr27128a.d: Likewise.
* testsuite/ld-elf/pr27128b.d: Likewise.
* testsuite/ld-elf/pr27128c.d: Likewise.
* testsuite/ld-elf/pr27128d.d: Likewise.
* testsuite/ld-elf/pr27128e.d: Likewise.
|
|
|
|
Update Makefile.tpl to add missing changes in
commit af019bfde9b13d628202fe58054ec7ff08d92a0f
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Sat Jan 9 06:51:15 2021 -0800
Support the PGO build for binutils+gdb
"autogen Makefile.def" showed no changes in Makefile.in.
PR binutils/26766
* Makefile.tpl (PGO_BUILD_TRAINING_FLAGS_TO_PASS): Add
PGO_BUILD_TRAINING=yes.
(PGO_BUILD_TRAINING_MFLAGS): New.
(all): Pass $(PGO_BUILD_TRAINING_MFLAGS) to the PGO build.
|
|
While the configure script was checking for a bunch of headers, only
one of them was conditionally included in the source (unistd.h). The
rest were always included. Based on those usage this whole time, we
can reasonably assume that the build also has unistd.h.
All the other files including config.h never actually used any defines
from the header.
|
|
This package doesn't build any archives or install programs.
|
|
|
|
Some sim dirs were already setting up CFLAGS_FOR_BUILD in inconsistent
ways. Move it to a common place for reuse.
|
|
Rather than require $AR be set and then default to `ar`, use the
standard AC_CHECK_TOOL helper to find a good prefixed tool. In
practice this shouldn't change much as we seem to have macros in
the tree that were already setting it up, but we shouldn't rely
on that implicitly.
|
|
All the scripts were using this implicitly already, so there's no real
change for them, but we want to call it explicitly as the CPP tool is
used to generate nltvals.def.
|
|
This was last used 15 years ago, so clearly not important enough to
keep around. Punt it.
|
|
We don't need a variable to add a dependency to the "all" target, and
having one doesn't really add value. Switch to the target directly for
the few ports that actually use this.
|
|
|
|
As reported in gdb/27393, the 'directory' and 'set directories' commands
fail when parsing an empty dir name:
(gdb) set directories ""
/home/lsix/dev/gnu/binutils-gdb/gdbsupport/pathstuff.cc:132: internal-error: gdb::unique_xmalloc_ptr<char> gdb_abspath(const char*): Assertion `path != NULL && path[0] != '\0'' failed.
or
(gdb) dir :
/home/lsix/dev/gnu/binutils-gdb/gdbsupport/pathstuff.cc:132: internal-error: gdb::unique_xmalloc_ptr<char> gdb_abspath(const char*): Assertion `path != NULL && path[0] != '\0'' failed.
This patch fixes this issue by ignoring any attempt to add an empty
name to the source directories list. 'set dir ""' will reset the
directories list the same way 'set dir' would do it.
Tested on x86_64.
|
|
I noticed an oddity in skip_ctf_tests -- for me it ends up caching the
string "!0", because it ends with 'return ![...]'. In Tcl, this is
just string concatenation.
The result works because the users of this function have unbraced if
conditions, like:
if [skip_ctf_tests] {
... which works because "if" re-parses the returned string as an
expression, and evaluates that.
There's only a latent bug here, but this is also un-idiomatic, so I am
checking in this patch to fix it. This way, if someone in the future
uses a braced condition (which is what I normally recommend), it will
continue to work.
gdb/testsuite/ChangeLog
2021-02-26 Tom Tromey <tom@tromey.com>
* lib/gdb.exp (skip_ctf_tests): Use expr on result.
|
|
|
|
PR binutils/27408
* readelf.c (quiet): New option flag.
(enum long_option_values): New enum to hold long option value.
(long_options): Add --quiet.
(usage): Mention --quiet.
(display_rel_file): If quiet is enabled, suppress "no symbols".
(main): Handle the new option.
* NEWS: Mention --quiet.
* docs/binutils.texi: Document --quiet.
|
|
PR 27411
* config/tc-arm.c (do_t_add_sub): Correct error message.
* testsuite/gas/arm/pr27411.s: New test.
* testsuite/gas/arm/pr27411.d: New test driver.
* testsuite/gas/arm/pr27411.l: Expected error output for new test.
|
|
* dwarf.c (display_debug_addr): Handle dwarf-5 .debug_addr bits.
|
|
Commit 2450ad54 removed extra trailing \n from tsv notifications but
did not update gdb.trace/mi-tsv-changed.exp accordingly. This commit
removes the extra \n from expected output so gdb.trace/mi-tsv-changed.exp
passes again.
gdb/testsuite/ChangeLog:
* gdb.trace/mi-tsv-changed.exp (test_create_delete_modify_tsv):
Remove trailing \n from expected output.
|
|
PR 27390
* dwarf.c: (skip_attr_bytes): Add support for DW_FORM_str* and
DW_FORM_addrx*.
(read_and_display_attr_value): Likewise.
|
|
Add a note to the comment on use_gdb_stub explaining the use of this check
for skipping tests that spawn new inferiors as discussed here:
https://sourceware.org/pipermail/gdb-patches/2020-December/174186.html
|
|
PR 27441
* testsuite/ld-plugin/pr27441a.c,
* testsuite/ld-plugin/pr27441b.c,
* testsuite/ld-plugin/pr27441c.c,
* testsuite/ld-plugin/pr27441c.d: New test.
* testsuite/ld-plugin/lto.exp: Run it.
|
|
The previous regen was done on a tree without the new NEWS file.
* Makefile.in: Regenerate.
|
|
|
|
|
|
I added the same comment for nat/aarch64-linux-hw-point.c yesterday.
Christian suggested adding the comment for the other file that I had
identified as including both <sys/ptrace.h> and <asm/ptrace.h>.
I searched the sources in gdb/, but found no other files which include
both of these headers.
If possible, I would prefer to see us use <sys/ptrace.h> when possible,
however, from past experience, I've found that this file does not always
contain all of the constants, etc. required by the particular source
file.
gdb/ChangeLog:
* nat/aarch64-sve-linux-ptrace.h: Add comment regarding include
order for <sys/ptrace.h> and <asm/ptrace.h>.
|
|
As reported in PR 26861, when killing an inferior on macOS, we hit the
assert:
../../gdb-10.1/gdb/target.c:2149: internal-error: void target_mourn_inferior(ptid_t): Assertion `ptid == inferior_ptid' failed.
This is because darwin_nat_target::kill passes a pid-only ptid to
target_mourn_inferior, with the pid of the current inferior:
target_mourn_inferior (ptid_t (inf->pid));
... which doesn't satisfy the assert in target_mourn_inferior:
gdb_assert (ptid == inferior_ptid);
The reason for this assertion is that target_mourn_inferior is a
prototype shared between GDB and GDBserver, so that shared code in
gdb/nat (used in both GDB and GDBserver) can call target_mourn_inferior.
In GDB's implementation, it is likely that some targets still rely on
inferior_ptid being set to "the current thread we are working on". So
until targets are completely decoupled from inferior_ptid (at least
their mourn_inferior implementations), we need to ensure the passed in
ptid matches inferior_ptid, to ensure the calling code called
target_mourn_inferior with the right global context.
However, I think the assert is a bit too restrictive. The
mourn_inferior operation works on an inferior, not a specific thread.
And by the time we call mourn_inferior, the threads of the inferior
don't exist anymore, the process is gone, so it doesn't really make
sense to require inferior_ptid to point a specific thread.
I looked at all the target_ops::mourn_inferior implementations, those
that read inferior_ptid only care about the pid field, which supports
the idea that only the inferior matters. Other implementations look at
the current inferior (call `current_inferior ()`).
I think it would make sense to change target_mourn_inferior to accept
only a pid rather than a ptid. It would then assert that the pid is the
same as the current inferior's pid. However, this would be a quite
involved change, so I'll keep it for later.
To fix the macOS issue immediately, I propose to relax the assert to
only compare the pids, as is done in this patch.
Another solution would obviously be to make darwin_nat_target::kill pass
inferior_ptid to target_mourn_inferior. However, the solution I propose
is more in line with where I think we want to go (passing a pid to
target_mourn_inferior).
gdb/ChangeLog:
PR gdb/26861
* target.c (target_mourn_inferior): Only compare pids in
target_mourn_inferior.
Change-Id: If2439ccc5aa67272ea16148a43c5362ef23fb2b8
|
|
This change fixes the initial state of the main thread of remote
targets which have no concept of threading. Such targets are
treated as single-threaded by gdb, and this single thread needs
to be initially set to the "resumed" state, in the same manner as
threads in thread-aware remote targets (see remote.c,
remote_target::remote_add_thread).
Without this fix, the following assert was triggered on thread-
unaware remote targets:
remote_target::select_thread_for_ambiguous_stop_reply(const target_waitstatus*): Assertion `first_resumed_thread != nullptr' failed.
The bug can be reproduced using gdbserver
* by disabling packets 'T' and 'qThreadInfo', or
* by disabling all thread-related packets.
The test suite has been updated to include these two scenarios, see
gdb.server/stop-reply-no-thread.exp.
Change-Id: I2c39c9de17e8d6922a8c1b9e259eb316a554a43d
|
|
* dwarf.c (get_type_abbrev_from_form): Accept but ignore sup
forms.
(read_and_display_attr_value): Handle sup forms.
(display_debug_sup): New function. Displays the contents of a
.debug_sup section.
(load_debug_sup_file): New function. Loads the contents of a file
referenced by a .debug_sup section.
(check_for_and_load_links): Call load_debug_sup_file.
(debug_displays): Add entry for .debug_sup.
* dwarf.h (enum dwarf_section_display_enum): Add debug_sup.
* readelf.c (process_section_headers): Add support for debug_sup.
* doc/debug.options.texi: Note that the =links option will display
the contents of .debug_sup sections.
* NEWS: Mention the new support.
|
|
In commit:
commit faeb9f13c179a4c78bc295a0d0bbd788239704d9
Date: Wed Feb 24 12:50:00 2021 +0000
gdb/fortran: add support for ASSOCIATED builtin
A test was added that fails to process the trailing gdb prompt inside
a gdb_test_multiple call, this will cause a failure if the tests are
run with READ1=1, or randomly at other times depending on how the
expect buffers are read in.
Fixed by adding a -wrap argument.
gdb/testsuite/ChangeLog:
* gdb.fortran/associated.exp: Add missing '-wrap' argument.
|
|
An extra \n in calls to fprintf_unfiltered() caused invalid MI records
to be emitted:
> gdb -i mi3 -ex "target remote :7000"
=thread-group-added,id="i1"
~"GNU gdb (GDB) 11.0.50.20201019-git\n"
~"Copyright (C) 2020 Free Software Foundation, Inc.\n"
...
~"Remote debugging using :7001\n"
=tsv-created,name="trace_timestamp",initial="0"\n
=thread-group-started,id="i1",pid="304973"
This commit fixes the problem.
gdb/ChangeLog:
* gdb/mi/mi-interp.c (mi_traceframe_changed): Remove trailing \n from output.
(mi_tsv_created): Likewise.
(mi_tsv_deleted): Likewise.
|
|
When running test-case gdb.dwarf2/fission-mix.exp using gcc-11 (and using the
tentative fix for PR27353 to get past that assertion failure), I run into:
...
(gdb) file fission-mix^M
Reading symbols from fission-mix...^M
Dwarf Error: wrong unit_type in compilation unit header \
(is DW_UT_split_compile (0x05), should be DW_UT_type (0x02)) \
[in module fission-mix2.dwo]^M
(No debugging symbols found in fission-mix)^M
...
The compilation unit that is complained about is:
...
Contents of the .debug_info.dwo section (loaded from fission-mix2.dwo):
Compilation Unit @ offset 0x0:
Length: 0x57 (32-bit)
Version: 5
Unit Type: DW_UT_split_compile (5)
Abbrev Offset: 0x0
Pointer Size: 8
DWO ID: 0x3e3930d3cc1805df
<0><14>: Abbrev Number: 1 (DW_TAG_compile_unit)
...
And the dwarf error is triggered here in read_comp_unit_head:
...
case DW_UT_split_compile:
if (section_kind != rcuh_kind::COMPILE)
error (_("Dwarf Error: wrong unit_type in compilation unit header "
"(is %s, should be %s) [in module %s]"),
dwarf_unit_type_name (cu_header->unit_type),
dwarf_unit_type_name (DW_UT_type), filename);
break;
...
due to passing rcuh_kind::TYPE here in open_and_init_dwo_file:
...
create_debug_type_hash_table (per_objfile, dwo_file.get (),
&dwo_file->sections.info, dwo_file->tus,
rcuh_kind::TYPE);
...
Fix this by changing the section_kind argument to create_debug_type_hash_table
to rcuh_kind::COMPILE, to reflect that we're passing &dwo_file->sections.info
rather than &dwo_file->sections.types.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-02-25 Tom de Vries <tdevries@suse.de>
PR symtab/27354
* dwarf2/read.c (open_and_init_dwo_file): Use rcuh_kind::COMPILE as
section_kind for &dwo_file->sections.info.
|
|
Prior to 89753bbf8102 ("Warn when a script redefines a symbol") there
was no diagnostic at all. As of that commit, it's a warning, not an
error.
|
|
When attempting to call a Fortran function for which there is no debug
information we currently trigger undefined behaviour in GDB by
accessing non-existent type fields.
The reason is that in order to prepare the arguments, for a call to a
Fortran function, we need to know the type of each argument. If the
function being called has no debug information then obviously GDB
doesn't know about the argument types and we should either give the
user an error or pick a suitable default. What we currently do is
just assume the field exist and access undefined memory, which is
clearly wrong.
The reason GDB needs to know the argument type is to tell if the
argument is artificial or not, artificial arguments will be passed by
value while non-artificial arguments will be passed by reference.
An ideal solution for this problem would be to allow the user to cast
the function to the correct type, we already do this to some degree
with the return value, for example:
(gdb) print some_func_ ()
'some_func_' has unknown return type; cast the call to its declared return type
(gdb) print (integer) some_func_ ()
$1 = 1
But if we could extend this to allow casting to the full function
type, GDB could figure out from the signature what are real
parameters, and what are artificial parameters. Maybe something like
this:
(gdb) print ((integer () (integer, double)) some_other_func_ (1, 2.3)
Alas, right now the Fortran expression parser doesn't seem to support
parsing function signatures, and we certainly don't have support for
figuring out real vs artificial arguments from a signature.
Still, I think we can prevent GDB from accessing undefined memory and
provide a reasonable default behaviour.
In this commit I:
- Only ask if the argument is artificial if the type of the argument
is actually known.
- Unknown arguments are assumed to be artificial and passed by
value (non-artificial arguments are pass by reference).
- If an artificial argument is prefixed with '&' by the user then we
treat the argument as pass-by-reference.
With these three changes we avoid undefined behaviour in GDB, and
allow the user, in most cases, to get a reasonably natural default
behaviour.
gdb/ChangeLog:
PR fortran/26155
* f-lang.c (fortran_argument_convert): Delete declaration.
(fortran_prepare_argument): New function.
(evaluate_subexp_f): Move logic to new function
fortran_prepare_argument.
gdb/testsuite/ChangeLog:
PR fortran/26155
* gdb.fortran/call-no-debug-func.f90: New file.
* gdb.fortran/call-no-debug-prog.f90: New file.
* gdb.fortran/call-no-debug.exp: New file.
|
|
This commit adds support for the ASSOCIATED builtin to the Fortran
expression evaluator. The ASSOCIATED builtin takes one or two
arguments.
When passed a single pointer argument GDB returns a boolean indicating
if the pointer is associated with anything.
When passed two arguments the second argument should either be some a
pointer could point at or a second pointer.
If the second argument is a pointer target, then the result from
associated indicates if the pointer is pointing at this target.
If the second argument is another pointer, then the result from
associated indicates if the two pointers are pointing at the same
thing.
gdb/ChangeLog:
* f-exp.y (f77_keywords): Add 'associated'.
* f-lang.c (fortran_associated): New function.
(evaluate_subexp_f): Handle FORTRAN_ASSOCIATED.
(operator_length_f): Likewise.
(print_unop_or_binop_subexp_f): New function.
(print_subexp_f): Make use of print_unop_or_binop_subexp_f for
FORTRAN_ASSOCIATED, FORTRAN_LBOUND, and FORTRAN_UBOUND.
(dump_subexp_body_f): Handle FORTRAN_ASSOCIATED.
(operator_check_f): Likewise.
* std-operator.def: Add FORTRAN_ASSOCIATED.
gdb/testsuite/ChangeLog:
* gdb.fortran/associated.exp: New file.
* gdb.fortran/associated.f90: New file.
|
|
gfortran supports .xor. as an alias for .neqv., see:
https://gcc.gnu.org/onlinedocs/gfortran/_002eXOR_002e-operator.html
this commit adds support for this operator to GDB.
gdb/ChangeLog:
* f-exp.y (fortran_operators): Add ".xor.".
gdb/testsuite/ChangeLog:
* gdb.fortran/dot-ops.exp (dot_operations): Test ".xor.".
|
|
This makes IR objects use the same logic as normal objects with
respect to what sort of ref/def makes an as-needed library needed.
Testing the binding of the definition is just plain wrong. What
matters is the binding of the reference.
PR 27441
* elf-bfd.h (struct elf_link_hash_entry): Add ref_ir_nonweak.
* elflink.c (elf_link_add_object_symbols): Set ref_ir_nonweak and
use when deciding an as-needed library should be loaded instead
of using the binding of the library definition.
|
|
|
|
PR 27456
* rename.c (simple_copy): Mark target_stat ATTRIBUTE_UNUSED.
|
|
With test-case gdb.cp/temargs.exp on target board \
unix/gdb:debug_flags=-gdwarf-5 I run into:
...
(gdb) info addr I^M
ERROR: GDB process no longer exists
GDB process exited with wait status 32286 exp19 0 0 CHILDKILLED SIGABRT SIGABRT
UNRESOLVED: gdb.cp/temargs.exp: test address of I in templ_m
...
This is a regression since commit 529908cbd0a "Remove DW_UNSND".
The problem is that this DW_AT_decl_file:
...
<1><221>: Abbrev Number: 4 (DW_TAG_structure_type)
<222> DW_AT_name : Base<double, 23, (& a_global), &S::f>
<226> DW_AT_byte_size : 1
<226> DW_AT_decl_file : 1
<226> DW_AT_decl_line : 30
<227> DW_AT_sibling : <0x299>
...
is not read by this code in new_symbol:
....
attr = dwarf2_attr (die,
inlined_func ? DW_AT_call_file : DW_AT_decl_file,
cu);
if (attr != nullptr && attr->form_is_unsigned ())
...
because DW_AT_decl_file has form DW_FORM_implicit_const:
...
4 DW_TAG_structure_type [has children]
DW_AT_name DW_FORM_strp
DW_AT_byte_size DW_FORM_implicit_const: 1
DW_AT_decl_file DW_FORM_implicit_const: 1
DW_AT_decl_line DW_FORM_data1
DW_AT_sibling DW_FORM_ref4
DW_AT value: 0 DW_FORM value: 0
...
which is a signed LEB128, so attr->form_is_unsigned () returns false.
Fix this by introducing new functions is_nonnegative and as_nonnegative, and
use these instead of form_is_unsigned and as_unsigned.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-02-24 Tom de Vries <tdevries@suse.de>
PR symtab/27336
* dwarf2/attribute.c (attribute::form_is_signed): New function
factored out of ...
* dwarf2/attribute.h (attribute::as_signed): ... here.
(attribute::is_nonnegative, attribute::as_nonnegative): New function.
(attribute::form_is_signed): Declare.
* dwarf2/read.c (new_symbol): Use is_nonnegative and as_nonnegative
for DW_AT_decl_file.
|
|
gdb/ChangeLog:
* nat/aarch64-linux-hw-point.c: Add comment regarding include
order for <sys/ptrace.h> and <asm/ptrace.h>.
|
|
Due to a recent glibc header file change, the file
nat/aarch64-linux-hw-point.c no longer builds on Fedora rawhide.
An enum for PTRACE_SYSEMU is now provided by <sys/ptrace.h>. In the
past, PTRACE_SYSEMU was defined only in <asm/ptrace.h>. This is
what it looks like...
In <asm/ptrace.h>:
#define PTRACE_SYSEMU 31
In <sys/ptrace.h>:
enum __ptrace_request
{
...
PTRACE_SYSEMU = 31,
#define PT_SYSEMU PTRACE_SYSEMU
...
}
When <asm/ptrace.h> and <sys/ptrace.h> are both included in a source
file, we run into the following build problem when the former is
included before the latter:
In file included from nat/aarch64-linux-hw-point.c:26:
/usr/include/sys/ptrace.h:86:3: error: expected identifier before numeric constant
86 | PTRACE_SYSEMU = 31,
| ^~~~~~~~~~~~~
(There are more errors after this one too.)
The file builds without error when <asm/ptrace.h> is included after
<sys/ptrace.h>. I found that this is already done in
nat/aarch64-sve-linux-ptrace.h (which is included by
nat/aarch64-linux-ptrace.c).
I've tested this change on Fedora rawhide and Fedora 33, both
running on an aarch64 machine.
gdb/ChangeLog:
* nat/aarch64-linux-hw-point.c: Include <asm/ptrace.h> after
<sys/ptrace.h>.
|
|
The 'section' command uses a fixed size buffer into which a section
name is copied. This commit replaces this with a use of std::string
so we can now display very long section names.
The expected results of one test need to be updated.
gdb/ChangeLog:
* exec.c (set_section_command): Move variable declarations into
the function body, and use std::string instead of a fixed size
buffer.
gdb/testsuite/ChangeLog:
* gdb.base/sect-cmd.exp: Update expected results.
|
|
The only target that implements target_ops::get_section_table in a
meaningful way is exec_target. This target calls back into the
program space to return the current global section_table.
The global section table is populated whenever the user provides GDB
with an executable, or when a symbol file is loaded, e.g. when a
dynamic library is loaded, or when the user does add-symbol-file.
I recently ran into a situation where a user, debugging a remote
target, was not supplying GDB with a main executable at all. Instead
the user attached to the target then did add-symbol-file, and then
proceeded to debug the target.
This works fine, but it was noticed that even when
trust-readonly-sections was on GDB was still accessing the target to
get the contents of readonly sections.
The problem is that by not providing an executable there was no
exec_target in the target stack, and so when GDB calls the
target_ops::get_section_table function GDB ends up in
dummy_target::get_section_table, which just returns NULL.
What I want is that even when GDB doesn't have an exec_target in the
target stack, a call to target_ops::get_section_table will still
return the section_table from the current program space.
When considering how to achieve this my first though was, why is the
request for the section table going via the target stack at all? The
set of sections loaded is a property of the program space, not the
target. This is, after all, why the data is being stored in the
program space.
So I initially tried changing target_get_section_table so that,
instead of calling into the target it just returns
current_program_space->target_sections ().
This would be fine except for one issue, target_bfd (from
bfd-target.c). This code is used from solib-svr4.c to create a
temporary target_ops structure that implements two functions
target_bfd::xfer_partial and target_bfd::get_section_table.
The purpose behind the code is to enable two targets, ppc64 and frv to
decode function descriptors from the dynamic linker, based on the
non-relocated addresses from within the dynamic linker bfd object.
Both of the implemented functions in target_bfd rely on the target_bfd
object holding a section table, and the ppc64 target requires that the
target_bfd implement ::get_section_table.
The frv target doesn't require ::get_section_table, instead it
requires the ::xfer_partial. We could in theory change the ppc64
target to use the same approach as frv, however, this would be a bad
idea. I believe that the frv target approach is broken. I'll
explain:
The frv target calls get_target_memory_unsigned to read the function
descriptor. The address being read is the non-relocated address read
from the dynamic linker in solib-srv4.c:enable_break. Calling
get_target_memory_unsigned eventually ends up in target_xfer_partial
with an object type of TARGET_OBJECT_RAW_MEMORY. This will then call
memory_xfer_check_region. I believe that it is quite possible that a
the non-relocated addresses pulled from the dynamic linker could be in
a memory region that is not readable, while the relocated addresses
are in a readable memory region. If this was ever the case for the
frv target then GDB would reject the attempt to read the non-relocated
function pointer.
In contrast the ppc64 target calls target_section_by_addr, which calls
target_get_section_table, which then calls the ::get_section_table
function on the target.
Thus, when reflecting on target_bfd we see two functions,
::xfer_partial and ::get_section_table. The former is required by the
frv target, but that target is (I think) potentially broken. While
the latter is required by the ppc64 target, but this forces
::get_section_table to exist as a target_ops member function.
So my original plan, have target_get_section_table NOT call a
target_ops member function appears to be flawed.
My next idea was to remove exec_target::get_section_table, and instead
move the implementation into dummy_target::get_section_table.
Currently the dummy_target implementation always returns NULL
indicating no section table, but plenty of other dummy_target member
functions do more than just return null values.
So now, dummy_target::get_section_table returns the section table from
the current program space. This allows target_bfd to remain
unchanged, so ppc64 and frv should not be affected.
Making this change removes the requirement for the user to provide an
executable, GDB can now always access the section_table, as the
dummy_target always exists in the target stack.
Finally, there's a test that the target_section table is not empty in
the case where the user does add-symbol-file without providing an
executable.
gdb/ChangeLog:
* exec.c (exec_target::get_section_table): Delete member function.
(section_table_read_available_memory): Use current_top_target, not
just the exec_ops target.
* target-delegates.c: Regenerate.
* target.c (default_get_section_table): New function.
* target.h (target_ops::get_section_table): Change default
behaviour to call default_get_section_table.
(default_get_section_table): Declare.
|
|
Following on from earlier commits which made access to the
target_sections table more 'const', this commit makes the table
private within the program_space class and provides member functions
to access the table.
Ideally I would have liked for the new target_sections member
function (on program_space) to return a 'const' reference to the table
within the program_space. Unfortunately, there are two places in
solib-*.c, where code outside of the program_space class modifies the
target_sections table, and so to support this we need to return a
non-const reference.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* exec.c (exec_target::close): Call new clear_target_sections
function.
(program_space::add_target_sections): Update name of member
variable.
(program_space::foreach_target_section): New function.
(program_space::add_target_sections): Update name of member
variable.
(program_space::remove_target_sections): Likewise.
(exec_one_fork): Use new target_sections member function.
(exec_target::get_section_table): Likewise.
(exec_target::files_info): Likewise.
(set_section_command): Use new foreach_target_section member
function.
(exec_set_section_address): Likewise.
(exec_target::has_memory): Use new target_sections member
function.
* progspace.h (program_space::clear_target_sections): New member
function.
(program_space::target_sections): Rename member variable to
m_target_sections, replace with a new member function.
(program_space::foreach_target_section): Declare new member
function.
(program_space::m_target_sections): New member variable.
* solib-dsbt.c (scan_dyntag): Use new member function.
* solib-svr4.c (scan_dyntag): Likewise.
|
|
During review of the next patch (which changes the 'section' command),
a bug was pointed out. I wondered why no tests spotted this bug and I
found that the 'section' command test (sect-cmd.exp) is only run on
hppa targets!
In this commit I have given this test script a bit of a spring clean,
bringing it up to date with current testsuite style. I have made some
of the patterns a little more robust, but in general my intention was
not to change the underlying meaning of any of these tests.
gdb/testsuite/ChangeLog:
* gdb.base/sect-cmd.exp: Rewrite using modern testsuite
techniques. Enable the test for all targets.
|
|
The code to access the target section table can be made more const, so
lets do that. There should be no user visible changes after this
commit.
gdb/ChangeLog:
* gdb/bfd-target.c (class target_bfd) <get_section_table>: Make
return type const.
* gdb/exec.c (struct exec_target) <get_section_table>: Likewise.
(section_table_read_available_memory): Make local const.
(exec_target::xfer_partial): Make local const.
(print_section_info): Make parameter const.
* gdb/exec.h (print_section_info): Likewise.
* gdb/ppc64-tdep.c (ppc64_convert_from_func_ptr_addr): Make local
const.
* gdb/record-btrace.c (record_btrace_target::xfer_partial):
Likewise.
* gdb/remote.c (remote_target::remote_xfer_live_readonly_partial):
Likewise.
* gdb/s390-tdep.c (s390_load): Likewise.
* gdb/solib-dsbt.c (scan_dyntag): Likewise.
* gdb/solib-svr4.c (scan_dyntag): Likewise.
* gdb/target-debug.h (target_debug_print_target_section_table_p):
Rename to...
(target_debug_print_const_target_section_table_p): ...this.
* gdb/target-delegates.c: Regenerate.
* gdb/target.c (target_get_section_table): Make return type const.
(target_section_by_addr): Likewise. Also make some locals const.
(memory_xfer_partial_1): Make some locals const.
* gdb/target.h (struct target_ops) <get_section_table>: Make
return type const.
(target_section_by_addr): Likewise.
(target_get_section_table): Likewise.
|
|
We already have a command 'maint info sections', this command prints
all sections from all known object files.
However, GDB maintains a second section table internally. This
section table is used when GDB wants to read directly from an object
file rather than actually reading memory on the target. As such only
some sections (the allocatable ones) are added to this secondary
section table.
I recently ran into a situation where some of GDB's optimisations for
reading directly from the files were not working. In 'maint info
sections' I could see that GDB knew about the object file, and did
know about the sections that it _should_ have been reading from. But
I couldn't ask GDB which sections it had copied into its secondary
section table.
This commit adds a new command 'maint info target-sections' that fills
this gap. This command lists only those sections that GDB has copied
into its secondary table.
You'll notice that the testsuite includes a comment indicating that
there's a bug in GDB. Normally this is not something I would add to
the testsuite, instead we should raise an actual bugzilla bug and then
mark an xfail, however, a later patch in this series will remove this
comment once the actual bug in GDB is fixed.
gdb/ChangeLog:
* NEWS: Mention new 'maint info target-sections' command.
* maint.c (maintenance_info_target_sections): New function.
(_initialize_maint_cmds): Register new command.
gdb/doc/ChangeLog:
* gdb.texinfo (Files): Document new 'maint info target-sections'
command.
gdb/testsuite/ChangeLog:
* gdb.base/maint-info-sections.exp: Add new tests.
(check_maint_info_target_sections_output): New proc.
|
