This commit was originally part of this patch series:
(v1): https://sourceware.org/pipermail/gdb-patches/2021-May/179357.html
(v2): https://sourceware.org/pipermail/gdb-patches/2021-June/180208.html
(v3): https://sourceware.org/pipermail/gdb-patches/2021-July/181028.html
However, that series is being held up in review, so I wanted to break
out some of the non-related fixes in order to get these merged.
This commit addresses two semi-related issues, both of which are
problems exposed by using 'set debug frame on'.
The first issue is in frame.c in get_prev_frame_always_1, and was
introduced by this commit:
commit a05a883fba
Date: Tue Jun 29 12:03:50 2021 -0400
gdb: introduce frame_debug_printf
This commit replaced fprint_frame with frame_info::to_string.
However, the former could handle taking a nullptr while the later, a
member function, obviously requires a non-nullptr in order to make the
function call. In one place we are not-guaranteed to have a
non-nullptr, and so, there is the possibility of triggering undefined
behaviour.
The second issue addressed in this commit has existed for a while in
GDB, and would cause this assertion:
gdb/frame.c:622: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->this_id.p != frame_id_status::COMPUTING' failed.
We attempt to get the frame_id for a frame while we are computing the
frame_id for that same frame.
What happens is that when GDB stops we create a frame_info object for
the sentinel frame (frame #-1) and then we attempt to unwind this
frame to create a frame_info object for frame #0.
In the test case used here to expose the issue we have created a
Python frame unwinder. In the Python unwinder we attemt to read the
program counter register.
Reading this register will initially create a lazy register value.
The frame-id stored in the lazy register value will be for the
sentinel frame (lazy register values hold the frame-id for the frame
from which the register will be unwound).
However, the Python unwinder does actually want to examine the value
of the program counter, and so the lazy register value is resolved
into a non-lazy value. This sends GDB into value_fetch_lazy_register
in value.c.
Now, inside this function, if 'set debug frame on' is in effect, then
we want to print something like:
frame=%d, regnum=%d(%s), ....
Where 'frame=%d' will be the relative frame level of the frame for
which the register is being fetched, so, in this case we would expect
to see 'frame=0', i.e. we are reading a register as it would be in
frame #0. But, remember, the lazy register value actually holds the
frame-id for frame #-1 (the sentinel frame).
So, to get the frame_info for frame #0 we used to call:
frame = frame_find_by_id (VALUE_FRAME_ID (val));
Where VALUE_FRAME_ID is:
#define VALUE_FRAME_ID(val) (get_prev_frame_id_by_id (VALUE_NEXT_FRAME_ID (val)))
That is, we start with the frame-id for the next frame as obtained by
VALUE_NEXT_FRAME_ID, then call get_prev_frame_id_by_id to get the
frame-id of the previous frame.
The get_prev_frame_id_by_id function finds the frame_info for the
given frame-id (in this case frame #-1), calls get_prev_frame to get
the previous frame, and then calls get_frame_id.
The problem here is that calling get_frame_id requires that we know
the frame unwinder, so then have to try each frame unwinder in turn,
which would include the Python unwinder.... which is where we started,
and thus we have a loop!
To prevent this loop GDB has an assertion in place, which is what
actually triggers.
Solving the assertion failure is pretty easy, if we consider the code
in value_fetch_lazy_register and get_prev_frame_id_by_id then what we
do is:
1. Start with a frame_id taken from a value,
2. Lookup the corresponding frame,
3. Find the previous frame,
4. Get the frame_id for that frame, and
5. Lookup the corresponding frame
6. Print the frame's level
Notice that steps 3 and 5 give us the exact same result, step 4 is
just wasted effort. We could shorten this process such that we drop
steps 4 and 5, thus:
1. Start with a frame_id taken from a value,
2. Lookup the corresponding frame,
3. Find the previous frame,
6. Print the frame's level
This will give the exact same frame as a result, and this is what I
have done in this patch by removing the use of VALUE_FRAME_ID from
value_fetch_lazy_register.
Out of curiosity I looked to see how widely VALUE_FRAME_ID was used,
and saw it was only used in one other place in valops.c:value_assign,
where, once again, we take the result of VALUE_FRAME_ID and pass it to
frame_find_by_id, thus introducing a redundant frame_id lookup.
I don't think the value_assign case risks triggering the assertion
though, as we are unlikely to call value_assign while computing the
frame_id for a frame, however, we could make value_assign slightly
more efficient, with no real additional complexity, by removing the
use of VALUE_FRAME_ID.
So, in this commit, I completely remove VALUE_FRAME_ID, and replace it
with a use of VALUE_NEXT_FRAME_ID, followed by a direct call to
get_prev_frame_always, this should make no difference in either case,
and resolves the assertion issue from value.c.
As I said, this patch was originally part of another series, the
original test relied on the fixes in that original series. However, I
was able to create an alternative test for this issue by enabling
frame debug within an existing test script.
This commit probably fixes bug PR gdb/27938, though the bug doesn't
have a reproducer attached so it is not possible to know for sure.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27938
When reading an archive member, set error to bfd_error_malformed_archive
on open_nested_file failure only if the error is unset.
PR ld/28138
* archive.c (_bfd_get_elt_at_filepos): Don't set error to
bfd_error_malformed_archive if it has been set.
This test fails on PPC64 because PPC64 prints the value of 3.5 with
more significant digits than on Intel. The patch updates the regular
expression to allow for more significant digits on the constant.
gdb/testsuite/ChangeLog
* gdb.mi/mi-reverse.exp: mi_execute_to exec-step reverse add check
for additional digits.
The "val_print_type_code_flags ()" function is responsible for
extraction of fields for "flags" data type. These data types are
used when describing a custom register type in a target description
XML. The logic used for the extraction though is not sound:
unsigned field_len = TYPE_FIELD_BITSIZE (type, field);
ULONGEST field_val
= val >> (TYPE_FIELD_BITPOS (type, field) - field_len + 1);
TYPE_FIELD_BITSIZE: The bit length of the field to be extracted.
TYPE_FIELD_BITPOS: The starting position of the field; 0 is LSB.
val: The register value.
Imagine you have a field that starts at position 1 and its length
is 4 bits. According to the third line of the code snippet the
shifting right would become "val >> -2", or "val >> 0xfff...fe"
to be precise. That will result in a "field_val" of 0.
The correct extraction should be:
ULONGEST field_val = val >> TYPE_FIELD_BITPOS (type, field);
The rest of the algorithm that masks out the higher bits is OK.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
In commit:
commit f069ea46a0
Date: Sat Jul 3 16:29:08 2021 -0700
Rename gdb/ChangeLog to gdb/ChangeLog-2021
The gdb/ChangeLog file was renamed, but all of the other ChangeLog
files relating to gdb were left in place.
As I understand things, the no ChangeLogs policy applies to all the
GDB related directories, so this commit renames all of the remaining
GDB related ChangeLog files.
As with the original commit, the intention behind this commit is to
hopefully stop people merging ChangeLog entries by mistake.
The renames carried out in this commit are:
gdb/doc/ChangeLog -> gdb/doc/ChangeLog-1991-2021
gdb/stubs/ChangeLog -> gdb/stubs/ChangeLog-2012-2020
gdb/testsuite/ChangeLog -> gdb/testsuite/ChangeLog-2014-2021
gdbserver/ChangeLog -> gdbserver/ChangeLog-2002-2021
gdbsupport/ChangeLog -> gdbsupport/ChangeLog-2020-2021
As reported in PR gdb/28076 [1], passing no condition argument to the
-break-condition command (e.g.: "-break-condition 2") should clear the
condition for breakpoint 2, just like CLI's "condition 2", but instead
an error message is returned:
^error,msg="-break-condition: Missing the <number> and/or <expr> argument"
The current implementation of the -break-condition command's argument
handling (79aabb7308 "gdb/mi: add a '--force' flag to the
'-break-condition' command") was done according to the documentation,
where the condition argument seemed mandatory. However, the
-break-condition command originally (i.e. before the 79aabb7308
patch) used the CLI's "cond" command, and back then not passing a
condition argument was clearing out the condition. So, this is a
regression in terms of the behavior.
Fix the argument handling of the -break-condition command to allow not
having a condition argument, and also update the document to make the
behavior clear. Also add test cases to test the scenarios which were
previously not covered.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28076
Commit 40726f16a8 broke references to sections within ADDR(), and
overlays with weird section names.
* ldgram.y (paren_script_name): New rule.
(exp): Use it for ALIGNOF, SIZEOF, ADDR, and LOADADDR. Similarly
ensure script mode parsing for section name in SEGMENT_START.
(overlay_section): Delete unnecessary ldlex_script call. Backup
on a lookahead NAME parsed in expression mode.
* testsuite/ld-elf/overlay.s: Add more sections.
* testsuite/ld-elf/overlay.t: Test '-' in section names.
Generated from sys/sys/syscall.h revision 1.319.
We can safely remove the _lwp_gettid syscall, which was never exposed
in libc and never made it into a release.
gdb/ChangeLog:
2021-07-23 Frederic Cambus <fred@statdns.com>
* syscalls/netbsd.xml: Regenerate.
When creating a parameter in Guile, you have to create it using
make-parameter and then register it with GDB with register-parameter!.
In between, it's still possible (though not documented) to set the
parameter's value. I broke this use case by mistake while writing this
series, so thought it would be good to have a test for it.
I suppose that people could use this "feature" to give their parameter
an initial value, even though make-parameter has an initial-value
parameter for this. Nevertheless, changing this behavior could break
some scripts, which is why I think it's important for it to be tested.
Change-Id: I5b2103e3cec0cfdcccf7ffb00eb05fed8626e66d
I don't understand what the sfunc function type in
cmd_list_element::function is for. Compared to cmd_simple_func_ftype,
it has an extra cmd_list_element parameter, giving the callback access
to the cmd_list_element for the command being invoked. This allows
registering the same callback with many commands, and alter the behavior
using the cmd_list_element's context.
From the comment in cmd_list_element, it sounds like at some point it
was the callback function type for set and show functions, hence the
"s". But nowadays, it's used for many more commands that need to access
the cmd_list_element object (see add_catch_command for example).
I don't really see the point of having sfunc at all, since do_sfunc is
just a trivial shim that changes the order of the arguments. All
commands using sfunc could just as well set cmd_list_element::func to
their callback directly.
Therefore, remove the sfunc field in cmd_list_element and everything
that goes with it. Rename cmd_const_sfunc_ftype to cmd_func_ftype and
use it for cmd_list_element::func, as well as for the add_setshow
commands.
Change-Id: I1eb96326c9b511c293c76996cea0ebc51c70fac0
After browsing the CLI code for quite a while and trying really hard, I
reached the conclusion that I can't give a meaningful explanation of
what "sfunc" and "cfunc" functions are, in cmd_list_element. I don't
see a logic at all. That makes it very difficult to do any kind of
change. Unless somebody can make sense out of all that, I'd like to try
to retro-fit some logic in the cmd_list_element callback function code
so that we can understand what is going on, do some cleanups and add new
features.
The first change is about "cfunc". I can't figure out what the "c" in
cfunc means. It's not const, because there's already "const" in
"cmd_const_cfunc_ftype", and the previous "cmd_cfunc_ftype" had nothing
const.. It's not "cmd" or "command", because there's already "cmd" in
"cmd_const_cfunc_ftype".
The "main" command callback, cmd_list_element::func, has three
parameters, whereas cfunc has two. It is missing the cmd_list_element
parameter. So the only reason I see for cfunc to exist is to be a shim
between the three and two parameter versions. Most commands don't need
to receive the cmd_list_element object, so adding it everywhere would be
long and would just add more unnecessary boilerplate. So since this is
the "simple" version of the callback, compared to the "full", I suggest
renaming cmd_const_cfunc_ftype into cmd_simple_func_ftype, as well as
everything (like the utility functions) that goes with it.
Change-Id: I4e46cacfd77a66bc1cbf683f6a362072504b7868
Same idea as the previous patch, but for m_cwd.
To keep things consistent across the board, change get_inferior_cwd as
well, which is shared with GDBserver. So update the related GDBserver
code too.
Change-Id: Ia2c047fda738d45f3d18bc999eb67ceb8400ce4e
With the current code, both a NULL pointer and an empty string can mean
"no arguments". We don't need this distinction. Changing to a string
has the advantage that there is now a single state for that (an empty
string), which makes the code a bit simpler in my opinion.
Change-Id: Icdc622820f7869478791dbaa84b4a1c7fec21ced
Add cwd/set_cwd to the inferior class, remove set_inferior_args.
Keep get_inferior_args, because it is used from fork_inferior, in shared
code. The cwd could eventually be passed as a parameter eventually,
though, I think that would be cleaner.
Change-Id: Ifb72ea865d7e6f9a491308f0d5c1595579d8427e
Add args/set_args to the inferior class, remove the set_inferior_args
and get_inferior_args functions, that would just be wrappers around
them.
Change-Id: If87d52f3402ce08be26c32897ae8915d9f6d1ea3
There are currently two states that the inferior args can be stored.
The main one is the `args` field, where they are stored as a single
string. The other one is the `argc`/`argv` fields.
This last one is only used for arguments passed in GDB's
command line. And the only outcome is that when get_inferior_args is
called, `argc`/`argv` are serialized into `args`. So really,
`argc`/`argv` is just a staging area before moving the arguments in
`args`.
Simplify this by only keeping the `args` field. Change
set_inferior_args_vector to immediately serialize the arguments into
`args`, work that would be done in get_inferior_args later anyway.
The only time where this work would be "wasted" is when the user passes
some arguments on the command line, but does not end up running the
program. But that just seems unlikely. And it's not that much work.
Change-Id: Ica0b9859397c095f6530350c8fb3c36905f2044a
The declaration of set_inferior_cwd is currently shared between gdb and
gdbserver, in gdbsupport/common-inferior.h. It doesn't need to be, as
set_inferior_cwd is not called from common code. Only get_inferior_cwd
needs to.
The motivation for this is that a future patch will change the prototype
of set_inferior_cwd in gdb, and I don't want to change it for gdbserver
unnecessarily. I see this as a good cleanup in any case, to reduce to
just the essential what is shared between GDB and GDBserver.
Change-Id: I3127d27d078f0503ebf5ccc6fddf14f212426a73
Fix:
DUPLICATE: gdb.base/setshow.exp: test_setshow_args: show args
by giving some explicit test names.
Change-Id: I2a738d3d3675ab9b45929e71f5aee0ea6bf92072
Split in multiple procs, one per topic, and start with a fresh GDB in
each. I find it easier to work on a test with multiple smaller
independent test procedures. For example, it's possible to comment all
but one when working on one. It's also easier to add things without
having to think about the impact on existing tests, and vice-versa.
Change-Id: I19691eed8f9bcb975b2eeff7577cac66251bcbe2
Using save_vars is a bit better than what we have now, as it ensures the
variable gets restored if the code within it throws an error.
Change-Id: I3bd6836e5b7efb61b078acadff1a1c8182c19a27
Split the file into multiple independent test procs, where each proc
starts with a fresh GDB. I find it easier to understand what a test is
doing when each part of the test is isolated and self-contained. It
makes it easier to comment out some parts of the test while working /
debugging a specific part. It also makes it easier to add new things
(which a subsequent patch will do) without fear of impacting another part
of the test.
Change-Id: I8b4d52ac82b1492d79b679e13914ed177d8a836d
Not all systems have hardware breakpoint support. Add a check
to see if the system supports hardware breakpoints.
gdb/testsuite/ChangeLog
* gdb.python/py-breakpoint.exp (test_hardware_breakpoints): Add
check for hardware breakpoint support.
In spawn_capture_tty_name (lib/gdb.exp) we either set or unset
last_spawn_tty_name depending on whether spawn_out(slave,name) exists
or not.
One situation that might cause spawn_out(slave,name) to not exists is
if the spawn function is called with the argument -leaveopen, which is
how it is called when processes are created as part of a pipeline, the
created process has no tty, instead its output is written to a file
descriptor.
If a pipeline is created consisting of multiple processes then there
will be multiple sequential calls to spawn, all using -leaveopen. The
first of these calls is fine, spawn_out(slave,name) is not set, and so
in spawn_capture_tty_name we unset last_spawn_tty_name. However, on
the second call to spawn, spawn_out(slave,name) is still not set and
so in spawn_capture_tty_name we again try to unset
last_spawn_tty_name, this now throws an error (as last_spawn_tty_name
is already unset).
Fix this issue by using -nocomplain with the call to unset in
spawn_capture_tty_name.
Before this commit I was seeing gdb.base/gnu-debugdata.exp report 1
pass, and 1 unsupported test. After this commit I now see 16 passes
from this test script.
I have also improved the code that used to do this:
if { [info exists spawn_out] } {
set ::last_spawn_tty_name $spawn_out(slave,name)
} else {
...
}
The problem here is that we check for the existence of spawn_out, and
then unconditionally read spawn_out(slave,name). A situation could
arise where some other element of spawn_out is set,
e.g. spawn_out(foo), in which case we would enter the if block and try
to read a non-existent variable. After this commit we now check
specifically for spawn_out(slave,name).
Finally, it is worth noting that before this issue was fixed runtest
itself, or rather the expect process behind runtest, would segfault
while exiting. I haven't looked at all into what the problem is here
that caused expect to crash, as fixing the bug in GDB's testing
scripts made the segfault go away.
While EVEX.L'L are indeed ignored when EVEX.b stands for just SAE,
EVEX.b itself is not ignored when an insn permits neither rounding
control nor SAE.
While changing this aspect of EVEX.b handling, also alter unduly set
embedded broadcast: Don't call BadOp(), screwing up subsequent
disassembly, but emit "{bad}" instead.
When running test-case gdb.ada/formatted_ref.exp with gcc-11 and target board
unix/gdb:debug_flags=-gdwarf-4 we run into:
...
(gdb) print/x s^M
No definition of "s" in current context.^M
(gdb) FAIL: gdb.ada/formatted_ref.exp: print/x s
...
which is caused by "runto defs.adb:20" taking us to defs__struct1IP:
...
(gdb) break defs.adb:20^M
Breakpoint 1 at 0x402cfd: defs.adb:20. (2 locations)^M
(gdb) run ^M
Starting program: formatted_ref ^M
^M
Breakpoint 1, defs__struct1IP () at defs.adb:20^M
20 return s.x; -- Set breakpoint marker here.^M
(gdb) print s1'access^M
...
instead of the expected defs.f1:
...
(gdb) break defs.adb:20^M
Breakpoint 1 at 0x402d0e: file defs.adb, line 20.^M
(gdb) run ^M
Starting program: formatted_ref ^M
^M
Breakpoint 1, defs.f1 (s=...) at defs.adb:20^M
20 return s.x; -- Set breakpoint marker here.^M
...
This is caused by incorrect line info due to gcc PR 101575 - "[gcc-11,
-gdwarf-4] Missing .file <n> directive causes invalid line info".
Fix this by when landing in defs__struct1IP:
- xfailing the runto, and
- issuing a continue to land in defs.f1.
Likewise in a few other test-cases.
Tested on x86_64-linux, with:
- system gcc.
- gcc-11 and target boards unix/gdb:debug_flags=-gdwarf-4 and
unix/gdb:debug_flags=-gdwarf-5.
gdb/testsuite/ChangeLog:
2021-07-22 Tom de Vries <tdevries@suse.de>
* gdb.ada/formatted_ref.exp: Add xfail for PR gcc/101575.
* gdb.ada/iwide.exp: Same.
* gdb.ada/pkd_arr_elem.exp: Same.
Their sole use is for {,V}EXTRACTPS / {,V}P{EXT,INS}RB respectively; for
consistency also limit use of dqw_mode to Jdqw. 64-bit disassembly
reflecting REX.W / VEX.W is not in line with the assembler's opcode
table having NoRex64 / VexWIG in all respective templates, i.e. assembly
input isn't being honored there either. Obviously the 0FC5 encodings of
{,V}PEXTRW then also need adjustment for consistency reasons.
It has only a single use and can easily be represented by dq_mode
instead. Plus its handling in intel_operand_size() was duplicating
that of vex_vsib_{d,q}_w_dq_mode anyway.
