This changes allocate_value_lazy to be a static "constructor" of
struct value.
I considered trying to change value to use ordinary new/delete, but it
seems to me that due to reference counting, we may someday want to
change these static constructors to return value_ref_ptr instead.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This changes the value_lazy and set_value_lazy functions to be methods
of value. Much of this patch was written by script.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This changes value_enclosing_type to be a method of value. Much of
this patch was written by script.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This changes deprecated_set_value_type to be a method of value. Much
of this patch was written by script.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Nearly every call to fixup_symbol_section in gdb is incorrect, and if
any such call has an effect, it's purely by happenstance.
fixup_section has a long comment explaining that the call should only
be made before runtime section offsets are applied. And, the loop in
this code (the fallback loop -- the minsym lookup code is "ok") is
careful to remove these offsets before comparing addresses.
However, aside from a single call in dwarf2/read.c, every call in gdb
is actually done after section offsets have been applied. So, these
calls are incorrect.
Now, these calls could be made when the symbol is created. I
considered this approach, but I reasoned that the code has been this
way for many years, seemingly without ill effect. So, instead I chose
to simply remove the offending calls.
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
[I sent this earlier today, but I don't see it in the archives.
Resending it through a different computer / SMTP.]
The use of the static buffer in command_line_input is becoming
problematic, as explained here [1]. In short, with this patch [2] that
attempt to fix a post-hook bug, when running gdb.base/commands.exp, we
hit a case where we read a "define" command line from a script file
using command_command_line_input. The command line is stored in
command_line_input's static buffer. Inside the define command's
execution, we read the lines inside the define using command_line_input,
which overwrites the define command, in command_line_input's static
buffer. After the execution of the define command, execute_command does
a command look up to see if a post-hook is registered. For that, it
uses a now stale pointer that used to point to the define command, in
the static buffer, causing a use-after-free. Note that the pointer in
execute_command points to the dynamically-allocated buffer help by the
static buffer in command_line_input, not to the static object itself,
hence why we see a use-after-free.
Fix that by removing the static buffer. I initially changed
command_line_input and other related functions to return an std::string,
which is the obvious but naive solution. The thing is that some callees
don't need to return an allocated string, so this this an unnecessary
pessimization. I changed it to passing in a reference to an std::string
buffer, which the callee can use if it needs to return
dynamically-allocated content. It fills the buffer and returns a
pointers to the C string inside. The callees that don't need to return
dynamically-allocated content simply don't use it.
So, it started with modifying command_line_input as described above, all
the other changes derive directly from that.
One slightly shady thing is in handle_line_of_input, where we now pass a
pointer to an std::string's internal buffer to readline's history_value
function, which takes a `char *`. I'm pretty sure that this function
does not modify the input string, because I was able to change it (with
enough massaging) to take a `const char *`.
A subtle change is that we now clear a UI's line buffer using a
SCOPE_EXIT in command_line_handler, after executing the command.
This was previously done by this line in handle_line_of_input:
/* We have a complete command line now. Prepare for the next
command, but leave ownership of memory to the buffer . */
cmd_line_buffer->used_size = 0;
I think the new way is clearer.
[1] https://inbox.sourceware.org/gdb-patches/becb8438-81ef-8ad8-cc42-fcbfaea8cddd@simark.ca/
[2] https://inbox.sourceware.org/gdb-patches/20221213112241.621889-1-jan.vrany@labware.com/
Change-Id: I8fc89b1c69870c7fc7ad9c1705724bd493596300
Reviewed-By: Tom Tromey <tom@tromey.com>
This implements the request given in PR breakpoints/12464.
Before this patch, when a breakpoint that has multiple locations is reached,
GDB printed:
Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5
This patch changes the message so that bkpt_print_id prints the precise
encountered breakpoint:
Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5
In mi mode, bkpt_print_id also (optionally) prints a new table field "locno":
locno is printed when the breakpoint hit has more than one location.
Note that according to the GDB user manual node 'GDB/MI Development and Front
Ends', it is ok to add new fields without changing the MI version.
Also, when a breakpoint is reached, the convenience variables
$_hit_bpnum and $_hit_locno are set to the encountered breakpoint number
and location number.
$_hit_bpnum and $_hit_locno can a.o. be used in the command list of a
breakpoint, to disable the specific encountered breakpoint, e.g.
disable $_hit_bpnum.$_hit_locno
In case the breakpoint has only one location, $_hit_locno is set to
the value 1, so as to allow a command such as:
disable $_hit_bpnum.$_hit_locno
to disable the breakpoint even when the breakpoint has only one location.
This also fixes a strange behaviour: when a breakpoint X has only
one location,
enable|disable X.1
is accepted but transforms the breakpoint in a multiple locations
breakpoint having only one location.
The changes in RFA v4 handle the comments of Tom Tromey:
- Changed convenience var names from $bkptno/$locno to
$_hit_bpnum/$_hit_locno.
- updated the tests and user manual accordingly.
User manual also explictly describes that $_hit_locno is set to 1
for a breakpoint with a single location.
- The variable values are now set in bpstat_do_actions_1 so that
they are set for silent breakpoints, and when several breakpoints
are hit at the same time, that the variables are set to the printed
breakpoint.
The changes in RFA v3 handle the additional comments of Eli:
GDB/NEW:
- Use max 80-column
- Use 'code location' instead of 'location'.
- Fix typo $bkpno
- Ensure that disable $bkptno and disable $bkptno.$locno have
each their explanation inthe example
- Reworded the 'breakpoint-hit' paragraph.
gdb.texinfo:
- Use 'code location' instead of 'location'.
- Add a note to clarify the distinction between $bkptno and $bpnum.
- Use @kbd instead of examples with only one command.
Compared to RFA v1, the changes in v2 handle the comments given by
Keith Seitz and Eli Zaretskii:
- Use %s for the result of paddress
- Use bkptno_numopt_re instead of 2 different -re cases
- use C@t{++}
- Add index entries for $bkptno and $locno
- Added an example for "locno" in the mi interface
- Added examples in the Break command manual.
Currently, every internal_error call must be passed __FILE__/__LINE__
explicitly, like:
internal_error (__FILE__, __LINE__, "foo %d", var);
The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability. We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.
So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.
The result is that we now should call internal_error like so:
internal_error ("foo %d", var);
Likewise for internal_warning.
The patch adjusts all calls sites. 99% of the adjustments were done
with a perl/sed script.
The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
Iterate over objfile in search order using the objfile of the context
block as current_objfile so the iteration can stay inside the block's
linker namespace.
When searching for standard exceptions for Ada, we lookup the minimal
symbol of each exception. With linker namespaces there can be multiple
instances in different namespaces. Collect them all.
The cooked index work changed how .gdb_index is constructed, and in
the process broke .gdb_index support. This is PR symtab/29179.
This patch partially fixes the problem. It arranges for Ada names to
be encoded in the form expected by the index code. In particular,
linkage names for Ada are emitted, including the "main" name; names
are Ada-encoded; and names are no longer case-folded, something that
prevented operator names from round-tripping correctly.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29179
I looked at all the spots using value_mark, and converted all the
straightforward ones to use scoped_value_mark instead.
Regression tested on x86-64 Fedora 34.
This changes GDB to use frame_info_ptr instead of frame_info *
The substitution was done with multiple sequential `sed` commands:
sed 's/^struct frame_info;/class frame_info_ptr;/'
sed 's/struct frame_info \*/frame_info_ptr /g' - which left some
issues in a few files, that were manually fixed.
sed 's/\<frame_info \*/frame_info_ptr /g'
sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace
problems.
The changed files were then manually checked and some 'sed' changes
undone, some constructors and some gets were added, according to what
made sense, and what Tromey originally did
Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>
A user noticed that gdb would assert when printing a certain array
with array-indexes enabled. This turned out to be caused by the array
having an index type of Character, which is completely valid in Ada.
This patch changes the Ada support to recognize Character as a
discrete type, and adds some tests.
Because this is Ada-specific and was also reviewed internally, I am
checking it in.
Add the `length` and `set_length` methods on `struct type`, in order to remove
the `TYPE_LENGTH` macro. In this patch, the macro is changed to use the
getter, so all the call sites of the macro that are used as a setter are
changed to use the setter method directly. The next patch will remove the
macro completely.
Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4
Add the `target_type` and `set_target_type` methods on `struct type`, in order
to remove the `TYPE_TARGET_TYPE` macro. In this patch, the macro is changed to
use the getter, so all the call sites of the macro that are used as a setter
are changed to use the setter method directly. The next patch will remove the
macro completely.
Change-Id: I85ce24d847763badd34fdee3e14b8c8c14cb3161
This rewrites registry.h, removing all the macros and replacing it
with relatively ordinary template classes. The result is less code
than the previous setup. It replaces large macros with a relatively
straightforward C++ class, and now manages its own cleanup.
The existing type-safe "key" class is replaced with the equivalent
template class. This approach ended up requiring relatively few
changes to the users of the registry code in gdb -- code using the key
system just required a small change to the key's declaration.
All existing users of the old C-like API are now converted to use the
type-safe API. This mostly involved changing explicit deletion
functions to be an operator() in a deleter class.
The old "save/free" two-phase process is removed, and replaced with a
single "free" phase. No existing code used both phases.
The old "free" callbacks took a parameter for the enclosing container
object. However, this wasn't truly needed and is removed here as
well.
Currently the Ada code assumes that it can distinguish between a
multi-dimensional array and an array of arrays by looking for an
intervening typedef -- that is, for an array of arrays, there will be
a typedef wrapping the innermost array type.
A recent compiler change removes this typedef, which causes a gdb
failure in the internal AdaCore test suite.
This patch handles this case by checking whether the array type in
question has a name.
Currently, GDB internally uses the term "location" for both the
location specification the user input (linespec, explicit location, or
an address location), and for actual resolved locations, like the
breakpoint locations, or the result of decoding a location spec to
SaLs. This is expecially confusing in the breakpoints module, as
struct breakpoint has these two fields:
breakpoint::location;
breakpoint::loc;
"location" is the location spec, and "loc" is the resolved locations.
And then, we have a method called "locations()", which returns the
resolved locations as range...
The location spec type is presently called event_location:
/* Location we used to set the breakpoint. */
event_location_up location;
and it is described like this:
/* The base class for all an event locations used to set a stop event
in the inferior. */
struct event_location
{
and even that is incorrect... Location specs are used for finding
actual locations in the program in scenarios that have nothing to do
with stop events. E.g., "list" works with location specs.
To clean all this confusion up, this patch renames "event_location" to
"location_spec" throughout, and then all the variables that hold a
location spec, they are renamed to include "spec" in their name, like
e.g., "location" -> "locspec". Similarly, functions that work with
location specs, and currently have just "location" in their name are
renamed to include "spec" in their name too.
Change-Id: I5814124798aa2b2003e79496e78f95c74e5eddca
This test in test-case gdb.ada/dynamic-iface.exp passes with gcc 8:
...
(gdb) print obj^M
$1 = (n => 3, a => "ABC", value => 93)^M
(gdb) PASS: gdb.ada/dynamic-iface.exp: print local as interface
...
but fails with gcc 7:
...
(gdb) print obj^M
$1 = ()^M
(gdb) FAIL: gdb.ada/dynamic-iface.exp: print local as interface
...
More concretely, we have trouble finding the type of obj. With gcc 8:
...
$ gdb -q -batch main -ex "b concrete.adb:20" -ex run -ex "ptype obj"
...
type = <ref> new concrete.intermediate with record
value: integer;
end record
...
and with gcc 7:
...
type = <ref> tagged record null; end record
...
The translation from tagged type to "full view" type happens in
ada_tag_value_at_base_address, where we hit this code:
...
/* Storage_Offset'Last is used to indicate that a dynamic offset to
top is used. In this situation the offset is stored just after
the tag, in the object itself. */
if (offset_to_top == last)
{
struct value *tem = value_addr (tag);
tem = value_ptradd (tem, 1);
tem = value_cast (ptr_type, tem);
offset_to_top = value_as_long (value_ind (tem));
}
...
resulting in an offset_to_top for gcc 8:
...
(gdb) p offset_to_top
$1 = -16
...
and for gcc 7:
...
(gdb) p offset_to_top
$1 = 16
...
The difference is expected, it bisects to gcc commit d0567dc0dbf ("[multiple
changes]") which mentions this change.
There's some code right after the code quoted above that deals with this
change:
...
else if (offset_to_top > 0)
{
/* OFFSET_TO_TOP used to be a positive value to be subtracted
from the base address. This was however incompatible with
C++ dispatch table: C++ uses a *negative* value to *add*
to the base address. Ada's convention has therefore been
changed in GNAT 19.0w 20171023: since then, C++ and Ada
use the same convention. Here, we support both cases by
checking the sign of OFFSET_TO_TOP. */
offset_to_top = -offset_to_top;
}
...
but it's not activated because of the 'else'.
Fix this by removing the 'else'.
Tested on x86_64-linux, with gcc 7.5.0.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29057
Even after the previous patches reworking the inheritance of several
breakpoint types, the present breakpoint hierarchy looks a bit
surprising, as we have "breakpoint" as the superclass, and then
"base_breakpoint" inherits from "breakpoint". Like so, simplified:
breakpoint
base_breakpoint
ordinary_breakpoint
internal_breakpoint
momentary_breakpoint
ada_catchpoint
exception_catchpoint
tracepoint
watchpoint
catchpoint
exec_catchpoint
...
The surprising part to me is having "base_breakpoint" being a subclass
of "breakpoint". I'm just refering to naming here -- I mean, you'd
expect that it would be the top level baseclass that would be called
"base".
Just flipping the names of breakpoint and base_breakpoint around
wouldn't be super great for us, IMO, given we think of every type of
*point as a breakpoint at the user visible level. E.g., "info
breakpoints" shows watchpoints, tracepoints, etc. So it makes to call
the top level class breakpoint.
Instead, I propose renaming base_breakpoint to code_breakpoint. The
previous patches made sure that all code breakpoints inherit from
base_breakpoint, so it's fitting. Also, "code breakpoint" contrasts
nicely with a watchpoint also being typically known as a "data
breakpoint".
After this commit, the resulting hierarchy looks like:
breakpoint
code_breakpoint
ordinary_breakpoint
internal_breakpoint
momentary_breakpoint
ada_catchpoint
exception_catchpoint
tracepoint
watchpoint
catchpoint
exec_catchpoint
...
... which makes a lot more sense to me.
I've left this patch as last in the series in case people want to
bikeshed on the naming.
"code" has a nice property that it's exactly as many letters as
"base", so this patch didn't require any reindentation. :-)
Change-Id: Id8dc06683a69fad80d88e674f65e826d6a4e3f66
Currently, init_ada_exception_catchpoint is defined in breakpoint.c, I
presume so it can call the static describe_other_breakpoints function.
I think this is a dependency inversion.
init_ada_exception_catchpoint, being code specific to Ada catchpoints,
should be in ada-lang.c, and describe_other_breakpoints, a core
function, should be exported.
And then, we can convert init_ada_exception_catchpoint to an
ada_catchpoint ctor.
Change-Id: I07695572dabc5a75d3d3740fd9b95db1529406a1
This commit changes ada_catchpoint_location's ctor from:
ada_catchpoint_location (breakpoint *owner)
to:
ada_catchpoint_location (ada_catchpoint *owner)
just to make the code better document intention.
To do this, we need to move the ada_catchpoint_location type's
definition to after ada_catchpoint is defined, otherwise the compiler
doesn't know that ada_catchpoint is convertible to struct breakpoint.
Change-Id: Id908b2e38bde30b262381e00c5637adb9bf0129d
The breakpoint c++-ification series introduced another bug in Ada --
it caused "catch exception" and related commands to fail on Windows.
The problem is that the re_set method calls the wrong superclass
method, so the breakpoint doesn't get correctly re-set when the
runtime offsets change. This patch fixes the problem.
This changes print_recreate_thread to be a method on breakpoint. This
function is only used as a helper by print_recreate methods, so I
thought this transformation made sense.
The breakpoint C++-ification series introduced a regression for Ada
catchpoints. Specifically, commit 2b5ab5b8 ("Convert base breakpoints
to vtable ops") caused these to start failing. I didn't notice this
because testing Ada using a Linux distro compiler requires installing
the GNAT debuginfo, which I hadn't done.
This patch fixes the problem. I'm checking it in.
This converts "ordinary" breakpoint to use vtable_breakpoint_ops.
Recall that an ordinary breakpoint is both the kind normally created
by users, and also a base class used by other classes.
This changes breakpoint_ops::print_one to return bool, and updates all
the implementations and the caller. The caller is changed so that a
NULL check is no longer needed -- something that will be impossible
with a real method.
Replace with calls to blockvector::blocks, and the appropriate method
call on the returned array_view.
Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
