Using the following patch that removes the reference_to_pointer_iterator
from breakpoint_range, I would get:
CXX breakpoint.o
/home/smarchi/src/binutils-gdb/gdb/breakpoint.c: In function ‘void breakpoint_program_space_exit(program_space*)’:
/home/smarchi/src/binutils-gdb/gdb/breakpoint.c:3030:46: error: cannot allocate an object of abstract type ‘breakpoint’
3030 | for (breakpoint &b : all_breakpoints_safe ())
| ^
In file included from /home/smarchi/src/binutils-gdb/gdb/gdbthread.h:26,
from /home/smarchi/src/binutils-gdb/gdb/infrun.h:21,
from /home/smarchi/src/binutils-gdb/gdb/gdbarch.h:28,
from /home/smarchi/src/binutils-gdb/gdb/arch-utils.h:23,
from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:21:
/home/smarchi/src/binutils-gdb/gdb/breakpoint.h:619:8: note: because the following virtual functions are pure within ‘breakpoint’:
619 | struct breakpoint : public intrusive_list_node<breakpoint>
| ^~~~~~~~~~
/home/smarchi/src/binutils-gdb/gdb/breakpoint.c:250:1: note: ‘virtual breakpoint::~breakpoint()’
250 | breakpoint::~breakpoint ()
| ^~~~~~~~~~
This is because the operator* method of the basic_safe_iterator iterator
wrapper returns a value_type. So, even if the method of the underlying
iterator (breakpoint_iterator, an intrusive_list iterator) returns a
`breakpoint &`, the method of the wrapper returns a `breakpoint`.
I think it would make sense for iterator wrappers such as
basic_safe_iterator to return the exact same thing as the iterator they
wrap. At least, it fixes my problem.
Change-Id: Ibbcd390ac03d2fb6ae4854923750c8d7c3c04e8a
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Remove the bp_location_pointer_iterator layer. Adjust all users of
breakpoint::locations to use references instead of pointers.
Change-Id: Iceed34f5e0f5790a9cf44736aa658be6d1ba1afa
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Replace the hand-maintained linked lists of breakpoint locations with
and intrusive list.
- Remove breakpoint::loc, add breakpoint::m_locations.
- Add methods for the various manipulations that need to be done on the
location list, while maintaining reasonably good encapsulation.
- bp_location currently has a default constructor because of one use
in hoist_existing_locations. hoist_existing_locations now returns a
bp_location_list, and doesn't need the default-constructor
bp_location anymore, so remove the bp_location default constructor.
- I needed to add a call to clear_locations in delete_breakpoint to
avoid a use-after-free.
- Add a breakpoint::last_loc method, for use in
set_breakpoint_condition.
bp_location_range uses reference_to_pointer_iterator, so that all
existing callers of breakpoint::locations don't need to change right
now. It will be removed in the next patch.
The rest of the changes are to adapt the call sites to use the new
methods, of breakpoint::locations, rather than breakpoint::loc directly.
Change-Id: I25f7ee3d66a4e914a0540589ac414b3b820b6e70
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Using the following patch, I would get this build failure:
CXX breakpoint.o
In file included from /usr/include/c++/13.1.1/bits/stl_algobase.h:66,
from /usr/include/c++/13.1.1/bits/hashtable_policy.h:36,
from /usr/include/c++/13.1.1/bits/hashtable.h:35,
from /usr/include/c++/13.1.1/bits/unordered_map.h:33,
from /usr/include/c++/13.1.1/unordered_map:41,
from /usr/include/c++/13.1.1/functional:63,
from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/ptid.h:35,
from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:206,
from /home/smarchi/src/binutils-gdb/gdb/defs.h:26,
from /home/smarchi/src/binutils-gdb/gdb/breakpoint.c:20:
/usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h: In instantiation of ‘constexpr void std::__advance(_BidirectionalIterator&, _Distance, bidirectional_iterator_tag) [with _BidirectionalIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; _Distance = long int]’:
/usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:224:21: required from ‘constexpr void std::advance(_InputIterator&, _Distance) [with _InputIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; _Distance = long int]’
/usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:237:19: required from ‘constexpr _InputIterator std::next(_InputIterator, typename iterator_traits<_Iter>::difference_type) [with _InputIterator = reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >; typename iterator_traits<_Iter>::difference_type = long int]’
/home/smarchi/src/binutils-gdb/gdb/breakpoint.c:1073:19: required from here
/usr/include/c++/13.1.1/bits/stl_iterator_base_funcs.h:179:11: error: no match for ‘operator--’ (operand type is ‘reference_to_pointer_iterator<intrusive_list_iterator<bp_location, intrusive_base_node<bp_location> > >’)
179 | --__i;
| ^~~~~
This points out that while intrusive_list_iterator has an operator--,
the reference_to_pointer_iterator wrapper does not. I'm not to sure why
the compiler chooses the overload of __advance that accepts a
_BidirectionalIterator, given that reference_to_pointer_iterator can't
be decremented, but adding those operators seems like the right thing to
do in any case, for completeness.
Change-Id: I8e2044b6734fadf0f21093047cf35bb7080dbdc3
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Add convenience first_loc methods to struct breakpoint (const and
non-const overloads). A subsequent patch changes the list of locations
to be an intrusive_list and makes the actual list private, so these
spots would need to change from:
b->loc
to something ugly like:
*b->locations ().begin ()
That would make the code much heavier and not readable. There is a
surprisingly big number of places that access the first location of
breakpoints. Whether this is correct, or these spots fail to consider
the possibility of multi-location breakpoints, I don't know. But
anyhow, I think that using this instead:
b->first_loc ()
conveys the intention better than the other two forms.
Change-Id: Ibbefe3e4ca6cdfe570351fe7e2725f2ce11d1e95
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Add three convenience methods to struct breakpoint:
- has_locations: returns true if the breakpoint has at least one
location
- has_single_location: returns true if the breakpoint has exactly one
location
- has_multiple_locations: returns true if the breakpoint has more than
one location
A subsequent patch changes the list of breakpoints to be an
intrusive_list, so all these spots would need to change. But in any
case, I think that this:
if (b->has_multiple_locations ())
conveys the intention better than:
if (b->loc != nullptr && b->loc->next != nullptr)
Change-Id: Ib18c3605fd35d425ef9df82cb7aacff1606c6747
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
The print_it method itself is const. In a subsequent patch, the
locations that come out of a const breakpoint will be const as well. It
will therefore be needed to make the last_loc output parameter const as
well. Make that change now to reduce the size of the following patches.
Change-Id: I7ed962950bc9582646e31e2e42beca2a1c9c5105
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Some implementations of breakpoint::check_status and
breakpoint::print_it do this:
struct breakpoint *b = bs->breakpoint_at;
bs->breakpoint_at is always the same as `this` (we can get convinced by
looking at the call sites of check_status and print_it), so it would
just be clearer to access fields through `this` instead.
Change-Id: Ic542a64fcd88e31ae2aad6feff1da278c7086891
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
I noticed some methods of syscall_catchpoint doing this:
struct gdbarch *gdbarch = loc->owner->gdbarch;
`loc` is the list of locations of this catchpoint. Logically, the owner
the locations are this catchpoint. So this just ends up getting
this->gdbarch. Remove the unnecessary indirection through the loc.
syscall_catchpoint::print_recreate does something slightly different,
getting its arch from the loc:
struct gdbarch *gdbarch = loc->gdbarch;
I suppose it's always going to be the same arch, so get it from the
catchpoint there too.
Change-Id: I6f6a6f8e0cd7cfb754cecfb6249e71ec12ba4855
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Add a checked_static_cast overload that works with references. A bad
dynamic cast with references throws std::bad_cast, it would be possible
to implement the new overload based on that, but it seemed simpler to
just piggy back off the existing function.
I found some potential uses of this new overload in amd-dbgapi-target.c,
update them to illustrate the use of the new overload. To build
amd-dbgapi-target.c, on needs the amd-dbgapi library, which I don't
expect many people to have. But I have it, and it builds fine here. I
did test the new overload by making a purposely bad cast and it did
catch it.
Change-Id: Id6b6a7db09fe3b4aa43cddb60575ff5f46761e96
Reviewed-By: Lancelot SIX <lsix@lancelotsix.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
After this commit:
commit ed32754a8c
Date: Thu Mar 9 10:45:03 2023 +0100
[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for remote target
I noticed the occasional failure in gdb.server/multi-ui-errors.exp,
which looked like this:
(gdb) PASS: gdb.server/multi-ui-errors.exp: interact with GDB's main UI
interrupt
(gdb)
Program received signal SIGINT, Interrupt.
0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6
FAIL: gdb.server/multi-ui-errors.exp: interrupt (timeout)
PASS: gdb.server/multi-ui-errors.exp: interrupt arrived
p server_pid
$1 = 718174
(gdb) PASS: gdb.server/multi-ui-errors.exp: p server_pid
This is triggered by this code in gdb.server/multi-ui-errors.exp:
gdb_test "interrupt"
gdb_test_multiple "" "interrupt arrived" {
-re "Program received signal SIGINT, Interrupt\\.\r\n" {
pass $gdb_test_name
}
}
The problem here is that the first interrupt will trigger the prompt
to be printed, and then, after some time the inferior will be
interrupted.
However the default pattern for gdb_test includes a '$' end anchor.
If expect sees the prompt with nothing following it then everything is
fine, and the test passes.
However, if the interrupt is quick and so what expect sees is this:
(gdb)
Program received signal SIGINT, Interrupt.
0x00007ffff7d501e7 in nanosleep () from /lib64/libc.so.6
In this case the end anchor means that the gdb_test fails to match,
and eventually times out.
Fix this by passing -no-prompt-anchor to gdb_test.
Reviewed-By: Tom de Vries <tdevries@suse.de>
If a header file defining a static function is included in multiple source
files, each calling the function, and GDB is asked to jump to a line inside
that function, there would be multiple locations matching the target. The
solution in this commit is to select the location in the current symtab.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This patch augments the DAP launch request with some optional new
parameters that let the client control the command-line arguments and
the environment of the inferior.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
This adds two new attributes and three new methods to gdb.Inferior.
The attributes let Python code see the command-line arguments and the
name of "main". Argument setting is also supported.
The methods let Python code manipulate the inferior's environment
variables.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
It's not worth avoiding an fseek to the same position, and can cause
problems if the linker's output file (which is opened "w+") is read,
because that can result in writing, reading, then writing again.
POSIX.1-2017 (IEEE Std 1003.1) says of fopen:
"When a file is opened with update mode ('+' as the second or third
character in the mode argument), both input and output may be
performed on the associated stream. However, the application shall
ensure that output is not directly followed by input without an
intervening call to fflush() or to a file positioning function
(fseek(), fsetpos(), or rewind()), and input is not directly followed
by output without an intervening call to a file positioning function,
unless the input operation encounters end-of-file."
* bfdio.c (bfd_seek): Always call iovec->bseek.
This adds a 'global_context' parse_and_eval to gdb.parse_and_eval.
This lets users request a parse that is done at "global scope".
I considered letting callers pass in a block instead, with None
meaning "global" -- but then there didn't seem to be a clean way to
express the default for this parameter.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
This adds a PARSER_LEAVE_BLOCK_ALONE flag, and changes the parse API
to respect it. This flag lets callers avoid any change to the
passed-in block and expression PC, letting them specify the context
exactly. In particular, now nullptr can be used to indicate that the
parse should not examine any local variables.
This patch adds a new parser_flags type and changes the parser APIs to
use it rather than a collection of 'int' and 'bool'. More flags will
be added in subsquent patches.
I think parser-defs.h should hold declarations that can be used by
parser implementations, whereas expression.h should hold declarations
that are used by code that wants to call a parser. Following this
logic, this patch moves innermost_block_tracker to expression.h.
This adds a new Python function, gdb.execute_mi, that can be used to
invoke an MI command but get the output as a Python object, rather
than a string. This is done by implementing a new ui_out subclass
that builds a Python object.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11688
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
This adds a second mi_parse constructor. This constructor takes a
command name and vector of arguments, and does not do any escape
processing. This also changes mi_parse::args to handle parse objects
created this new way.
This changes mi_parse::args to be a private member, retrieved via
accessor. It also changes this member to be a std::string. This
makes it simpler for a subsequent patch to implement different
behavior for argument parsing.
If an MI command written in Python includes a number in its output,
currently that is simply emitted as a string. However, it's
convenient for a later patch if these are emitted using field_signed.
This does not make a difference to ordinary MI clients.
clear_current_line overwrites the current line with chars_per_line
blank spaces. Printing the final space triggers a condition in
pager_file::puts that causes lines_printed to be incremented. If
lines_printed becomes greater than or equal to lines_allowed, the
pagination prompt will appear if enabled.
In this case the prompt is unnecessary since after printing the final
space clear_current_line immediately moves the cursor to the beginning
of the line with '\r'. A new line isn't actually started, so the prompt
ends up being spurious.
Additionally it's possible for gdb to crash during this pagination prompt.
Answering the prompt with 'q' throws an exception intended to bring gdb
back to the main event loop. But since commit 0fea10f327,
clear_current_line may be called under the progress_update destructor.
The exception will try to propagate through the destructor, causing an abort.
To fix this, pagination is disabled for the duration for clear_current_line.
clear_current_line is also renamed to clear_progress_notify to help
indicate that it is a special purpose function intended for use with
do_progress_notify.
Acked-by: Eli Zaretskii <eliz@gnu.org>
normally RELA relocs in BFD should not consider the contents of the
relocated place. The aarch64 psABI is even stricter, it specifies
(section 5.7.16) that all RELA relocs _must_ be idempotent.
Since the inception of the aarch64 BFD backend all the relocs have a
non-zero src_mask, and hence break this invariant. It's normally not
a very visible problem as one can see it only when the relocated place
already contains a non-zero value, which usually only happens sometimes
when using 'ld -r' (or as in the testcase when jumping through hoops to
generate the relocations). Or with alternative toolchains that do encode
stuff in the relocated places with the assumption that a relocation
to that place ignores whatever is there (as they can according to
the psABI).
Golang is such a toolchain and https://github.com/golang/go/issues/39927
is ultimately caused by this problem: the testcase testGCData failing
is caused by the garbage collection data-structure to describe a type
containing pointers to be wrong. It's wrong because a field that's
supposed to contain a file-relative offset (to some gcbits) has a
relocation applied and that relocation has an addend which also is
already part of the go-produced object file (so the addend is
implicitely applied twice).
bfd/
PR ld/30437
* elfnn-aarch64.c (elfNN_aarch64_howto_table): Clear src_mask
if all relocation descriptors.
ld/
* testsuite/ld-aarch64/rela-idempotent.s: New testcase.
* testsuite/ld-aarch64/rela-idempotent.d: New.
* testsuite/ld-aarch64/aarch64-elf.exp: Run it.
When testing gdb.arch/disp-step-insn-reloc.exp with clang in an x86_64
machine, the compiled test case would segfault when returning from
the function can_relocate_call, with a suggestion of a broken stack.
The example assembly in the commment was the following:
f:
MOV $1, %[ok]
JMP end
set_point0:
CALL f ; tracepoint here.
end:
And the segmentation fault happening at the final "ret" instruction of
can_relocate_call. Looking at the disassembled version of the later
half of the important function, we see:
Clang version (f starting at 11a4):
00000000000011ae <set_point0>:
11ae: e8 f1 ff ff ff callq 11a4 <can_relocate_call+0x14>
11b3: 89 45 fc mov %eax,-0x4(%rbp)
11b6: 83 7d fc 01 cmpl $0x1,-0x4(%rbp)
11ba: 0f 85 0a 00 00 00 jne 11ca <set_point0+0x1c>
11c0: e8 5b 00 00 00 callq 1220 <pass>
11c5: e9 05 00 00 00 jmpq 11cf <set_point0+0x21>
11ca: e8 61 00 00 00 callq 1230 <fail>
11cf: 48 83 c4 10 add $0x10,%rsp
11d3: 5d pop %rbp
11d4: c3 retq
11d5: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1)
11dc: 00 00 00 00
gcc version (f starting at 401125):
000000000040112c <set_point0>:
40112c: e8 f4 ff ff ff callq 401125 <can_relocate_call+0x11>
401131: 89 45 fc mov %eax,-0x4(%rbp)
401134: 83 7d fc 01 cmpl $0x1,-0x4(%rbp)
401138: 75 07 jne 401141 <set_point0+0x15>
40113a: e8 c7 ff ff ff callq 401106 <pass>
40113f: eb 05 jmp 401146 <set_point0+0x1a>
401141: e8 c7 ff ff ff callq 40110d <fail>
401146: 90 nop
401147: c9 leaveq
401148: c3 retq
The epilogue of set_point0 (11cf for clang, 401146 for gcc) is the main
difference: GCC's version uses the leaveq instruction, which resets rsp
based on rbp, while clang adds the same constant to rsp that it
subtracted in the prologue. Clang fails because the return address that
is added by the "call f" instruction isn't accounted for.
This commit fixes that by adding a return instruction to f, which leaves
the rsp as the compilers would expect.
Approved-By: Andrew Burgess <aburgess@redhat.com>
If in a "word ptr <address>" or alike construct the "ptr" part is
double-quoted, it shouldn't be recognized as the specific keyword we're
looking for (just like we don't recognize double-quoted operator or
register names anymore). Be careful though to tell closing from opening
double-quotes, as a quoted symbol may follow right afterwards.
The concept of quoted symbols names was introduced pretty late. Utilize
it to allow access to symbols with names matching that of a register (or,
in Intel syntax, also an identifier-like operator).
This is primarily to aid gcc when generating Intel syntax output; see
their bug target/53929.
