Tom Tromey [Fri, 12 May 2023 14:28:28 +0000 (08:28 -0600)]
Use tuples for default arguments in DAP
My co-worker Kévin taught me that using a mutable object as a default
argument in Python is somewhat dangerous, because the object is
created a single time (when the function is defined), and so if it is
mutated in the body of the function, the changes will stick around.
This patch changes the cases like this in DAP to use () rather than []
as the default. This patch is merely preventative, as no bugs like
this are in the code.
Tom Tromey [Thu, 11 May 2023 20:25:07 +0000 (14:25 -0600)]
Fix a latent bug in DAP request decorator
The 'request' decorator is intended to also ensure that the request
function runs in the DAP thread. However, the unwrapped function is
installed in the global request map, so the wrapped version is never
called. This patch fixes the bug.
Tom Tromey [Tue, 9 May 2023 20:38:45 +0000 (14:38 -0600)]
Rename one DAP function
When I first started implementing DAP, I had some vague plan of having
the implementation functions use the same name as the request. I
abandoned this idea, but one vestige remained. This patch renames the
one remaining function to be gdb-ish.
Tom Tromey [Mon, 17 Apr 2023 14:08:54 +0000 (08:08 -0600)]
Implement DAP setExceptionBreakpoints request
This implements the DAP setExceptionBreakpoints request for Ada. This
is a somewhat minimal implementation, in that "exceptionOptions" are
not implemented (or advertised) -- I wasn't completely sure how this
feature is supposed to work.
I haven't added C++ exception handling here, but it's easy to do if
needed.
This patch relies on the new MI command execution support to do its
work.
Tom Tromey [Thu, 16 Feb 2023 17:42:22 +0000 (10:42 -0700)]
Don't require inferior execution for Ada catchpoints
Currently, Ada catchpoints require that the inferior be running.
However, there's no deep reason for this -- for example, C++ exception
catchpoints do not have this requirement. Instead, those work like
ordinary breakpoints: they are pending until the needed runtime
locations are seen.
This patch changes Ada catchpoints to work the same way.
Tom Tromey [Thu, 16 Feb 2023 17:56:02 +0000 (10:56 -0700)]
Combine create_excep_cond_exprs and ada_catchpoint::re_set
This patch merges create_excep_cond_exprs into ada_catchpoint::re_set.
This is less verbose and is also a step toward making ada_catchpoint
work more like the other code_breakpoint-based exception catchpoints.
Tom Tromey [Mon, 17 Apr 2023 17:20:02 +0000 (11:20 -0600)]
Stop gdb in gnat_runtime_has_debug_info
gnat_runtime_has_debug_info starts a new gdb to do its work. However,
it also leaves this gdb running, which can potentially confuse the
calling test -- I encountered this when writing a new DAP test. This
patch changes the proc to shut down gdb.
Tom de Vries [Mon, 12 Jun 2023 11:00:09 +0000 (13:00 +0200)]
[gdb/testsuite] Relax breakpoint count check in gdb.python/py-rbreak.exp
With a gdb 13.2 based package on SLE-15 aarch64, I run into:
...
(gdb) PASS: gdb.python/py-rbreak.exp: nosharedlibrary
py sl = gdb.rbreak("^[^_]",minsyms=False)^M
Breakpoint 2 at 0x4004ac: file ../sysdeps/aarch64/crti.S, line 63.^M
...
(gdb) py print(len(sl))^M
12^M
(gdb) FAIL: gdb.python/py-rbreak.exp: check number of returned breakpoints is 11
...
The FAIL is due to:
- the glibc object crti.o containing debug information for function
call_weak_fn, and
- the test-case not expecting this.
The debug information is there due to compiling glibc using a binutils which
contains commit 591cc9fbbfd ("gas/Dwarf: record functions").
I've run into a similar issue before, see commit 3fbbcf473a5 ("[gdb/testsuite]
Fix regexp in py-rbreak.exp").
The fix I applied there was to use a regexp "^[^_]" to filter out
__libc_csu_fini and __libc_csu_init, but that doesn't work for call_weak_fn.
Fix this by:
- reverting the regexp to "", and
- rewriting the check to require at least 11 functions, rather than a precise
match.
Tom de Vries [Mon, 12 Jun 2023 09:14:24 +0000 (11:14 +0200)]
[gdb/testsuite] Fix breakpoint regexp in gdb.ada/out_of_line_in_inlined.exp
With a gdb 13.2 based package on openSUSE Tumbleweed i586, I ran into:
...
(gdb) run ^M
Starting program: out_of_line_in_inlined/foo_o224_021-all ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib/libthread_db.so.1".^M
^M
Breakpoint 1.1, foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:26^M
26 for C of S loop^M
(gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \
run to foo_o224_021.child1.child2
...
I can reproduce the same issue with gdb trunk on x86_64, by using optimize=-O3
instead of optimize=-O2.
The test case in that bug report involved running gdb against the 'jq'
program (which is a command-line JSON processor) on Fedora 37. Since
the debug info is compiler (and compile-time option) dependent, it
won't necessarily show up in other distributions or even past or
future versions of Fedora. (E.g. when trying the example shown below
on Fedora 38, GDB says that the value of 'value' has been optimized
out. I.e. it does not demonstrate the same DWARF error that can be
see when using Fedora 37.)
That said, on Fedora 37, the bug could be reproduced as follows:
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Reading symbols from /home/kev/.cache/debuginfod_client/9d3c8b4197350a190a74972d481de32abf641aa4/debuginfo...
No source file named src/util.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (src/util.c:415) pending.
Starting program: /usr/bin/jq </dev/null
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1, jq_util_input_next_input (state=0x55555555d7f0) at src/util.c:416
416 if (state->parser == NULL) {
(gdb) p value
DWARF-2 expression error: DW_OP_GNU_uninit must always be the very last op.
This is undesirable - rather than output an error about the DWARF
info, we'd prefer to see a value, even if it is uninitialized.
Examination of the debuginfo showed the following:
While DW_OP_GNU_uninit is not the very last op, it is the last op
prior to DW_OP_piece. The fix involved changing the DW_OP_GNU_uninit
case in dwarf_expr_context::execute_stack_op in gdb/dwarf2/expr.c so
that DW_OP_GNU_uninit may appear just before DW_OP_piece.
With the fix in place, attempting to print 'value' now looks like
this:
(gdb) p value
$1 = [uninitialized] {kind_flags = 0 '\000', pad_ = 0 '\000', offset = 0,
size = 0, u = {ptr = 0x0, number = 0}}
Note that "[uninitialized]" is part of the output. (But also note
that there's an extra space character.)
I've made a new test case,
gdb.dwarf2/DW_OP_piece_with_DW_OP_GNU_uninit.exp, by adapting an
existing one, gdb.dwarf2/opt-out-not-implptr.exp. Since it uses the
DWARF assembler, the test case does not depend on a specific compiler
version or compiler options.
Indu Bhagat [Fri, 9 Jun 2023 18:24:25 +0000 (11:24 -0700)]
libsframe: testsuite: add sframe_find_fre tests for pltN entries
Add a new test plt-findfre-1 to ensure lookup of SFrame stack trace
information for pltN entries is correct.
In this test, a dummy SFrame FDE of type SFRAME_FDE_TYPE_PCMASK is
created. The size of the 'function code block' covered by the SFrame
FDE is equivalent to 5 pltN entries of 16 bytes each.
The test first looks up SFrame FREs for some addresses in the first pltN
entry, followed by lookups for some addresses in the fourth pltN entry.
libsframe/
* Makefile.in: Regenerated.
* testsuite/libsframe.find/find.exp: Add new test.
* testsuite/libsframe.find/local.mk: Likewise.
* testsuite/libsframe.find/plt-findfre-1.c: New test.
Indu Bhagat [Fri, 9 Jun 2023 18:14:05 +0000 (11:14 -0700)]
libsframe: fix sframe_find_fre for pltN entries
To find SFrame stack trace information from an FDE of type
SFRAME_FDE_TYPE_PCMASK, sframe_find_fre () was doing an operation
like,
(start_ip_offset & 0xff) >= (pc & 0xff), etc.
This is buggy and needs correction. The mask 0xff should be 0xf (to
work for a pltN entry of size say, 16 bytes).
At this time, the size of the pltN entry is implicitly assumed to be 16
bytes by libsframe. In next version of the SFrame format, we can encode
this information explicitly in the SFrame FDE.
For now, we should fix the code to at least behave correctly for the
generated code and the generated SFrame stack trace information for the
pltN entries on x86_64.
libsframe/
* sframe.c (sframe_find_fre): Correct the bitmask used for
SFrame FDEs of type SFRAME_FDE_TYPE_PCMASK.
What's happening is that when debuginfod is initialised
debuginfod_begin is called (this is in the debuginfod library), this
in turn sets up libcurl, which makes use of openssl. Somewhere during
this setup process an at_exit function is registered to cleanup some
state.
Back in GDB the debuginfod_client object is managed using this code:
using debuginfod_client_up
= std::unique_ptr<debuginfod_client, debuginfod_client_deleter>;
And then a global debuginfod_client_up is created to hold a pointer to
the debuginfod_client object. As a global this will be cleaned up
using the standard C++ global object destructor mechanism, which is
run after the at_exit handlers.
However, it is expected that when debuginfod_end is called the
debuginfod_client object will still be in a usable state, that is, we
don't expect the at_exit handlers to have run and started cleaning up
the library state.
To fix this issue we need to ensure that debuginfod_end is called
before the at_exit handlers have a chance to run.
This commit removes the debuginfod_client_up type, and instead has GDB
hold a raw pointer to the debuginfod_client object. We then make use
of GDB's make_final_cleanup to register a function that will call
debuginfod_end.
As GDB's final cleanups are called before exit is called, this means
that debuginfod_end will be called before the at_exit handlers are
called, and the crash identified above is resolved.
It's not obvious how this issue can easily be tested for. The bug does
not appear to manifest when using a local debuginfod server, so we'd
need to setup something more involved. For now I'm proposing this
patch without any associated tests.
Co-Authored-By: Mark Wielaard <mark@klomp.org> Co-Authored-By: Simon Marchi <simark@simark.ca> Reviewed-By: Tom Tromey <tom@tromey.com> Reviewed-By: Aaron Merey <amerey@redhat.com>
Here argv[0] is a value* which we know is either a TYPE_CODE_ARRAY or
a TYPE_CODE_STRING. The problem is that the above line is casting the
value contents directly to a C-string, i.e. one that is assumed to
have a null-terminator at the end.
After the above commit this can no longer be assumed to be true. A
string value will be represented just as it would be in the current
language, so for Ada and Fortran the string will be an array of
characters with no null-terminator at the end.
My proposed solution is to copy the string contents into a std::string
object, and then use the std::string::c_str() value, this will ensure
that a null-terminator has been added.
I had a check through GDB at places TYPE_CODE_STRING was used and
couldn't see any other obvious places where this type of assumption
was being made, so hopefully this is the only offender.
Running the above test with ASan compiled in no longer gives an error.
Tom Tromey [Wed, 24 May 2023 19:59:58 +0000 (13:59 -0600)]
Use scoped_value_mark in two more places
I found a couple of spots that could use scoped_value_mark. One of
them is a spot that didn't consider the possibility that value_mark
can return NULL. I tend to doubt this can be seen in this context,
but nevertheless this is safer.
Alan Modra [Thu, 8 Jun 2023 10:25:55 +0000 (19:55 +0930)]
ecoff find_nearest_line and final link leaks
Freeing ecoff_debug_info "pointers to the unswapped symbolic info"
isn't a simple matter, due to differing allocation strategies. In
_bfd_ecoff_slurp_symbolic_info the pointers are to objalloc memory.
In the ecoff linker they are to separately malloc'd memory. In gas we
have most (obj-elf) or all (obj-ecoff) into a single malloc'd buffer.
This patch fixes the leaks for binutils and ld, leaving the gas leaks
for another day. The mips elf backend already had this covered, and
the ecoff backend had a pointer, raw_syments used as a flag, so most
of the patch is moving these around a little so they are accessible
for both ecoff and elf.
include/
* coff/ecoff.h (struct ecoff_debug_info): Add alloc_syments.
bfd/
* libecoff.h (struct ecoff_tdata): Delete raw_syments.
* elfxx-mips.c (free_ecoff_debug): Delete. Replace uses with
_bfd_ecoff_free_ecoff_debug_info.
(_bfd_mips_elf_final_link): Init debug.alloc_syments.
* ecofflink.c (_bfd_ecoff_free_ecoff_debug_info): New function.
* ecoff.c (_bfd_ecoff_bfd_free_cached_info): Call
_bfd_ecoff_free_ecoff_debug_info.
(_bfd_ecoff_slurp_symbolic_info): Replace uses of raw_syments
with alloc_syments.
(ecoff_final_link_debug_accumulate): Likewise. Use
_bfd_ecoff_free_ecoff_debug_info.
(_bfd_ecoff_bfd_copy_private_bfd_data): Set alloc_syments for
copied output.
* elf64-alpha.c (elf64_alpha_read_ecoff_info): Use
_bfd_ecoff_free_ecoff_debug_info.
* libbfd-in.h (_bfd_ecoff_free_ecoff_debug_info): Declare.
* libbfd.h: Regenerate.
gas/
* config/obj-ecoff.c (ecoff_frob_file): Set alloc_syments.
* config/obj-elf.c (elf_frob_file_after_relocs): Likewise.
I noticed that the test-suite doesn't excercise the case in
tui_redisplay_readline that height (initially 1) is changed by this call:
...
tui_puts_internal (w, prompt, &height);
...
Lancelot SIX [Wed, 31 May 2023 14:04:55 +0000 (15:04 +0100)]
gdb/corelow.c: do not try to reopen a file if open failed once
In the current implementation, core_target::build_file_mappings will try
to locate and open files which were mapped in the process for which the
core dump was produced. If the file cannot be found or cannot be
opened, GDB will re-try to open it once for each time it was mapped in
the process's address space.
This patch makes it so GDB recognizes that it has already failed to open
a given file once and does not re-try the process for each mapping.
Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
Lancelot SIX [Wed, 31 May 2023 11:23:05 +0000 (12:23 +0100)]
gdb/corelow.c: avoid repeated warnings in build_file_mappings
When GDB opens a coredump it tries to locate and then open all files
which were mapped in the process.
If a file is found but cannot be opened with BFD (bfd_open /
bfd_check_format fails), then a warning is printed to the user. If the
same file was mapped multiple times in the process's address space, the
warning is printed once for each time the file was mapped. I find this
un-necessarily noisy.
This patch makes it so the warning message is printed only once per
file.
There was a comment in the code assuming that if the file was found on
the system, opening it (bfd_open + bfd_check_format) should always
succeed. A recent change in BFD (014a602b86f "Don't optimise bfd_seek
to same position") showed that this assumption is not valid. For
example, it is possible to have a core dump of a process which had
mmaped an IO page from a DRI render node (/dev/dri/runderD$NUM). In
such case the core dump does contain the information that portions of
this special file were mapped in the host process, but trying to seek to
position 0 will fail, making bfd_check_format fail. This patch removes
this comment.
Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
The problem is that if bfd_check_format fails, we close the bfd but keep
a reference to it in the bfd_map.
If the same filename appears another time in the NT_FILE note, we enter
this code again. The second time, bfd_map[filename] is not nullptr and
we try to call bfd_make_section_anyway on an already closed BFD, which
is a use-after-free error.
This patch makes sure that the bfd is only saved in the bfd_map if it
got opened successfully.
This error got exposed by a recent change in BFD (014a602b86f "Don't
optimise bfd_seek to same position"). Since this change, opening a
coredump which contains mapping to some special files such as a DRI
render node (/dev/dri/renderD$NUM) exposes the issue. This happens for
example for processes using AMDGPU devices to offload compute tasks.
Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
Indu Bhagat [Wed, 7 Jun 2023 22:13:35 +0000 (15:13 -0700)]
libsframe: reuse static function sframe_decoder_get_funcdesc_at_index
sframe_decoder_get_funcdesc_at_index () is the function to access SFrame
FDEs in the SFrame decoder context. Use it consistently.
Avoid unnecessary type cast and include minor enhancements as the code
is moved around.
libsframe/
* sframe.c (sframe_decoder_get_funcdesc_at_index): Move some
checks here. Move the static function definition before the new
use.
(sframe_decoder_get_funcdesc): Use
sframe_decoder_get_funcdesc_at_index instead.
Tom Tromey [Mon, 5 Jun 2023 18:30:09 +0000 (12:30 -0600)]
Simplify ada_lookup_struct_elt_type
This patch simplifies ada_lookup_struct_elt_type by changing it to
call find_struct_field. The two functions were substantially similar,
even to the point of having identical comments.
I tested this using both the gdb test suite and the internal AdaCore
test suite. Given this and the fact that it is Ada-specific, I am
checking it in.
Nick Clifton [Wed, 7 Jun 2023 13:30:13 +0000 (14:30 +0100)]
Add extra linker warning message about discrepancies between normal and common symbols.
PR 30499
bfd * elflink.c (elf_link_add_object_symbols): Add a message indicating that alignment and size discrepancies between the definition of common symbols and normal symbols are serious and should be investigated.
ld * testsuite/ld-elfcomm/elfcomm.exp: Update regexps to match new output from the linker.
Tom de Vries [Wed, 7 Jun 2023 12:57:40 +0000 (14:57 +0200)]
[gdb/cli] Handle pending ^C after rl_callback_read_char for readline 7
In commit faf01aee1d0 ("[gdb] Handle pending ^C after rl_callback_read_char")
we handled a problem (described in detail in that commit) for readline >= 8
using public readline functions rl_pending_signal and rl_check_signals.
For readline 7 (note that we require at least readline 7 so there's no need to
worry about readline 6), there was no fix though, because rl_check_signals was
not available.
Fix this by instead using the private readline function _rl_signal_handler.
There is precedent for using private readline variables and functions, but
it's something we want to get rid of (PR build/10723). Nevertheless, I think
we can allow this specific instance because it's not used when building
against readline >= 8.
[ In the meanwhile, a fix was committed in the devel branch of the readline
repo, contained in commit 8d0c439 ("rollup of changes since readline-8.2"),
first proposed here (
https://lists.gnu.org/archive/html/bug-readline/2022-10/msg00008.html ). ]
Tested on x86_64-linux, against system readline 7.0 on openSUSE Leap 15.4.
Tom de Vries [Tue, 16 May 2023 16:00:51 +0000 (17:00 +0100)]
Fix PR30369 regression on aarch64/arm (PR30506)
The gdb.dwarf2/dw2-prologue-end-2.exp test was failing for both AArch64 and
Arm.
As Tom pointed out here (https://inbox.sourceware.org/gdb-patches/6663707c-4297-c2f2-a0bd-f3e84fc62aad@suse.de/),
there are issues with both the prologue skipper for AArch64 and Arm and an
incorrect assumption by the testcase.
This patch fixes both of AArch64's and Arm's prologue skippers to not skip past
the end of a function. It also incorporates a fix to the testcase so it
doesn't assume the prologue skipper will stop at the first instruction of the
functions/labels.
Regression-tested on aarch64-linux/arm-linux Ubuntu 20.04/22.04 and
x86_64-linux Ubuntu 20.04.
Tom de Vries [Wed, 7 Jun 2023 09:36:19 +0000 (11:36 +0200)]
[gdb/testsuite] Add missing wait in gdb.python/tui-window-disabled.exp
While working on PR tui/30526, I noticed a bug in test-case
gdb.python/tui-window-disabled.exp.
Here we send "tui enable" to gdb, but don't wait for it to arrive before
checking for a window box:
...
send_gdb "tui enable\n"
Term::check_box "check for python window" 0 0 80 16
...
Fix this by waiting for the prompt to be issued in TUI before doing the check.
Alan Modra [Wed, 7 Jun 2023 07:58:22 +0000 (17:28 +0930)]
ld-elf/eh5 remove xfail hppa64
Commit cb81e84c72 resulted in an xpass for hppa64-hp-hpux11, but the
test still fails on hpp64-linux. Let's make it pass for hppa64-linux
too, by accepting pcrel sdata8 encoding in the augmentation data.
Luis Machado [Tue, 6 Jun 2023 09:57:59 +0000 (10:57 +0100)]
Fix gdb.base/memtag.exp failure
While running this test on an emulator, I noticed we're failing to match the
output message when "memory-tag check" is issued with no arguments. That's
because I coded the message using "error" and missed a period at the end. Other
similar messages are issued with error_no_arg.
Alan Modra [Wed, 7 Jun 2023 04:46:06 +0000 (14:16 +0930)]
_bfd_free_cached_info
doc/bfdint.texi and comments in the aout and som code about this
function are just wrong, and its name is not very apt. Better would
be _bfd_mostly_destroy, and we certainly should not be saying anything
about the possibility of later recreating anything lost by this
function. What's more, if _bfd_free_cached_info is called when
creating an archive map to reduce memory usage by throwing away
symbols, the target _close_and_cleanup function won't have access to
tdata or section bfd_user_data to tidy memory. This means most of the
target _close_and_cleanup function won't do anything, and therefore
sometimes will result in memory leaks.
This patch fixes the documentation problems and moves most of the
target _close_and_cleanup code to target _bfd_free_cached_info.
Another notable change is that bfd_generic_bfd_free_cached_info is now
defined as _bfd_free_cached_info rather than _bfd_bool_bfd_true,
ie. the default now frees objalloc memory.
Indu Bhagat [Tue, 6 Jun 2023 17:50:07 +0000 (10:50 -0700)]
libsframe: fix cosmetic issues and typos
include/
* sframe-api.h (sframe_decoder_get_num_fidx): Use extern.
libsframe/
* sframe-dump.c (dump_sframe_func_with_fres): Fix line length.
* sframe.c (sframe_frame_row_entry_copy): Likewise.
(sframe_decode_fre_start_address): Use the intended type uint32_t.
Alan Modra [Tue, 6 Jun 2023 10:26:56 +0000 (19:56 +0930)]
Re: loongarch readelf support
Commit 89c70cd358b8 apparently results in a bogus "value may be used
uninitialized" warning with some combination of compiler and
optimisation options.
Indu Bhagat [Mon, 5 Jun 2023 21:16:02 +0000 (14:16 -0700)]
libsframe: avoid unnecessary type casts
Change the data type of some of the members of the sframe_decoder_ctx
and sframe_encoder_ctx data structures to use the applicable data types
explicitly. Current implementation in libsframe does type casts, which
seem unnecessary.
libsframe/
* libsframe/sframe-impl.h (struct sframe_decoder_ctx): Use
applicable data type explicitly.
(struct sframe_encoder_ctx): Likewise. Use same style of
comments consistently.
* libsframe/sframe.c (struct sf_fde_tbl): Define without
typedef.
(struct sf_fre_tbl): Likewise.
(sframe_decode): Remove unnecessary type casts.
(sframe_encoder_get_funcdesc_at_index): Likewise.
(sframe_encoder_add_fre): Likewise.
(sframe_encoder_add_funcdesc): Likewise.
(sframe_sort_funcdesc): Likewise.
(sframe_encoder_write_sframe): Likewise.
Tom Tromey [Mon, 24 Apr 2023 14:23:46 +0000 (08:23 -0600)]
Use unrelocated_addr in dwarf2_fde
This changes dwarf2_fde to use the unrelocated_addr type. This
pointed out a latent bug in dwarf2_frame_cache, where a relocated
address is compared to an unrelocated address.
Tom Tromey [Wed, 19 Apr 2023 19:36:56 +0000 (13:36 -0600)]
Move unrelocated_addr to common-types.h
unrelocated_addr is currently defined in symtab.h, but in order to
avoid having to include that in more places, I wanted to move the type
elsewhere. I considered defs.h, but it seemed reasonable to have it
next to CORE_ADDR, which is what this patch does.
Tom Tromey [Wed, 19 Apr 2023 19:21:51 +0000 (13:21 -0600)]
Remove baseaddr parameter from dwarf2_record_block_ranges
dwarf2_record_block_ranges is only ever called with the text section
offset, so this patch removes the parameter entirely. This makes a
subsequent patch a little simpler.
Andrew Burgess [Tue, 13 Jul 2021 18:44:27 +0000 (14:44 -0400)]
gdb: building inferior strings from within GDB
History Of This Patch
=====================
This commit aims to address PR gdb/21699. There have now been a
couple of attempts to fix this issue. Simon originally posted two
patches back in 2021:
The approach taken in my first patch was pretty similar to what Simon
originally posted back in 2021. My second attempt was only a slight
variation on the first.
Pedro then pointed out his older patch, and so we arrive at this
patch. The GDB changes here are mostly Pedro's work, but updated by
me (Andrew), any mistakes are mine.
The tests here are a combinations of everyone's work, and the commit
message is new, but copies bits from everyone's earlier work.
Problem Description
===================
Bug PR gdb/21699 makes the observation that using $_as_string with
GDB's printf can cause GDB to print unexpected data from the
inferior. The reproducer is pretty simple:
#include <stddef.h>
static char arena[100];
/* Override malloc() so value_coerce_to_target() gets a known
pointer, and we know we"ll see an error if $_as_string() gives
a string that isn't null terminated. */
void
*malloc (size_t size)
{
memset (arena, 'x', sizeof (arena));
if (size > sizeof (arena))
return NULL;
return arena;
}
int
main ()
{
return 0;
}
And then in a GDB session:
$ gdb -q test
Reading symbols from /tmp/test...
(gdb) start
Temporary breakpoint 1 at 0x4004c8: file test.c, line 17.
Starting program: /tmp/test
Temporary breakpoint 1, main () at test.c:17
17 return 0;
(gdb) printf "%s\n", $_as_string("hello")
"hello"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
(gdb) quit
The problem above is caused by how value_cstring is used within
py-value.c, but once we understand the issue then it turns out that
value_cstring is used in an unexpected way in many places within GDB.
Within py-value.c we have a null-terminated C-style string. We then
pass a pointer to this string, along with the length of this
string (so not including the null-character) to value_cstring.
In value_cstring GDB allocates an array value of the given character
type, and copies in requested number of characters. However
value_cstring does not add a null-character of its own. This means
that the value created by calling value_cstring is only
null-terminated if the null-character is included in the passed in
length. In py-value.c this is not the case, and indeed, in most uses
of value_cstring, this is not the case.
When GDB tries to print one of these strings the value contents are
pushed to the inferior, and then read back as a C-style string, that
is, GDB reads inferior memory until it finds a null-terminator. For
the py-value.c case, no null-terminator is pushed into the inferior,
so GDB will continue reading inferior memory until a null-terminator
is found, with unpredictable results.
Patch Description
=================
The first thing this patch does is better define what the arguments
for the two function value_cstring and value_string should represent.
The comments in the header file are updated to describe whether the
length argument should, or should not, include a null-character.
Also, the data argument is changed to type gdb_byte. The functions as
they currently exist will handle wide-characters, in which case more
than one 'char' would be needed for each character. As such using
gdb_byte seems to make more sense.
To avoid adding casts throughout GDB, I've also added an overload that
still takes a 'char *', but asserts that the character type being used
is of size '1'.
The value_cstring function is now responsible for adding a null
character at the end of the string value it creates.
However, once we start looking at how value_cstring is used, we
realise there's another, related, problem. Not every language's
strings are null terminated. Fortran and Ada strings, for example,
are just an array of characters, GDB already has the function
value_string which can be used to create such values.
Consider this example using current GDB:
(gdb) set language ada
(gdb) p $_gdb_setting("arch")
$1 = (97, 117, 116, 111)
(gdb) ptype $
type = array (1 .. 4) of char
(gdb) p $_gdb_maint_setting("test-settings string")
$2 = (0)
(gdb) ptype $
type = array (1 .. 1) of char
This shows two problems, first, the $_gdb_setting and
$_gdb_maint_setting functions are calling value_cstring using the
builtin_char character, rather than a language appropriate type. In
the first call, the 'arch' case, the value_cstring call doesn't
include the null character, so the returned array only contains the
expected characters. But, in the $_gdb_maint_setting example we do
end up including the null-character, even though this is not expected
for Ada strings.
This commit adds a new language method language_defn::value_string,
this function takes a pointer and length and creates a language
appropriate value that represents the string. For C, C++, etc this
will be a null-terminated string (by calling value_cstring), and for
Fortran and Ada this can be a bounded array of characters with no null
terminator. Additionally, this new language_defn::value_string
function is responsible for selecting a language appropriate character
type.
After this commit the only calls to value_cstring are from the C
expression evaluator and from the default language_defn::value_string.
And the only calls to value_string are from Fortan, Ada, and ObjectC
related code.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Co-Authored-By: Pedro Alves <pedro@palves.net> Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Mon, 5 Jun 2023 10:53:15 +0000 (12:53 +0200)]
[gdb] Fix grammar in comments and docs
Fix grammar in some comments and docs:
- machines that doesn't -> machines that don't
- its a -> it's a
- its the -> it's the
- if does its not -> if it does it's not
- one more instructions if doesn't match ->
one more instruction if it doesn't match
- it's own -> its own
- it's first -> its first
- it's pointer -> its pointer
I also came across "it's performance" in gdb/stubs/*-stub.c in the HP public
domain notice, I've left that alone.
Alan Modra [Mon, 5 Jun 2023 06:55:16 +0000 (16:25 +0930)]
bfd_error_on_input messages
bfd_errmsg uses asprintf for bfd_error_on_input, which means we
currently leak memory. Keep a static pointer to the message and free
it in various places to minimise the leaks.
bfd_set_input_error (NULL, bfd_error_no_error) is a way to free up the
last string if that matters.
* bfd.c (input_error_msg): New static var.
(bfd_set_input_error): Free it here..
(bfd_init): ..and here..
(bfd_errmsg): ..and here. Use it for asprintf output.
YunQiang Su [Wed, 26 Apr 2023 10:16:40 +0000 (18:16 +0800)]
MIPS: sync oprand char usage between mips and micromips
We should try our best to make mips32 using the same
oprand char with micromips. So for mips32, we use:
^ is added for 5bit sa oprand for some new DSPr2 instructions:
APPEND, PREPEND, PRECR_SRA[_R].PH.W
the LSB bit is 11, like RD.
+t is removed for coprocessor 0 destination register.
'E' does the samething.
+t is now used for RX oprand for MFTR/MTTR (MT ASE)
? is added for sel oprand for MFTR/MTTR (MT ASE)
For mips32, the position of sel in MFTR/MTTR is same with mfc0 etc,
while for micromips, they are different.
We also add an extesion format of cftc2/cttc2/mftc2/mfthc2/mttc2/mtthc2:
concatenating rs with rx as the index of control or data.
YunQiang Su [Tue, 16 May 2023 01:46:46 +0000 (09:46 +0800)]
MIPS: fix some ld testcases with compiler
1. config/default.exp:
use -mabi=32 not for -gnuabi64
xfail_from_runlist: remove an element and mark it xfail.
2. ld-elf/indirect.exp: xfail
indirect5a indirect5b indirect6a indirect6b
indirect5c indirect5d indirect6c indirect6d
3. ld-elf/pr23658-2: mips output is not common
4. ld-elf/shared.exp: non-run on mips: Build libpr16496b.so
5. ld-elfvers/vers.exp:
xfail vers4, vers4b
no-run on mips: vers24a, vers24b, vers24c
6. ld-gc/gc.exp: add -KPIC into asflags for pr13683, pr14265, pr19161
7. ld-mips-elf/mips-elf.exp:
use noarch for mips16-local-stubs-1, since it use -mips4
8. ld-plugin/lto.exp:
no-run on mips/linux: PR ld/12982
add -KPIC into asflags for lto-3r, lto-5r, PR ld/19317 (2)
xfail PR ld/15323 (4), PR ld/19317 (3)
9. ld-plugin/plugin.exp: xfail
plugin claimfile lost symbol
plugin claimfile replace symbol
plugin claimfile replace symbol
plugin claimfile lost symbol with source
plugin claimfile replace symbol with source
plugin claimfile resolve symbol with source
plugin 2 with source lib
load plugin 2 with source
plugin 3 with source lib
load plugin 3 with source
11. ld-selective/selective.exp: add -fno-PIC, which is needed for -mno-abicalls
12. ld-shared/shared.exp: xfail shared (non PIC), shared (PIC main, non PIC so)
YunQiang Su [Wed, 10 May 2023 13:22:41 +0000 (21:22 +0800)]
MIPS: fix -gnuabi64 testsuite
Test on:
mips64-linux-gnuabi64
mips64el-linux-gnuabi64
mipsisa64-linux-gnuabi64
mipsisa64el-linux-gnuabi64
mipsisa64r2-linux-gnuabi64
mipsisa64r2el-linux-gnuabi64
mipsisa64r6-linux-gnuabi64
mipsisa64r6el-linux-gnuabi64
YunQiang Su [Wed, 10 May 2023 07:50:19 +0000 (15:50 +0800)]
MIPS: fix r6 testsuites
Introduce
run_dump_test_o32l
run_dump_test_n32l
run_dump_test_n64l
Which use `-march=from-abi` for pre-R6 testcases,
like micromips/mips16e etc.
For cases doesn't use run_dump_test_*, we use
-mips32r2 for micromips32
-mips1 for mips16-32
-march=from-abi for testcases to o32/n32/n64 both/all.
Replace `addi` with `addiu` for some cases for both r6 and pre-R6.
Introduce some new testcases for r6 with FPXX/FP64.
Introduce new testcase: comdat-reloc-r6.
Skip `default` in mips_arch_list_matching if triple is mipsisa*, due to:
1)it will cannot match mipsr6@*.d: since mips32rN/mips64rN
will always be used, it won't be a problem.
2)some test think -march=mips64rN will alway true for mipsisa64rN,
which is not true now.
This patch fix testsuite for all r6-default gnu triples:
mipsisa32r6-linux-gnu
mipsisa32r6el-linux-gnu
mips-img-linux-gnu
mipsel-img-linux-gnu
mipsisa64r6-linux-gnu
mipsisa64r6el-linux-gnu
YunQiang Su [Wed, 10 May 2023 10:07:23 +0000 (18:07 +0800)]
MIPS: default r6 if vendor is img
This behavior is used by downstream toolchain since 2014.
We also set the default ABI for mips*-img-elf to O32.
The previous value is NO_ABI, which is not good default ABI.
We don't support mips64*-img* due to GCC doesn't support it,
and We believe that the multilib should be used for this case.
YunQiang Su [Sat, 6 May 2023 08:26:13 +0000 (16:26 +0800)]
MIPS: gas: alter 64 or 32 for mipsisa triples if march is implicit
When configure with triples mipsisa[32,64]rN[el,], the march value
is pinned to a fix value if not given explicitly. for example
1) mipsisa32r6-linux-gnu -n32 xx.s will complains that:
-march=mips32r6 is not compatible with the selected ABI
2) mipsisa64r2el-linux-gnu -o32 generates objects with 64bit CPU:
ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)
They are not good default behaviors: Let's alter the CPU info
Since we are using these triples as a regular linux distributions,
let's alter march according to ABI.
Tom de Vries [Sat, 3 Jun 2023 20:43:57 +0000 (22:43 +0200)]
[gdb/python] Fix doc string of valpy_const_value
In gdb/python/py-value.c, in the value_object_methods array I noticed:
...
{ "const_value", valpy_const_value, METH_NOARGS,
"Return a 'const' qualied version of the same value." },
...
Tom de Vries [Sat, 3 Jun 2023 20:43:57 +0000 (22:43 +0200)]
[gdb/guile] Fix doc string for value-optimized-out?
In gdb/guile/scm-value.c, I noticed in the value_functions array initializer:
...
{ "value-optimized-out?", 1, 0, 0,
as_a_scm_t_subr (gdbscm_value_optimized_out_p),
"\
Return #t if the value has been optimizd out." },
...
There's a typo in the doc string.
Tom de Vries [Sat, 3 Jun 2023 20:43:57 +0000 (22:43 +0200)]
[gdb/tui] Fix help text of show tui tab-width
I noticed:
...
(gdb) help show tui tab-width
Show the tab witdh, in characters, for the TUI.
This variable controls how many spaces are used to display a tab character.
...
a typo: "witdh".
Tom de Vries [Sat, 3 Jun 2023 20:43:57 +0000 (22:43 +0200)]
[gdb/cli] Fix help text of maint set ignore-prologue-end-flag
I noticed here:
...
(gdb) help maint set ignore-prologue-end-flag
Set if the PROLOGUE-END flag is ignored.
The PROLOGUE-END flag from the line-table entries is used to place \
breakpoints past the prologue of functions. Disabeling its use use forces \
the use of prologue scanners.
...
a typo in "Disabeling" and accidental word repetition "use use".
projects / thirdparty / binutils-gdb.git / log
