Jan Beulich [Fri, 17 Mar 2023 09:07:05 +0000 (10:07 +0100)]
gas: apply md_register_arithmetic also to unary '+'
Even a unary '+' has to be considered arithmetic; at least on x86 in
Intel Syntax mode otherwise bogus insn operands may be accepted.
Convert this specific case to binary + (i.e. 0 + <register>). (An
implication is that md_operator(,1,) would need to deal with arch-
specific equivalents of unary '+' is a similar way, if such an arch-
specific variant would be specified in the first place.)
To avoid duplicating what make_expr_symbol() does to construct a
constant-zero expression, simply make its previously local variable a
file-scope static one. This way there's also no need to invoke
clean_up_expression().
Jan Beulich [Fri, 17 Mar 2023 09:06:18 +0000 (10:06 +0100)]
gas: expose flag_macro_alternate globally
Yet again with the removal of gasp about 20 years ago this extra level
of indirection isn't necessary anymore either. Drop macro.c's local
variable and make as.c's global.
While doing the conversion, switch the variable to "bool".
Jan Beulich [Fri, 17 Mar 2023 09:05:57 +0000 (10:05 +0100)]
gas: use flag_mri directly in macro processing
Again with the removal of gasp about 20 years ago the extra level of
indirection isn't necessary anymore. Drop macro.c's local variable and
use the global flag directly.
Jan Beulich [Fri, 17 Mar 2023 09:05:32 +0000 (10:05 +0100)]
gas: isolate macro_strip_at to macro.c
This removes a leftover from i960 support; with that nothing is left
which would set macro_strip_at to non-zero, so the variable is converted
to a #define (retaining the logic in case a new user would appear) and
macro_init()'s respective parameter is dropped.
Jan Beulich [Fri, 17 Mar 2023 09:05:05 +0000 (10:05 +0100)]
gas: drop function pointer parameter from macro_init()
With the removal of gasp (about 20 years ago) the need for this kind-
of-hook has disappeared. Go a step beyond merely moving the to be called
function: Inline its contents right at the sole call site.
Tom de Vries [Fri, 17 Mar 2023 09:01:07 +0000 (10:01 +0100)]
[gdb/testsuite] Fix filename in gdb.debuginfod/crc_mismatch.exp
After running test-case gdb.debuginfod/crc_mismatch.exp, I find a dir called '$':
...
$ ls $build/gdb/testsuite/
$ config.log gdb.log lib outputs site.exp
cache config.status gdb.sum Makefile site.bak temp
...
Fix this by removing the stray '$' here:
...
set debugfile "$[standard_output_file ${testfile}.debug]"
...
Andrew Burgess [Mon, 16 Jan 2023 17:38:10 +0000 (17:38 +0000)]
gdb/doc: extended documentation for inferior function calls
I noticed that the documentation for inferior function calls doesn't
say much about what happens if/when an inferior function call is
interrupted, i.e. it doesn't describe what the dummy frame looks like
on the stack, or how GDB behaves when the inferior is continued and
reaches the dummy frame.
This commit aims to add some of this missing information.
Tom Tromey [Thu, 16 Mar 2023 13:48:22 +0000 (07:48 -0600)]
Fix build breakage in rs6000-aix-tdep.c
A recent change to rs6000-aix-tdep.c broke the build. This patch
fixes it by declaring a few target descriptions in ppc-tdep.h and then
not including the various features .c files in rs6000-aix-tdep.c.
Hui Li [Sat, 4 Mar 2023 00:45:28 +0000 (08:45 +0800)]
gdb/testsuite: Add support for LoongArch in gdb.base/float.exp
The test results on LoongArch as follows:
Without this patch:
```
$ make check-gdb TESTS="gdb.base/float.exp"
=== gdb Summary ===
# of expected passes 2
# of unexpected failures 1
```
With this patch:
```
$ make check-gdb TESTS="gdb.base/float.exp"
=== gdb Summary ===
# of expected passes 3
```
Signed-off-by: Hui Li <lihui@loongson.cn> Reviewed-By: Tom Tromey <tom@tromey.com> Approved-By: Simon Marchi <simon.marchi@efficios.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Andrew Burgess [Wed, 8 Mar 2023 15:26:32 +0000 (15:26 +0000)]
gdb/doc: spring clean the Python unwinders documentation
The documentation for the Python Unwinders API could do with some
improvement. The 'Unwinder Skeleton Code' has an error: it says
'unwinders' when it should say 'unwinder' in one case.
Additionally, by placing the 'Unwinder Skeleton Code' before the
section 'Registering an Unwinder' we have skipping including the
registration line in the skeleton code. But this is confusion for
users (I think) as the skeleton code is almost complete, except for
one missing line which the user has to figure out for themselves. By
reordering the sections, it is now obvious that the registration
should be included in the skeleton code, and the example is therefore
almost complete.
Additionally, in the example skeleton code the way in which the
frame-id was being built (using the current stack point and program
counter is (a) not correct, and (b) counter to what is laid out in the
'Unwinder Input' section when describing building a frame-id.
I've removed the incorrect code and replaced it with more generic
comments indicating what needs to be done. As the actual actions that
need to be performed are both architecture specific, and dependent on
the function being unwound, it's almost impossible to include more
exact code here, but I think what I'm proposing is less misleading
than what we had before.
Clément Chigot [Thu, 27 Oct 2022 08:45:00 +0000 (10:45 +0200)]
ld/testsuite: disable ilp32 tests for aarch64-qnx
aarch64nto32 emulation isn't supported. The tests will then fall back
on aarch64elf32. It does work but some extra warnings are being
generated because the "-z relro" being added aarch64nto but ignored by
aarch64elf32 emulation.
Skip the tests to avoid any problems.
Clément Chigot [Mon, 28 Nov 2022 08:29:37 +0000 (09:29 +0100)]
ld: add support of QNX stack arguments for aarch64nto
QNX is handling the stack argument using a .note section. Generate it
according to ELF argument -zexecstack, -zstack-size and a new NTO
argument --lazy-stack. Another NTO argument --stack mimicking
-zstack-size is added in order to ensure compatibility with previously
made NTO linkers.
This requires a new emultempl nto.em which is applied above the default
${ARCH}elf.em.
ld/ChangeLog:
* emulparams/aarch64nto.sh: Move to nto.em.
* emultempl/nto.em: New file.
* testsuite/ld-aarch64/aarch64-nto.exp: New test.
* testsuite/ld-aarch64/nto-stack-note-1.d: New test.
* testsuite/ld-aarch64/nto-stack-note-2.d: New test.
* testsuite/ld-aarch64/start.s: New test.
* readelf.c (get_qnx_elfcore_note_type): New function.
(print_qnx_note): New function.
(process_note): Add support for QNX support.
include/ChangeLog:
* elf/common.h (QNT_DEBUG_FULLPATH): New define.
(QNT_DEBUG_RELOC): New define.
(QNT_STACK): New define.
(QNT_GENERATOR): New define.
(QNT_DEFAULT_LIB): New define.
(QNT_CORE_SYSINFO): New define.
(QNT_CORE_INFO): New define.
(QNT_CORE_STATUS): New define.
(QNT_CORE_GREG): New define.
(QNT_CORE_FPREG): New define.
(QNT_LINK_MAP): New define.
Alan Modra [Thu, 16 Mar 2023 06:40:07 +0000 (17:10 +1030)]
Re: Add --enable-linker-verssion
Output sections without any input sections to initialise their flags
have their flags initialised by data statements to LOAD, ALLOC,
HAS_CONTENTS by default. This is wrong for .comment. Fix that by
making the script initialise the section type to INFO, one of the
noalloc section types. That also allows the address of .comment to be
set to zero, as is usual for non-alloc sections.
Also, use source_sh for all of the sourced scripts to set up make
dependencies.
Alan Modra [Wed, 15 Mar 2023 07:37:44 +0000 (18:07 +1030)]
PR30217, dynamic relocations using local dynamic symbols
glibc's ld.so ignores local dynamic symbols. It's been that way
forever. We therefore can't use them on dynamic relocations. Fixing
that problem uncovered another problem in sorting of dynamic relocs,
caused no doubt by copying make_iplt_section (where we don't want
reloc sorting by the generic gold function, we want iplt relocs last)
to make_lplt_section (where we do want sorting).
PR 30217
* powerpc.cc (branch_needs_plt_entry): New function.
(Target_powerpc::plt_off): Use it here..
(Target_powerpc::Scan::global): ..and here to correct PLT16 reloc
handling for forced-local global symbols.
(Output_data_plt_powerpc::add_entry): Rename "stash"
parameter "is_local". Emit relative relocs for globals that
are forced local, and don't set_needs_dynsym_entry.
(Target_powerpc::make_lplt_section): Don't create a separate
reloc section, use rela_dyn.
(Target_powerpc::make_brlt_section): Likewise.
Tom de Vries [Wed, 15 Mar 2023 15:38:03 +0000 (16:38 +0100)]
[gdb/testsuite] Fix gdb.arch/amd64-stap-special-operands.exp for remote host
With test-case gdb.arch/amd64-stap-special-operands.exp and host board
local-remote-host-notty and target board native-gdbserver I run into:
...
(gdb) break -pstap three_arg^M
No probe matching objfile=`<any>', provider=`<any>', name=`three_arg'^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.arch/amd64-stap-special-operands.exp: probe: three_arg: \
gdb_breakpoint: set breakpoint at -pstap three_arg
...
due to compiling two executables with the same name, and when uploading the
second one from host to build, we run into:
...
Upload from 127.0.0.1 failed, \
$outputs/gdb.arch/amd64-stap-special-operands/amd64-stap-special-operands: \
Text file busy.
...
Tom de Vries [Wed, 15 Mar 2023 15:38:03 +0000 (16:38 +0100)]
[gdb/testsuite] Unset DEBUGINFOD_URLS on remote host
When running test-case gdb.arch/i386-pkru.exp with host board
local-remote-host-notty and target board native-gdbserver on openSUSE
Tumbleweed (with DEBUGINFOD_URLS set), I run into:
...
This GDB supports auto-downloading debuginfo from the following URLs:^M
<https://debuginfod.opensuse.org/>^M
Enable debuginfod for this session? (y or [n]) ^CQuit^M
(gdb) FAIL: gdb.arch/i386-pkru.exp: runto: run to main
...
The problem is that the unsetenv for DEBUGINFOD_URLS in default_gdb_init:
...
# If DEBUGINFOD_URLS is set, gdb will try to download sources and
# debug info for f.i. system libraries. Prevent this.
unset -nocomplain ::env(DEBUGINFOD_URLS)
...
doesn't work on remote host.
Fix this by using "set debuginfod enabled off" for remote host.
Tom de Vries [Wed, 15 Mar 2023 15:38:03 +0000 (16:38 +0100)]
[gdb/testsuite] Fix gdb.arch/amd64*.exp with local-remote-host-native.exp
There's a number of gdb.arch/amd64*.exp test-cases that fail with host+target
board local-remote-host-native.exp because of using a .S file, generated from
a .c file.
If a test-case compiles the .S file when executing on remote host,
the .S file is already copied from build to host, such that it's available for
the compiler.
But that's not the case for the .c file, which is needed by gdb to show a
source line:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, fn2 (y=y@entry=25, x=x@entry=6) at amd64-entry-value-inline.c:32^M
32 in gdb.arch/amd64-entry-value-inline.c^M
(gdb) FAIL: gdb.arch/amd64-entry-value-inline.exp: continue to breakpoint: \
break-here
...
Fix this by using "gdb_remote_download host <.c file>".
Tested on x86_64-linux, with host+target board local-remote-host-native.
Tom Tromey [Mon, 13 Feb 2023 16:56:58 +0000 (09:56 -0700)]
Implement DAP variables, scopes, and evaluate requests
The DAP code already claimed to implement "scopes" and "evaluate", but
this wasn't done completely correctly. This patch implements these
and also implements the "variables" request.
After this patch, variables and scopes correctly report their
sub-structure. This also interfaces with the gdb pretty-printer API,
so the output of pretty-printers is available.
Tom Tromey [Thu, 23 Feb 2023 17:45:47 +0000 (10:45 -0700)]
Hide the implementation of gdb_mpf
This renames the data member of gdb_mpf and makes it private. It also
adds a single new method to aid in this change. Unlike the earlier
changes here, I did this one all together because gdb_mpf has very few
uses.
Tom Tromey [Thu, 23 Feb 2023 14:13:40 +0000 (07:13 -0700)]
Clean up gmp-utils.h includes
gmp-utils.h includes "defs.h", but normally the rule in gdb is that
the .c files include this first. This patch changes this code to
match the rest of gdb.
Add a test-case that tests the sanity of target/host boards.
It contains a number of tests related to remote file manipulation, exercising:
- remote_upload
- remote_download
- remote_file exists
- remote_file delete
which check that these work together as expected.
Tested on x86_64-linux, with all relevant gdb/testsuite/boards/*.exp boards.
For target board remote-stdio-gdbserver.exp, this revealed a trivial problem
with the return value of proc ${board}_file for delete, so fix this.
The test-case shows that the proc ${board}_download in
local-remote-host-native.exp is broken, so remove it.
Likewise for board local-remote-host.exp, so remove proc ${board}_download and
associated ${board}_file.
Alan Modra [Fri, 10 Mar 2023 09:58:22 +0000 (20:28 +1030)]
gas/read.c: init more statics
* read.c (current_name, current_label, dwarf_file, dwarf_line): Move
to file scope.
(pobegin): Tidy pop_override_ok.
(read_a_source_file): Make last_eol an auto var.
(s_reloc): Constify bfd_relocs.
(read_begin): Init more variables.
Alan Modra [Sun, 12 Mar 2023 02:57:38 +0000 (13:27 +1030)]
gas .include and .incbin
This fixes a bug in .include and .incbin where given an absolute path
the -I dirs would be searched for the path.
* read.c (include_dir_count, include_dir_maxlen): Make them size_t.
(search_and_open): New function.
(s_incbin, s_include): Use search_and_open.
(init_include_dir): New function.
(add_include_dir): Don't set initial "." dir here.
* read.h (include_dir_count, include_dir_maxlen): Update.
(init_include_dir, search_and_open): Declare.
* as.c (gas_early_init): Call init_include_dir.
* config/tc-rx.c (rx_include): Avoid warning by using size_t.
* config/tc-tic54x.c (tic54x_set_default_include): Simplify and
use notes for include path.
(tic54x_mlib): Use search_and_open.
Alan Modra [Fri, 10 Mar 2023 09:56:51 +0000 (20:26 +1030)]
gas/ecoff.c: don't use zero struct copies to init
It might have made sense once upon a time, but doesn't nowadays when
compilers expand memset inline.
* ecoff.c (add_aux_sym_tir, allocate_scope, allocate_vlinks),
(allocate_shash, allocate_thash, allocate_tag, allocate_forward),
(allocate_thead, allocate_lineno_list): Use memset rather than
copying zero struct.
Andrew Burgess [Thu, 23 Feb 2023 11:45:11 +0000 (11:45 +0000)]
gdb: add gdbarch::displaced_step_buffer_length
The gdbarch::max_insn_length field is used mostly to support displaced
stepping; it controls the size of the buffers allocated for the
displaced-step instruction, and is also used when first copying the
instruction, and later, when fixing up the instruction, in order to
read in and parse the instruction being stepped.
However, it has started to be used in other places in GDB, for
example, it's used in the Python disassembler API, and it is used on
amd64 as part of branch-tracing instruction classification.
The problem is that the value assigned to max_insn_length is not
always the maximum instruction length, but sometimes is a multiple of
that length, as required to support displaced stepping, see rs600,
ARM, and AArch64 for examples of this.
It seems to me that we are overloading the meaning of the
max_insn_length field, and I think that could potentially lead to
confusion.
I propose that we add a new gdbarch field,
gdbarch::displaced_step_buffer_length, this new field will do
exactly what it says on the tin; represent the required displaced step
buffer size. The max_insn_length field can then do exactly what it
claims to do; represent the maximum length of a single instruction.
As some architectures (e.g. i386, and amd64) only require their
displaced step buffers to be a single instruction in size, I propose
that the default for displaced_step_buffer_length will be the
value of max_insn_length. Architectures than need more buffer space
can then override this default as needed.
I've updated all architectures to setup the new field if appropriate,
and I've audited all calls to gdbarch_max_insn_length and switched to
gdbarch_displaced_step_buffer_length where appropriate.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Fri, 10 Mar 2023 15:35:52 +0000 (15:35 +0000)]
gdbarch: make invalid=True the default for all Components
This commit switches the default value for the 'invalid' field from
False to True. All components that previous set the invalid field to
True explicitly have had the field removed.
I think that True is a good choice for the default, this means that we
now get the validity checks by default, and if anyone adds a new
Component they need to make a choice to add an 'invalid=False' line
and disable the validation.
The flip side of this is that 'invalid=False' seems to be far more
common than 'invalid=True'. But I don't see a huge problem with this,
we shouldn't be aiming to reduce our typing, rather we should choose
based on which is least likely to introduce bugs. I think assuming
that we should do a validity check will achieve that.
Some additional components need to have an 'invalid=False' line added
to their definition, these are components that have a predefault
value, which is sufficient; the tdep code doesn't need to replace this
value if it doesn't want to.
Without adding the 'invalid=False' these components would be
considered to be invalid if they have not changed from their
predefault value -- but the predefault is fine.
There's no change in the generated code after this commit, so there
will be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Fri, 10 Mar 2023 15:31:36 +0000 (15:31 +0000)]
gdbarch: remove some unneeded predefault="0" from gdbarch_components.py
I noticed that there are a bunch of 'predefault="0"' lines in
gdbarch_components.py, and that some (just some, not all) of these are
not needed.
The gdbarch is already zero initialized, but these lines seem to
exists so that we can know when to compare against "0" and when to
compare against "NULL". At least, this seems to be useful in some
places in the generated code.
Specifically, if we remove the predefault="0" line from the
max_insn_length component then we end up generating a line like:
gdb_assert (gdbarch->max_insn_length != NULL);
which doesn't compile as we compare a ULONGEST to NULL.
In this commit I remove all the predefault="0" lines that I claim are
obviously not needed. These are lines for components that are not
Values (i.e. the component holds a function pointer anyway), or for
Value components that hold a pointer type, in which case using NULL is
fine.
The only changes after this commit are some fields that have nullptr
as their initial value, and gcore_bfd_target now compares to NULL not
0 in gdbarch_gcore_bfd_target_p, which, given the field is of type
'const char *', seems like an improvement.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Fri, 10 Mar 2023 15:13:55 +0000 (15:13 +0000)]
gdbarch: improve generation of validation in gdbarch getters
We currently generate some validation code within the gdbarch getter
methods.
This commit adjusts the algorithm used to generate this validation
slightly to make the gdbarch.py code (I think) clearer; there's no
significant changes to what is generated.
The validation algorithm for gdbarch values is now:
- If the Value has an 'invalid' field that is a string, use that for
validation,
- If the Value has its 'predicate' field set to true, then check the
predicate returns true, this ensures the predicate has been
called,
- If the Value has its 'invalid' field set to True, or the Value has
'postdefault' field, then check the fields has changed from its
initial value,
- Otherwise no validation is performed.
The only changes after this commit are:
- Some comments change slightly, and
- For 'gcore_bfd_target' and 'max_insn_length' we now validate by
calling the predicate rather than checking the field value
directly, the underlying check being performed is unchanged
though.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
All use a postdefault but no predefault to set the default value for
the component.
As the postdefault values for these components are all constant
pointers that don't depend on other fields within the gdbarch, then I
don't see any reason why we couldn't use a predefault instead.
So lets do that.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Mon, 6 Mar 2023 14:39:28 +0000 (14:39 +0000)]
gdb/gdbarch: remove the 'invalid=None' state from gdbarch_components.py
This commit ensures that the 'invalid' property of all components is
either True, False, or a string.
Additionally, this commit allows a component to have both a predicate
and for the 'invalid' property to be a string.
Removing the option for 'invalid' to be None allows us to simplify the
algorithms in gdbarch.py a little.
Allowing a component to have both a predicate and an 'invalid' string
means that we can validate the value that a tdep sets into a field,
but also allow a predicate to ensure that the field has changed from
the default.
This functionality isn't going to be used in this series, but I have
tested it locally and believe that it would work, and this might make
it easier for others to add new components in the future.
In gdbarch_types.py, I've updated the type annotations to show that
the 'invalid' field should not be None, and I've changed the default
for this field from None to False.
The change to using False as the default is temporary. Later in this
series I'm going to change the default to True, but we need more fixes
before that can be done.
Additionally, in gdbarch_types.py I've removed an assert from
Component.get_predicate. This assert ensured that we didn't have the
predicate field set to True and the invalid field set to a string.
However, no component currently uses this configuration, and after
this commit, that combination is now supported, so the assert can be
removed.
As a consequence of the gdbarch_types.py changes we see some
additional comments generated in gdbarch.c about verification being
skipped due to the invalid field being False. This comment is inline
with plenty of other getters that also have a similar comment. Plenty
of the getters do have validation, so I think it is reasonable to have
a comment noting that the validation has been skipped for a specific
reason, rather than due to some bug.
In gdbarch_components.py I've had to add 'invalid=True' for two
components: gcore_bfd_target and max_insn_length, without this the
validation in the gdbarch getter would disappear.
And in gdbarch.py I've reworked the logic for generating the
verify_gdbarch function, and for generating the getter functions.
The logic for generating the getter functions is still not ideal, I
ended up having to add this additional logic block:
elif c.postdefault is not None and c.predefault is not None:
print(" /* Check variable changed from pre-default. */", file=f)
print(f" gdb_assert (gdbarch->{c.name} != {c.predefault});", file=f)
which was needed to ensure we continued to generate the same code as
before, without this the fact that invalid is now False when it would
previously have been None, meant that we dropped the gdb_assert in
favour of a comment like:
Andrew Burgess [Thu, 23 Feb 2023 18:18:45 +0000 (18:18 +0000)]
gdb/gdbarch: split postdefault setup from invalid check in gdbarch.py
Restructure how gdbarch.py generates the verify_gdbarch function.
Previously the postdefault handling was bundled together with the
validation. This means that a field can't have both a postdefault,
and set its invalid attribute to a string.
This doesn't seem reasonable to me, I see no reason why a field can't
have both a postdefault (used when the tdep doesn't set the field),
and an invalid expression, which can be used to validate the value
that a tdep might set.
In this commit I restructure the verify_gdbarch generation code to
allow the above, there is no change in the actual generated code in
this commit, that will come in later commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Mon, 6 Mar 2023 11:45:12 +0000 (11:45 +0000)]
gdb/gdbarch: remove yet more 'invalid=True' from gdbarch_components.py
Following on from the previous commit, this commit removes yet more
'invalid=True' lines from gdbarch_components.py where the invalid
setting has no effect.
Due to the algorithm used in gdbarch.py for generated verify_gdbarch,
if a component has a postdefault value then no invalid check will ever
be generated for the component, as such setting 'invalid=True' on the
component is pointless. This commit removes the setting of invalid.
There is no change in the generated code after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Mon, 6 Mar 2023 11:40:51 +0000 (11:40 +0000)]
gdb/gdbarch: remove unused 'invalid=True' from gdbarch_components.py
Due to the algorithm used to generate verify_gdbarch in gdbarch.py, if
a component has a predicate, then a validation check will never be
generated.
There are a bunch of components that are declared with both a
predicate AND have 'invalid=True' set. The 'invalid=True' has no
effect.
In this commit I clean things up by removing all these additional
'invalid=True' lines. There's no change in any of the generated files
after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Fri, 24 Feb 2023 17:40:16 +0000 (10:40 -0700)]
Fix crash in inside_main_func
gdb 13.1 crashes while running the rust compiler's debugger tests.
The crash has a number of causes.
First, the rust compiler still uses the C++-like _Z mangling, but with
its own twist -- some hex digits added to the end of a symbol. So,
while gdb finds the correct name of "main":
(top-gdb) p name
$13 = 0x292e0c0 "rustc_gdb_1031745::main"
It isn't found in the minsyms, because C++ demangling yields:
[99] t 0x90c0 _ZN17rustc_gdb_10317454main17h5b5be7fe16a97225E section .text rustc_gdb_1031745::main::h5b5be7fe16a97225 zko06yobckx336v
This could perhaps be fixed. I also filed a new PR to suggest
preferring the linkage name of the main program.
Next, the rust compiler emits both a DW_TAG_subprogram and a
DW_TAG_namespace for "main". This happens because the file is named
"main.rs" -- i.e., the bug is specific to the source file name. The
crash also seems to require the nested function inside of 'main', at
least for me. The namespace always is generated, but perhaps this
changes the ordering in the DWARF.
When inside_main_func looks up the main symbol, it finds the namespace
symbol rather than the function. (I filed a bug about fixing gdb's
symbol tables -- long overdue.)
Meanwhile, as I think it's important to fix this crash sooner rather
than later, this patch changes inside_main_func to check that the
symbol that is found is LOC_BLOCK. This perhaps should have been done
in the first place, anyway.
Tom de Vries [Mon, 13 Mar 2023 16:20:09 +0000 (17:20 +0100)]
[gdb/testsuite] Fix gdb.python/tui-window-factory.exp for remote host
When running gdb.python/tui-window.exp with host board
local-remote-host-notty and target board native-gdbserver, I get:
...
FAIL: gdb.python/tui-window-factory.exp: msg_2: \
check test_window box (box check: ul corner is l, not +)
...
The problem is that the result of Term::prepare_for_tui is not checked.
Tom de Vries [Mon, 13 Mar 2023 16:20:09 +0000 (17:20 +0100)]
[gdb/testsuite] Fix gdb.python/tui-window.exp for remote host
When running gdb.python/tui-window.exp with host board
local-remote-host-notty and target board native-gdbserver, I get:
...
UNSUPPORTED: gdb.python/tui-window.exp: TUI not supported
FAIL: gdb.python/tui-window.exp: test title
...
Fix this by adding the missing return after the unsupported.
Tom de Vries [Mon, 13 Mar 2023 16:20:09 +0000 (17:20 +0100)]
[gdb/testsuite] Require ![is_remote host] for TUI
When running test-case gdb.tui/corefile-run.exp with both host and target board
local-remote-host-native.exp, we run into:
...
FAIL: gdb.tui/corefile-run.exp: load corefile
...
while this passes with USE_TUI=0.
The problem is that the TUI setup code uses "setenv TERM ansi", which has no
effect on remote host.
I can confirm this analysis by working around this problem in
local-remote-host-native.exp like this:
...
- spawn $RSH -t -l $username $remote $cmd
+ spawn $RSH -t -l $username $remote "export TERM=ansi; $cmd"
...
For now, simply make TUI unsupported for remote host, by returning 0 in
prepare_for_tui.
Tom de Vries [Mon, 13 Mar 2023 16:20:09 +0000 (17:20 +0100)]
[gdb/testsuite] Handle USE_TUI in gdb.tui/corefile-run.exp
Once in a while I find myself rewriting a TUI test-case into a non-TUI
test-case, to better understand whether the problem I'm looking at is
related to the TUI or not.
I've got the impression that I've done this sufficiently often that it's worth
committing the non-TUI version, so having just written a non-TUI version of
gdb.tui/corefile-run.exp, let's commit it.
The non-TUI version can be enabled by doing:
...
$ make check "RUNTESTFLAGS=gdb.tui/corefile-run.exp USE_TUI=0"
...
Tom de Vries [Mon, 13 Mar 2023 16:20:09 +0000 (17:20 +0100)]
[gdb/testsuite] Fix untested message in gdb.tui/corefile-run.exp
In test-case gdb.tui/corefile-run.exp, we have this bit:
...
require !use_gdb_stub
if { [target_info gdb_protocol] == "extended-remote" } {
untested "not supported"
return
}
...
So with target board native-gdbserver we get:
...
UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: !use_gdb_stub
...
and with target board native-extended-gdbserver instead:
...
UNTESTED: gdb.tui/corefile-run.exp: not supported
...
Fix this by:
- adding an optional argument target_description to proc
target_can_use_run_cmd
- handling the target_description == core &&
[target_info gdb_protocol] == "extended-remote" case in the proc
- using require {target_can_use_run_cmd core}
such that now in both cases we have:
...
UNSUPPORTED: gdb.tui/corefile-run.exp: require failed: \
target_can_use_run_cmd core
...
Tom de Vries [Mon, 13 Mar 2023 15:47:25 +0000 (16:47 +0100)]
[gdb/testsuite] Fix gdb.threads/step-bg-decr-pc-switch-thread.exp for native-gdbserver
With test-case gdb.threads/step-bg-decr-pc-switch-thread.exp and target board
native-gdbserver, I run into:
...
(gdb) UNSUPPORTED: gdb.threads/step-bg-decr-pc-switch-thread.exp: \
switch to main thread
Remote debugging from host ::1, port 43914^M
monitor exit^M
Cannot execute this command while the target is running.^M
Use the "interrupt" command to stop the target^M
and then try again.^M
(gdb) WARNING: Timed out waiting for EOF in server after monitor exit
...
Fix this by following the advice and issuing an interrupt command, allowing
the following monitor exit command to succeed.
Bruno Larsen [Thu, 23 Feb 2023 12:56:32 +0000 (13:56 +0100)]
gdb/testsuite: add regression test for per-objfile typeprinters
PR python/17136 reported an unhandled exception when using typeprinters
only valid on some objfiles, rather than being a global typeprinter. The
fix was accepted without a regression test, and we've been carrying one
out-of-tree for a while but I think it's worth upstreaming. The code
itself was developed by Jan Kratochvil.
Co-Authored-By: Jan Kratochvil <jkratochvil@azul.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17136 Reviewed-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Wed, 1 Mar 2023 21:02:40 +0000 (14:02 -0700)]
Remove dead code from scalar_binop
scalar_binop has code for "&&" and "||", but I think this code can't
currently be run -- and, furthermore, it doesn't make sense to have
this code here, as the point of these operators is to short-circuit
evaluation.
Luis Machado [Tue, 21 Feb 2023 19:43:22 +0000 (19:43 +0000)]
aarch64: Expand documentation of XML features
Similar to the arm target documentation situation, the documentation of the
XML features for AArch64 targets is rather brief. I have received the same
feedback that what gdb carries in the documentation is quite unclear from the
perspective of what debugging servers should define in the XML features, how and
what the outcome is in gdb.
This patch attempts to clarify a bit more what all the possible features are.
Luis Machado [Tue, 21 Feb 2023 10:33:19 +0000 (10:33 +0000)]
arm: Expand documentation of XML features
The documentation of the XML features for Arm targets is very brief. I have
received feedback saying it is quite unclear from the perspective of the
debugging servers what should be defined in the XML features, how and
what the outcome is in gdb.
This patch attempts to clarify a bit more what all the possible features are.
Tom Tromey [Tue, 7 Mar 2023 23:24:11 +0000 (16:24 -0700)]
Remove extra scopes from objfile_relocate1
objfile_relocate1 introduces new scopes that aren't necessary. I
noticed this while working on an earlier patch in this series. This
patch removes these.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Wed, 8 Mar 2023 01:16:29 +0000 (18:16 -0700)]
Constify linetables
Linetables no longer change after they are created. This patch
applies const to them.
Note there is one hack to cast away const in mdebugread.c. This code
allocates a linetable using 'malloc', then later copies it to the
obstack. While this could be cleaned up, I chose not to do so because
I have no way of testing it.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Wed, 8 Mar 2023 00:37:45 +0000 (17:37 -0700)]
Change linetables to be objfile-independent
This changes linetables to not add the text offset to the addresses
they contain. I did this in a few steps, necessarily combined
together in one patch: I renamed the 'pc' member to 'm_pc', added the
appropriate accessors, and then recompiled. Then I fixed all the
errors. Where possible I generally chose to use the raw_pc accessor,
as it is less expensive.
Note that this patch discounts the possibility that the text section
offset might cause wraparound in the addresses in the line table.
However, this was already discounted -- in particular,
objfile_relocate1 did not re-sort the table in this scenario. (There
was a bug open about this, but as far as I can tell this has never
happened, it's not even clear what inspired that bug.)
Approved-By: Simon Marchi <simon.marchi@efficios.com>
John Baldwin [Fri, 10 Mar 2023 20:01:40 +0000 (12:01 -0800)]
PR gdb/30214: Prefer local include paths to system include paths
Some systems may install binutils headers into a system location
(e.g. /usr/local/include on FreeBSD) which may also include headers
for other external packages used by GDB such as zlib or zstd. If a
system include path such as /usr/local/include is added before local
include paths to directories within a clone or release tarball, then
headers from the external binutils package are used which can result
in build failures if the external binutils package is out of sync with
the version of GDB being built.
To fix, sort the include paths in INTERNAL_CFLAGS_BASE to add CFLAGS
for "local" componenets before external components.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30214 Reviewed-By: Tom Tromey <tom@tromey.com>
% gcc -m32 -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
/usr/bin/ld.bfd: /tmp/ccR8Yexy.o: TLS transition from R_386_TLS_GD to R_386_TLS_IE_32 against `a' at 0x15 in section `.text' failed
/usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
This commit fixes the issue.
There is an argument that the -fno-plt TLS sequence was added after
R_386_GOT32X was required for call *func@GOT(%ebx), so R_386_GOT32 was
intended to be unsupported.
Unfortunately this standpoint has caused interop difficulty: some
projects specify -mrelax-relocations=no to build relocatable object
files compatible with older linkers (e.g.
https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
(e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
today). Many uses have not been cleaned up in practice, and compiling
with -fno-plt will lead to the `TLS transition from R_386_TLS_GD ...`
error which is hard to reason about.
It seems easier to apply this simple change to prevent the footgun.
Fangrui Song [Fri, 10 Mar 2023 19:53:32 +0000 (11:53 -0800)]
ld: Allow R_X86_64_GOTPCREL for call *__tls_get_addr@GOTPCREL(%rip)
_Thread_local int a;
int main() { return a; }
% gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no
/usr/bin/ld.bfd: /tmp/ccSSBgrg.o: TLS transition from R_X86_64_TLSGD to R_X86_64_GOTTPOFF against `a' at 0xd in section `.text' failed
/usr/bin/ld.bfd: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status
This commit fixes the issue.
There is an argument that the -fno-plt TLS sequence was added after
R_X86_64_GOTPCRELX was required for call, so R_X86_64_GOTPCREL was
intended to be unsupported.
Unfortunately this standpoint has caused interop difficulty: some
projects specify -mrelax-relocations=no to build relocatable object
files compatible with older linkers (e.g.
https://github.com/IHaskell/IHaskell/issues/636) or do so by accident
(e.g. https://github.com/rust-lang/rust/pull/106511 not addressed as of
today). Many uses have not been cleaned up in practice, and compiling
with -fno-plt will lead to the `TLS transition from R_X86_64_TLSGD ...`
error which is hard to reason about.
There is another argument which may be weaker but relevant to the
necessity of -mrelax-relocations=no: HWAddressSanitizer x86-64 will
likely need some assembler support to disable relaxation. Without the
support and if the compiler needs to support many gas version, the
simplest solution would be to use -Wa,-mrelax-relocations=no.
Tom de Vries [Fri, 10 Mar 2023 15:34:04 +0000 (16:34 +0100)]
[gdb/testsuite] Fix gdb.python/py-completion.exp
With test-case gdb.python/py-completion.exp and target board
native-extended-gdbserver I get this warning:
...
(gdb) PASS: gdb.python/py-completion.exp: discard #2
completefilecommandcond $outputs/gdb.python/py-completion/py-completion-t^G\
PASS: gdb.python/py-completion.exp: completefilecommandcond completion
Remote debugging from host ::1, port 53346^M
monitor exit^M
not implemented^M
(gdb) WARNING: Timed out waiting for EOF in server after monitor exit
...
Fix this by adding the missing "discard #3", such that we have instead:
...
(gdb) PASS: gdb.python/py-completion.exp: discard #2
completefilecommandcond $outputs/gdb.python/py-completion/py-completion-t^G\
PASS: gdb.python/py-completion.exp: completefilecommandcond completion
^M
not implemented^M
(gdb) PASS: gdb.python/py-completion.exp: discard #3
Remote debugging from host ::1, port 36278^M
monitor exit^M
(gdb)
...
Tom de Vries [Fri, 10 Mar 2023 15:34:04 +0000 (16:34 +0100)]
[gdb/testsuite] Fix gdb.python/py-cmd.exp
[ Using $pp as shorthand for the pagination prompt
"--Type <RET> for more, q to quit, c to continue without paging--". ]
The test-case gdb.python/py-cmd.exp passes, but the handling of the
test_multiline command output looks a bit odd:
...
(gdb) test_multiline
test_multiline output
...
test_multiline output
$ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline
q
test_multiline
Quit
(gdb) test_multiline
test_multiline output
...
test_multiline output
$ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline: q
...
What happens is:
- a test_multiline command is issued
- some output is printed, followed by a pagination prompt
- the test-case concludes that pagination occurred, and produces a PASS
- "q\n" is replied to the pagination prompt
- without waiting for response to the "q\n", another test_multiline command is
issued
- in response to the "q\n" we get "Quit\n(gdb) "
- some output is printed, followed by a pagination prompt
- the test-case concludes that there's a valid response to the "q\n", and
produces a PASS, consuming the second pagination prompt, but without a reply.
My conclusion is that the second test_multiline command is unintentional, so fix
this by removing it.
Without it, we have the more straightforward:
...
(gdb) test_multiline
test_multiline output
...
test_multiline output
$ppPASS: gdb.python/py-cmd.exp: verify pagination from test_multiline
q
Quit
(gdb) PASS: gdb.python/py-cmd.exp: verify pagination from test_multiline: q
...
This also fixes the following warning with target board native-gdbserver:
...
WARNING: Timed out waiting for EOF in server after monitor exit
...
Tom de Vries [Fri, 10 Mar 2023 15:34:04 +0000 (16:34 +0100)]
[gdb/testsuite] Fix py-autoloaded-pretty-printers-in-newobjfile-event.exp for remote target
With test-case gdb.python/py-autoloaded-pretty-printers-in-newobjfile-event.exp
and target board remote-gdbserver-on-localhost, I run into:
...
FAIL: $exp: runto: run to main
...
I can easily fix this using "gdb_load_shlib $binfile_lib", but then run into:
...
(gdb) print all_good^M
$1 = false^M
(gdb) FAIL: $exp: print all_good
info pretty-printer^M
...
Sysroot is set to "target:", so gdb downloads the shared library from the target
(Using $so as shorthand for
libpy-autoloaded-pretty-printers-in-newobjfile-event.so):
...
Reading /home/remote-target/$so from remote target...^M
...
and internally refers to it as "target:/home/remote-target/$so".
In load_auto_scripts_for_objfile, gdb gives up trying to auto-load scripts
for $so once it checks for is_target_filename.
Fix this by declaring auto-load unsupported if sysroot starts with "target:".
Tom Tromey [Wed, 22 Feb 2023 21:49:47 +0000 (14:49 -0700)]
Use require with target_info
This changes many tests to use 'require' when checking target_info.
In a few spots, the require is hoisted to the top of the file, to
avoid doing any extra work when the test is going to be skipped
anyway.
Tom Tromey [Fri, 24 Feb 2023 20:55:29 +0000 (13:55 -0700)]
Move allocate_stub_method to stabsread.c
allocate_stub_method is only called from stabsread.c, and I don't
think it will be needed anywhere else. So, move it and make it
static. Tested by rebuilding.
projects / thirdparty / binutils-gdb.git / log
