As far as I can see, there are no more spots looking for a remote_debug
other than true/false. If we ever want to revert to an int, we can
always change it back later, but this makes things simpler for now.
gdb/ChangeLog:
* remote.h (remote_debug): Change to bool.
* remote.c (remote_debug): Change to bool.
(_initialize_remote): Adjust.
Change-Id: I21aac5b4cff9dc4f75c8efaf47c23583ecabd2a6
remote_debug is currently declared in target.h and defined in top.c.
Move them to remote.h and remote.c.
Include remote.h in remote-sim.c, as it uses remote_debug.
gdb/ChangeLog:
* target.h (remote_debug): Move to...
* remote.h (remote_debug): ... here.
* top.c (remote_debug): Move to...
* remote.c (remote_debug): ... here.
* remote-sim.c: Include remote.h.
Change-Id: Iae632d12ff8900b23eee6b2529d6a3cd339a8caa
Commands "set debug remote" and "set remotetimeout" are defined in
cli/cli-cmds.c, I think it would make more sense for them to be in
remote.c.
gdb/ChangeLog:
* cli/cli-cmds.c (show_remote_debug): Remove.
(show_remote_timeout): Remove.
(_initialize_cli_cmds): Don't register commands.
* remote.c (show_remote_debug): Move here.
(show_remote_timeout): Move here.
(_initialize_remote): Register commands.
Change-Id: Ic4d81888aa4f8dde89d1d29397ef19a08951b80b
Change all users to use the type::objfile method instead.
gdb/ChangeLog:
* gdbtypes.h (TYPE_OBJFILE): Remove, change all users to use the
type::objfile method instead.
Change-Id: I6b3f580913fb1fb0cf986b176dba8db68e1fabf9
Update all users to use the type::is_objfile_owned method.
gdb/ChangeLog:
* gdbtypes.h (TYPE_OBJFILE_OWNED): Remove, update all users to
use the type::is_objfile_owned method.
Change-Id: Icae84d136393ab9f756f50a33ac3cedda13c5ba2
Add the following methods to struct type:
* is_objfile_owned
* set_owner (objfile and gdbarch overloads)
* objfile and arch getters
Rename the fields in main_type to ensure no other code accesses them
directly. As usual, we can't make them actually private, but giving
them the `m_` prefix will help making sure they are not accessed when
not supposed to, by convention.
Remove the TYPE_OWNER macro to ensure no code uses the type_owner struct
directly.
gdb/ChangeLog:
* gdbtypes.h (TYPE_OBJFILE_OWNED): Adjust.
(TYPE_OWNER): Remove.
(TYPE_OBJFILE): Adjust.
(struct main_type) <flag_objfile_owned>: Rename to...
<m_flag_objfile_owned>: ... this.
<owner>: Rename to...
<m_owner>: ... this.
(struct type) <is_objfile_owned, set_owner, objfile, arch>: New
methods.
(TYPE_ALLOC): Adjust.
* gdbtypes.c (alloc_type): Adjust.
(alloc_type_arch): Adjust.
(alloc_type_copy): Adjust.
(get_type_arch): Adjust.
(smash_type): Adjust.
(lookup_array_range_type): Adjust.
(recursive_dump_type): Adjust.
(copy_type_recursive): Adjust.
* compile/compile-c-types.c (convert_func): Adjust.
(convert_type_basic): Adjust.
* compile/compile-cplus-types.c (compile_cplus_convert_func):
Adjust.
* language.c
(language_arch_info::type_and_symbol::alloc_type_symbol):
Adjust.
Change-Id: I7f92e869d9f92e2402a3d3007dd0832e05aa6ac8
Commit:
commit a72d0f3d69
Date: Tue Jan 12 13:02:30 2021 +0000
gdb/doc: reorder and group sections relating to aliases
Added a @menu block into the wrong place within a @node. This commit
moves it to the end of the @node, where it should be been placed.
gdb/doc/ChangeLog:
* gdb.texinfo (Aliases): Move @menu to the end of the node.
After a discussion on a recent patch it was pointed out that the
contents of a @var should (generally) be lower case. I took a look
through the GDB manual and there are a small number of places where
the contents are currently upper case, but one in particular seemed
like an obvious candidate for being down cased, so lets do that.
gdb/doc/ChangeLog:
* gdb.texinfo (PowerPC Embedded): Down case contents of @var.
On Ubuntu 18.04/20.04 I was running into annoying timeouts for
gdb.server/server-connect.exp. Those were caused by the ipv6 tests, because
they were running into the "Cannot assign requested address" error, originated
from the connect syscall.
Improve this by handling this additional error in the testsuite library.
It still fails for me, but at least it fails pretty quickly and doesn't make the
testsuite run take longer.
gdb/testsuite/ChangeLog:
2021-01-21 Luis Machado <luis.machado@linaro.org>
* lib/gdbserver-support.exp (gdb_target_cmd_ext): Handle a new error
message.
When building for 32-bit ARM, I ran into a couple build failures.
The first one seems to be caused by recent changes to warning switches,
leading to the following error:
--
In file included from gdb/coffread.c:35:0:
gdb/coffread.c: In function "void enter_linenos(file_ptr, int, int, objfile*)":
gdb/complaints.h:40:40: error: format "%ld" expects argument of type "long int", but argument 2 has type "file_ptr {aka long long int}" [-Werror=format=]
complaint_internal (FMT, ##__VA_ARGS__); \
^
gdb/coffread.c:1413:7: note: in expansion of macro "complaint"
complaint (_("Line number pointer %ld lower than start of line numbers"),
^~~~~~~~~
--
The other one is due to a narrowing conversion in valops.c:
--
gdb/valops.c: In function "value* value_assign(value*, value*)":
gdb/gdbtypes.h:1798:43: error: narrowing conversion of "type->type::length" from "ULONGEST {aka long long unsigned int}" to "size_t {aka unsigned int}" inside { } [-Werror=narrowing]
#define TYPE_LENGTH(thistype) (thistype)->length
~~~~~~~~~~~~^
gdb/valops.c:1252:9: note: in expansion of macro "TYPE_LENGTH"
TYPE_LENGTH (type)});
--
Fix both with the following patch. Validated with --enable-targets=all on
Ubuntu 18.04/20.04.
gdb/ChangeLog:
2021-01-21 Luis Machado <luis.machado@linaro.org>
* coffread.c (enter_linenos): Passing string to complaint.
* valops.c (value_assign): Make array view.
Function file_is_auto_load_safe was taking a format string and varargs
just to output a debug print. This is probably because that function is
used in linux-thread-db.c and main.c, but debug_auto_load is static in
auto-load.c. I simplified that, making debug_auto_load visible outside
of auto-load.c, and making the callers of file_is_auto_load_safe output
the debug print themselves.
This file uses _() for internationalization of the debug messages. This
is not necessary, as these are mostly messages for GDB developers, and
it's not used in other files anyway. So I removed them.
The rest is pretty much standard.
gdb/ChangeLog:
* auto-load.h (debug_auto_load): Move here.
(auto_load_debug_printf): New.
* auto-load.c: Use auto_load_debug_printf.
(debug_auto_load): Move to header.
* linux-thread-db.c (try_thread_db_load): Use
auto_load_debug_printf.
* main.c (captured_main_1): Likewise.
Change-Id: I468dc2a1d24b7dbf171f55181a11abbfafe70ba1
This variable appears to be unused. Its uses were removed in commit
3e2e34f862 ("fort_dyn_array: Use value constructor instead of
raw-buffer manipulation.") back in 2016.
gdb/ChangeLog:
* f-valprint.c (f77_array_offset_tbl): Remove.
Change-Id: I39ff8d1b402e54ca2ade936f65e540f500cce86e
When GDB is waiting trying to connect to a remote target and it receives
a SIGWINCH (terminal gets resized), the blocking system call gets
interrupted and we abort.
For example, I connect to some port (on which nothing listens):
(gdb) tar rem :1234
... GDB blocks here, resize the terminal ...
🔢 Interrupted system call.
The backtrace where GDB is blocked while waiting for the connection to
establish is:
#0 0x00007fe9db805b7b in select () from /usr/lib/libc.so.6
#1 0x000055f2472e9c42 in gdb_select (n=0, readfds=0x0, writefds=0x0, exceptfds=0x0, timeout=0x7ffe8fafe050) at /home/simark/src/binutils-gdb/gdb/posix-hdep.c:31
#2 0x000055f24759c212 in wait_for_connect (sock=-1, polls=0x7ffe8fafe300) at /home/simark/src/binutils-gdb/gdb/ser-tcp.c:147
#3 0x000055f24759d0e8 in net_open (scb=0x62500015b900, name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/ser-tcp.c:356
#4 0x000055f2475a0395 in serial_open_ops_1 (ops=0x55f24892ca60 <tcp_ops>, open_name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/serial.c:244
#5 0x000055f2475a01d6 in serial_open (name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/serial.c:231
#6 0x000055f2474d5274 in remote_serial_open (name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/remote.c:5019
#7 0x000055f2474d7025 in remote_target::open_1 (name=0x6020000601d8 ":1234", from_tty=1, extended_p=0) at /home/simark/src/binutils-gdb/gdb/remote.c:5571
#8 0x000055f2474d47d5 in remote_target::open (name=0x6020000601d8 ":1234", from_tty=1) at /home/simark/src/binutils-gdb/gdb/remote.c:4898
#9 0x000055f24776379f in open_target (args=0x6020000601d8 ":1234", from_tty=1, command=0x611000042bc0) at /home/simark/src/binutils-gdb/gdb/target.c:242
Fix that by using interruptible_select in wait_for_connect, instead of
gdb_select. Resizing the terminal now no longer aborts the connection.
It is still possible to interrupt the connection using ctrl-c.
gdb/ChangeLog:
* ser-tcp.c (wait_for_connect): Use interruptible_select instead
of gdb_select.
Change-Id: Ie25577bd1e5699e4847b6b53fdfa10b8c0dc5c89
Here's a bonus patch that applies on top of the other two.
While debugging TUI test cases, it's hard to know what exactly is
happening in the little mind of the terminal emulator. Add some logging
for all input processing. Right now I'm interested in seeing what
happens to the cursor position, so made it so all operations log the
"before" and "after" cursor position. It should help see if any
operation is not behaving as expected, w.r.t. the cursor position.
Here are some examples of the logging found in gdb.log with this patch
applied:
+++ Inserting string '+|'
+++ Inserted char '+', cursor: (0, 79) -> (1, 0)
+++ Inserted char '|', cursor: (1, 0) -> (1, 1)
+++ Inserted string '+|', cursor: (0, 79) -> (1, 1)
+++ Cursor Horizontal Absolute (80), cursor: (1, 1) -> (1, 79)
In the last line, note that the argument is 80 and we move to 79, that's
because the position in the argument to the control sequence is 1-based,
while our indexing is 0-based.
gdb/testsuite/ChangeLog:
* lib/tuiterm.exp (_log, _log_cur): New, use throughout.
Change-Id: Ibf570d4b2867729ce65bea8c193343a8a846170d
This started by observing that the section name:
Automatically prepend default arguments to user-defined aliases
Is very long. When this is rendered in the PDF manual (at least for
me), this name is so long that in the table of contents the page
number ends up being misaligned.
My first thought was we could drop the 'to user-defined aliases' bit
if this section became a sub-section of the section on aliases.
So then I looked for a section with 'aliases' in its name, and
couldn't find one.
It turns out that aliases are documented in a section called:
Creating new spellings of existing commands
Which (to me) seems an odd aspect of aliases to emphasise.
So, in this patch I make the following changes:
- Move the section on aliases earlier in the manual, this is now
immediately after the section about creating user defined
commands. This made more sense to me.
- Rename the section on aliases from 'Creating new spellings of
existing commands' to 'Command Aliases'.
- Update the wording of the first paragraph in the 'Command Aliases'
section so that it reads better given the new name.
- Add a cross-reference from the 'Command Aliases' section to the
'Python' section now that the aliases section comes first.
- Down case all the text inside @var within this section as this is
the correct style for the GDB manual.
- Move the section on default args to become a sub-section of the
'Command Aliases' section, and rename this sub-section from
'Automatically prepend default arguments to user-defined aliases'
to 'Default Arguments'.
- Add @menu into the 'Command Aliases' section to link to the
'Default Arguments' subsection.
- Add a @cindex entry to the default arguments sub-section.
gdb/doc/ChangeLog:
* gdb.texinfo (Commands): Update menu.
(Extending GDB): Likewise.
(Command aliases default args): Moved later into the document,
added a cindex entry. Renamed the section 'Automatically prepend
default arguments to user-defined aliases' to 'Default Arguments'.
(Aliases): Moved earlier in the document. Minor rewording of the
first paragraph, down-cased the text inside all uses of @var, and
added a cross reference to the Python code. Renamed the section
'Creating new spellings of existing commands' to 'Command
Aliases'.
This allows the creation of hardware breakpoints in Python with
gdb.Breakpoint(type=gdb.BP_HARDWARE_BREAKPOINT)
And they are included in the sequence returned by gdb.breakpoints().
gdb/ChangeLog:
2021-01-21 Hannes Domani <ssbssa@yahoo.de>
PR python/19151
* python/py-breakpoint.c (bppy_get_location): Handle
bp_hardware_breakpoint.
(bppy_init): Likewise.
(gdbpy_breakpoint_created): Likewise.
gdb/doc/ChangeLog:
2021-01-21 Hannes Domani <ssbssa@yahoo.de>
PR python/19151
* python.texi (Breakpoints In Python): Document
gdb.BP_HARDWARE_BREAKPOINT.
gdb/testsuite/ChangeLog:
2021-01-21 Hannes Domani <ssbssa@yahoo.de>
PR python/19151
* gdb.python/py-breakpoint.exp: Add tests for hardware breakpoints.
PR 27221
* dwarf2dbg.c (dwarf2_gen_line_info_1): Don't warn about ignored
line number info when gas is generating it.
* testsuite/gas/elf/dwarf2-20.d: Adjust to not expect warnings.
* testsuite/gas/m68hc11/indexed12.d: Likewise.
* testsuite/gas/elf/elf.exp: Don't run warn-2.
* gas/testsuite/gas/elf/warn-2.s: Delete.
git commit 994b251328 "Ignore section symbols when matching linkonce
with comdat" cured the reason why this test used to fail on mips.
* testsuite/ld-elf/pr26936.d: No longer xfail mips.
This will make it easier to modify, in particular add some indentation.
It is also a bit nicer to read, in my opinion.
gdb/testsuite/ChangeLog;
* gdb.base/skip.exp: Use multi_line where relevant.
Change-Id: Ia11712aac77344e0b8a836f4181d67e1cad3826c
The symptom that leads to this is the crash described in PR 26828:
/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:23478:25: runtime error: member access within null pointer of type 'struct dwarf2_cu'
The line of the crash is the following, in follow_die_offset:
if (target_cu != cu)
target_cu->ancestor = cu; <--- HERE
The line that assign nullptr to `target_cu` is the `per_objfile->get_cu`
call after having called maybe_queue_comp_unit:
/* If necessary, add it to the queue and load its DIEs. */
if (maybe_queue_comp_unit (cu, per_cu, per_objfile, cu->language))
load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu (per_cu),
false, cu->language);
target_cu = per_objfile->get_cu (per_cu); <--- HERE
Some background: there is an invariant, documented in
maybe_queue_comp_unit's doc, that if a CU is queued for expansion
(present in dwarf2_per_bfd::queue), then its DIEs are loaded in memory.
"its DIEs are loaded in memory" is a synonym for saying that a dwarf2_cu
object exists for this CU. Yet another way to say it is that
`per_objfile->get_cu (per_cu)` returns something not nullptr for that
CU.
The crash documented in PR 26828 triggers some hard-to-reproduce
sequence that ends up violating the invariant:
- dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A
- The DIE in CU A requires some DIE in CU B
- follow_die_offset calls maybe_queue_comp_unit. maybe_queue_comp_unit
sees CU B is not queued and its DIEs are not loaded, so it enqueues it
and returns 1 to its caller - meaning "the DIEs are not loaded, you
should load them" - prompting follow_die_offset to load the DIEs by
calling load_full_comp_unit
- Note that CU B is enqueued by maybe_queue_comp_unit even if it has
already been expanded. It's a bit useless (and causes trouble, see
next patch), but that's how it works right now.
- Since we entered the dwarf2/read code through
dwarf2_fetch_die_type_sect_off, nothing processes the queue, so we
exit the dwarf2/read code with CU B still lingering in the queue.
- dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A, again
- The DIE in CU A requires some DIE in CU B, again
- This time, maybe_queue_comp_unit sees that CU B is in the queue.
Because of the invariant that if a CU is in the queue, its DIEs are
loaded in the memory, it returns 0 to its caller, meaning "you don't
need to load the DIEs!".
- That happens to be true, so everything is fine for now.
- Time passes, some things call dwarf2_per_objfile::age_comp_units
enough so that CU B's age becomes past the dwarf_max_cache_age
threshold. age_comp_units proceeds to free CU B's DIEs. Remember
that CU B is still lingering in the queue (oops, the invariant just
got violated).
- dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A, again
- The DIE in CU A requires some DIE in CU B, again
- maybe_queue_comp_unit sees that CU B is in the queue, so returns to
its caller "you don't need to load the DIEs!". However, we know at
this point this is false.
- follow_die_offset doesn't load the DIEs and tries to obtain the DIEs for
CU B:
target_cu = per_objfile->get_cu (per_cu);
But since they are not loaded, target_cu is nullptr, and we get the
crash mentioned above a few lines after that.
This patch adds an assertions in maybe_queue_comp_unit to verify the
invariant, to make sure it doesn't return a falsehood to its caller.
The current patch doesn't fix the issue (the next patch does), but it
makes it so we catch the problem earlier and get this assertion failure
instead of a segmentation fault:
/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9100: internal-error:
int maybe_queue_comp_unit(dwarf2_cu*, dwarf2_per_cu_data*, dwarf2_per_objfile*, language):
Assertion `per_objfile->get_cu (per_cu) != nullptr' failed.
gdb/ChangeLog:
PR gdb/26828
* dwarf2/read.c (maybe_queue_comp_unit): Add assertion.
Change-Id: I4e51bd7bd58773f9fadf480179cbc4bae61508fe
This patch adds some logging that helped me diagnose the problems fixed
later in this series. I'm thinking that if it helped me now, it could
help somebody else (or myself) in the future, so I might as well add
them for real.
They can happen quite frequently and be noisy, so I used
dwarf_read_debug_printf_v for them, which means they'll only print if
`set debug dwarf-read` is >= 2.
gdb/ChangeLog:
* dwarf2/read.c (follow_die_offset): Add logging.
(dwarf2_per_objfile::age_comp_units): Add logging.
Change-Id: I7483c0b05c37bc9710b9b5d40e272935bc010863
When building with gcc 4.8, we get:
CXX remote.o
cc1plus: warning: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ [enabled by default]
/home/smarchi/src/binutils-gdb/gdb/remote.c:1157:38: error: 'resume_state' is not a class, namespace, or enumeration
enum resume_state m_resume_state = resume_state::NOT_RESUMED;
^
It looks like gcc 4.8 doesn't like that there is an enum class named
resume_state as well as a method. Since it's an easy fix, rename the method to
get_remote_state to avoid the clash.
gdb/ChangeLog:
PR gdb/27219
* remote.c (struct remote_thread_info) <resume_state>: Rename
to...
<get_resume_state>: ... this.
(remote_target::resume): Adjust.
(remote_target::commit_resume): Adjust.
(remote_target::select_thread_for_ambiguous_stop_reply): Adjust.
Change-Id: Ib86c877a4c75ee671d69c27ed06cb8f57bc087db
I am having trouble remembering which of _cur_x/_cur_y is columns and
which is rows, so renaming them helps. We already have _rows and _cols
to represent the terminal size, so I think that makes sense to name the
"_cur" variables accordingly.
gdb/testsuite/ChangeLog:
* lib/tuiterm.exp: Rename _cur_x/_cur_y to _cur_col/_cur_row.
Change-Id: I6abd3cdfdb295d8abde12dcd5f0ae09f18f07967
This code can be a bit cryptic for those who don't know terminal control
sequences very well. This patch adds links for all the handled
sequences, so it's easy to get some doc to follow the code.
I linked to a VT510 manual, because I think it's well formatted and easy
to read. There's only the repeat sequence (_csi_b) which I haven't
found in it, it looks to be xterm-specific or something.
I also tried to use the sequence names as they are in the manual.
gdb/testsuite/ChangeLog:
* lib/tuiterm.exp: Add links in comments.
Change-Id: I670b947a238e5e9bcab7c476a20eb3c31cf2909d
When running test-case gdb.python/py-format-string.exp with target board
unix/-m32, we run into:
...
(gdb) python print \
(gdb.parse_and_eval ('a_base_ref').format_string (deref_refs=True))^M
@0xffffc468: {_vptr.Base = 0x80487e0 <vtable for Deriv+8>, a = 42, \
static a_static_member = 2019}^M
(gdb) FAIL: gdb.python/py-format-string.exp: format_string: \
lang_cpp: a_base_ref with option deref_refs: deref_refs=true
...
while with -m64, we have instead:
...
@0x7fffffffd170: {_vptr.Base = 0x400910 <vtable for Deriv+16>, a = 42, \
static a_static_member = 2019}^M
(gdb) PASS: gdb.python/py-format-string.exp: format_string: \
lang_cpp: a_base_ref with option deref_refs: deref_refs=true
...
The vtable contains pointer entries which are 4-byte for -m32 and 8-byte for
-m64, so it's not surprising the offsets (Deriv+8 vs. Deriv+16) differ.
Fix this by allow Deriv+$decimal.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-01-20 Tom de Vries <tdevries@suse.de>
* gdb.python/py-format-string.exp: Allow Deriv+$decimal as vtable
offset.
The creation of this patch was motivated by Tom's "Change handling of
'!' operator in stap probes" patch.
While reviewing his patch, I stumbled upon a few issues with the stap
expression parser. They are:
- As it turns out, even with Tom's patch applied the parser doesn't
properly handle the '!' operator. The underlying issue was the fact
that stap_parse_argument_conditionally also needed to be patched in
order to recognize '!' as an operator that is part of a single
operand, and parse it accordingly.
- While writing the testcase I'm proposing on this patch, I found that
parenthesized sub-expressions were not being parsed correctly when
there was another term after them. For example:
1 - (2 + 3) + 4
In this case, the parser was considering "1" to be the left-side of
the expression, and "(2 + 3) + 4" to be the right-side. The patch
fixes the parser by making it identify whether a parenthesized
sub-expression has just been parsed, and act accordingly.
I've tested this on my Debian testing amd64, and everything seems OK.
gdb/ChangeLog:
2021-01-20 Sergio Durigan Junior <sergiodj@sergiodj.net>
Tom Tromey <tom@tromey.com>
* stap-probe.c (stap_parse_single_operand): Handle '!'
operator.
(stap_parse_argument_conditionally): Likewise.
Skip spaces after processing open-parenthesis sub-expression.
(stap_parse_argument_1): Skip spaces after call to
stap_parse_argument_conditionally.
Handle case when right-side expression is a parenthesized
sub-expression.
Skip spaces after call to stap_parse_argument_1.
gdb/testsuite/ChangeLog:
2021-01-20 Sergio Durigan Junior <sergiodj@sergiodj.net>
* gdb.arch/amd64-stap-expressions.S: New file.
* gdb.arch/amd64-stap-expressions.exp: New file.
Consider a minimal test-case test.c:
...
int main (void) { return 0; }
...
compiled with -m32:
...
$ gcc test.c -m32
...
When running the exec using gdbserver on openSUSE Factory (currently running a
linux kernel version 5.10.5):
...
$ gdbserver localhost:12345 a.out
...
to which we connect in a gdb session, we run into a segfault in the inferior:
...
$ gdb -batch -q -ex "target remote localhost:12345" -ex continue
Program received signal SIGSEGV, Segmentation fault.
0xf7dd8bd2 in init_cacheinfo () at ../sysdeps/x86/cacheinfo.c:761
...
The segfault is caused by gdbserver overwriting $gs_base with 0 using
PTRACE_SETREGS. After it is overwritten, the next use of $gs in the inferior
will trigger the segfault.
Before linux kernel version 5.9, the value used by PTRACE_SETREGS for $gs_base
was ignored, but starting version 5.9, the linux kernel has support for
intel architecture extension FSGSBASE, which allows users to modify $gs_base,
and consequently PTRACE_SETREGS can no longer ignore the $gs_base value.
The overwrite of $gs_base with 0 is done by a memset in x86_fill_gregset,
which was added in commit 9e0aa64f55 "Fix gdbserver qGetTLSAddr for
x86_64 -m32". The memset intends to zero-extend 32-bit registers that are
tracked in the regcache to 64-bit when writing them into the PTRACE_SETREGS
data argument. But in addition, it overwrites other registers that are
not tracked in the regcache, such as $gs_base.
Fix the segfault by redoing the fix from commit 9e0aa64f55 in minimal form.
Tested on x86_64-linux:
- openSUSE Leap 15.2 (using kernel version 5.3.18):
- native
- gdbserver -m32
- -m32
- openSUSE Factory (using kernel version 5.10.5):
- native
- m32
gdbserver/ChangeLog:
2021-01-20 Tom de Vries <tdevries@suse.de>
* linux-x86-low.cc (collect_register_i386): New function.
(x86_fill_gregset): Remove memset. Use collect_register_i386.
If an assembler trims off unused section symbols there may be no
section symbols. This means that testing for the .opd section symbol
needs to test both the section name and symbol flags.
* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Don't assume
section symbols are present.
In switch_thru_all_uis, a pre-c++11 way of removing copy constructor
and assignment operator is used.
This patch uses the DISABLE_COPY_AND_ASSIGN macro which does the right
thing for pre and post c++11.
gdb/Changelog:
2021-01-19 Lancelot SIX <lsix@lancelotsix.com>
* top.h (switch_thru_all_uis): Use DISABLE_COPY_AND_ASSIGN.
With the new member functions for struct trad_frame_saved_reg, there is no
need to invoke some of the set/get functions anymore. This patch removes
those and adjusts all callers.
Even though the most natural initial state of a saved register value is
UNKNOWN, there are target backends relying on the previous initial state
of REALREG set to a register's own number. I noticed this in at least a
couple targets: aarch64 and riscv.
Because of that, I decided to keep the reset function that sets the set of
register values to REALREG. I can't exercise all the targets to make sure
the initial state change won't break things, hence why it is risky to change
the default.
Validated with --enable-targets=all on aarch64-linux Ubuntu 18.04/20.04.
gdb/ChangeLog
2021-01-19 Luis Machado <luis.machado@linaro.org>
* trad-frame.h (trad_frame_saved_reg) <set_value_bytes>: Allocate
memory and save data.
(trad_frame_set_value, trad_frame_set_realreg, trad_frame_set_addr)
(trad_frame_set_unknown, trad_frame_set_value_bytes)
(trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p)
(trad_frame_value_bytes_p): Remove.
(trad_frame_reset_saved_regs): Adjust documentation.
* trad-frame.c (trad_frame_alloc_saved_regs): Initialize via a
constructor and reset the state of the registers.
(trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p)
(trad_frame_value_bytes_p, trad_frame_set_value)
(trad_frame_set_realreg, trad_frame_set_addr)
(trad_frame_set_unknown, trad_frame_set_value_bytes): Remove.
(trad_frame_set_reg_realreg): Update to call member function.
(trad_frame_set_reg_addr, trad_frame_set_reg_value_bytes): Likewise.
(trad_frame_get_prev_register): Likewise.
* aarch64-tdep.c (aarch64_analyze_prologue)
(aarch64_analyze_prologue_test, aarch64_make_prologue_cache_1)
(aarch64_prologue_prev_register): Update to use member functions.
* alpha-mdebug-tdep.c (alpha_mdebug_frame_unwind_cache): Likewise.
* alpha-tdep.c (alpha_heuristic_frame_unwind_cache): Likewise.
* arc-tdep.c (arc_print_frame_cache, arc_make_frame_cache): Likewise.
* arm-tdep.c (arm_make_prologue_cache, arm_exidx_fill_cache)
(arm_make_epilogue_frame_cache): Likewise.
* avr-tdep.c (avr_frame_unwind_cache)
(avr_frame_prev_register): Likewise.
* cris-tdep.c (cris_scan_prologue): Likewise.
* csky-tdep.c (csky_frame_unwind_cache): Likewise.
* frv-tdep.c (frv_analyze_prologue): Likewise.
* hppa-tdep.c (hppa_frame_cache, hppa_fallback_frame_cache): Likewise.
* lm32-tdep.c (lm32_frame_cache): Likewise.
* m32r-tdep.c (m32r_frame_unwind_cache): Likewise.
* m68hc11-tdep.c (m68hc11_frame_unwind_cache): Likewise.
* mips-tdep.c (set_reg_offset, mips_insn16_frame_cache)
(mips_micro_frame_cache, mips_insn32_frame_cache): Likewise.
(reset_saved_regs): Adjust to set realreg.
* riscv-tdep.c (riscv_scan_prologue, riscv_frame_cache): Adjust to
call member functions.
* rs6000-tdep.c (rs6000_frame_cache, rs6000_epilogue_frame_cache)
* s390-tdep.c (s390_prologue_frame_unwind_cache)
(s390_backchain_frame_unwind_cache): Likewise.
* score-tdep.c (score7_analyze_prologue)
(score3_analyze_prologue, score_make_prologue_cache): Likewise.
* sparc-netbsd-tdep.c (sparc32nbsd_sigcontext_saved_regs): Likewise.
* sparc-sol2-tdep.c (sparc32_sol2_sigtramp_frame_cache): Likewise.
* sparc64-netbsd-tdep.c (sparc64nbsd_sigcontext_saved_regs): Likewise.
* sparc64-sol2-tdep.c (sparc64_sol2_sigtramp_frame_cache): Likewise.
* tilegx-tdep.c (tilegx_analyze_prologue)
(tilegx_frame_cache): Likewise.
* v850-tdep.c (v850_frame_cache): Likewise.
* vax-tdep.c (vax_frame_cache): Likewise.
This patch updates the functions setting value bytes in trad-frame to use
a gdb::array_view instead of passing a buffer and a size.
gdb/ChangeLog:
2021-01-19 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-tdep.c (aarch64_linux_restore_vreg): Pass in an
array_view.
* trad-frame.c (trad_frame_set_value_bytes): Use gdb::array_view
instead of buffer and size.
(trad_frame_set_reg_value_bytes): Likewise.
* trad-frame.h (trad_frame_set_reg_value_bytes): Likewise.
(trad_frame_set_value_bytes): Likewise.
Our recent commit to support unnamed structure members better ditched
the old ctf_member_iter iterator body in favour of ctf_member_next.
However, these functions treat unnamed structure members differently:
ctf_member_iter just returned whatever the internal representation
contained, while ctf_member_next took care to always return "" rather
than sometimes returning "" and sometimes NULL depending on whether the
dict was dynamic (a product of ctf_create) or not (a product of
ctf_open). After this commit, ctf_member_iter did the same.
It was always a bug for external callers not to treat a "" return from
these functions as if it were NULL, so only buggy callers could be
affected -- but one of those buggy callers was ctf_add_type, which
assumed that it could just take whatever name was returned from
ctf_member_iter and slam it directly into the internal representation of
a dynamic dict -- which expects NULL for unnamed members, not "". The
net effect of all of this is that taking a struct containing unnamed
members and ctf_add_type'ing it into a dynamic dict produced a dict
whose unnamed members were inaccessible to ctf_member_info (though if
you wrote that dict out and then ctf_open'ed it, they would magically
reappear again).
Compensate for this by suitably transforming a "" name into NULL in the
internal representation, as should have been done all along.
libctf/ChangeLog
2021-01-19 Nick Alcock <nick.alcock@oracle.com>
* ctf-create.c (membadd): Transform ""-named members into
NULL-named ones.
* testsuite/libctf-regression/type-add-unnamed-struct*: New test.
The recent work allowing lookups of pointers in child dicts when the
pointed-to type is in the parent dict broke the case where a pointer
type that does not exist at all is looked up: we mistakenly return the
pointed-to type, which is likely not a pointer at all. This causes
considerable confusion.
Fixed, with a new testcase.
libctf/ChangeLog
2021-01-19 Nick Alcock <nick.alcock@oracle.com>
* ctf-lookup.c (ctf_lookup_by_name_internal): Do not return the
base type if looking up a nonexistent pointer type.
* testsuite/libctf-regression/pptrtab*: Test it.
GCC 11+ spots that the extern var_1 and var_666 declarations in this
test are unused, and removes them, thus stopping them from appearing as
conflicted data symbols and rendering the test pointless. Use them in a
function unique to this TU to prevent them from being eliminated.
ld/ChangeLog
2021-01-19 Nick Alcock <nick.alcock@oracle.com>
* testsuite/ld-ctf/data-func-2.c: Stop removal of the extern foo_t
symbols by the optimizer.
* testsuite/ld-ctf/data-func-conflicted.d: Adjust accordingly.
When executing test-case gdb.base/step-over-syscall.exp with target board
unix/-m32, we run into:
...
(gdb) x/2i $pc^M
=> 0xf7fd5155 <__kernel_vsyscall+5>: sysenter ^M
0xf7fd5157 <__kernel_vsyscall+7>: int $0x80^M
(gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: \
pc before/after syscall instruction
stepi^M
[Detaching after fork from child process 23593]^M
0xf7fd5159 in __kernel_vsyscall ()^M
1: x/i $pc^M
=> 0xf7fd5159 <__kernel_vsyscall+9>: pop %ebp^M
(gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: stepi fork insn
print /x $pc^M
$2 = 0xf7fd5159^M
(gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: pc after stepi
FAIL: gdb.base/step-over-syscall.exp: fork: displaced=off: \
pc after stepi matches insn addr after syscall
...
The test tries to verify that after doing a stepi at a syscall insn, the $pc
is matching the insn after the syscall insn.
However, in the case that the syscall insn is "sysenter", the stepi will land
further away, so in this case:
...
0xf7fd5155 <__kernel_vsyscall+5>: sysenter ^M
0xf7fd5157 <__kernel_vsyscall+7>: int $0x80^M
0xf7fd5159 <__kernel_vsyscall+9>: pop %ebp^M
...
the stepi will land at 0xf7fd5159 instead of 0xf7fd5157.
Fix this by detecting the sysenter/int sequence and adjusting the expected
pc.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-01-19 Tom de Vries <tdevries@suse.de>
* gdb.base/step-over-syscall.exp: Detect and handle sysenter/int
sequence.
When running test-case gdb.arch/i386-mpx.exp with target board unix/-m32, we
run into:
...
(gdb) print $bndstatus^M
$3 = {raw = 0xf7ca7ff2, status = {bde = 1039310844, error = 2}}^M
(gdb) FAIL: gdb.arch/i386-mpx.exp: bndstatus formating
print $bndstatus.raw^M
$4 = (void *) 0xf7ca7ff2^M
(gdb) FAIL: gdb.arch/i386-mpx.exp: bndstatus is zero by startup
...
The failure does not occur with -m64, there we have instead:
...
(gdb) print $bndstatus^M
$3 = {raw = 0x0, status = {bde = 0, error = 0}}^M
(gdb) PASS: gdb.arch/i386-mpx.exp: bndstatus formating
print $bndstatus.raw^M
$4 = (void *) 0x0^M
(gdb) PASS: gdb.arch/i386-mpx.exp: bndstatus is zero by startup
...
The difference is as follows. At the point of issuing the print commands, we
have run to main, so in the case of -m64 we have executed:
...
00000000004004c7 <main>:
4004c7: 55 push %rbp
4004c8: 48 89 e5 mov %rsp,%rbp
4004cb: 89 7d fc mov %edi,-0x4(%rbp)
4004ce: 48 89 75 f0 mov %rsi,-0x10(%rbp)
4004d2: 66 0f 1b 45 e0 bndmov %bnd0,-0x20(%rbp)
...
and in the case of -m32:
...
08048426 <main>:
8048426: 55 push %ebp
8048427: 89 e5 mov %esp,%ebp
8048429: 83 ec 08 sub $0x8,%esp
804842c: 8d 45 0c lea 0xc(%ebp),%eax
804842f: 8b 55 0c mov 0xc(%ebp),%edx
8048432: 0f 1a 04 10 bndldx (%eax,%edx,1),%bnd0
8048436: 66 0f 1b 45 f8 bndmov %bnd0,-0x8(%ebp)
...
In both cases, the bnd instructions attempt to save the bound for pointer
argument argv to stack. However, there's no such bound set.
In the -m64 case, that means we just save some random value to stack.
In the -m32 case, that means that when executing bndldx the corresponding
entry in the Bounds Directory is invalid, and $bndstatus is updated to reflect
that.
Fix this by dropping the unnecessary argv parameter to main, similar to all
other gdb.arch/i386-mpx*.c test-cases.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-01-19 Tom de Vries <tdevries@suse.de>
* gdb.arch/i386-mpx.c (main): Drop argc/argv parameter.
Put the logic to select local vs. usual .plt section in one place.
* elf64-ppc.c (elf_hash_entry): New inline function. Use
throughout to replace casts.
(branch_reloc_hash_match): Remove const from params.
(use_local_plt): New function.
(allocate_dynrelocs, ppc_build_one_stub, ppc_size_one_stub),
(build_global_entry_stubs_and_plt, ppc64_elf_relocate_section):
Use use_local_plt.
* elf32-ppc.c (use_local_plt): New function.
(allocate_dynrelocs, ppc_elf_relocate_section),
(write_global_sym_plt): Use use_local_plt.
