| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Currently, each target backend is responsible for printing "[Thread
...exited]" before deleting a thread. This leads to unnecessary
differences between targets, like e.g. with the remote target, we
never print such messages, even though we do print "[New Thread ...]".
E.g., debugging the gdb.threads/attach-many-short-lived-threads.exp
with gdbserver, letting it run for a bit, and then pressing Ctrl-C, we
currently see:
(gdb) c
Continuing.
^C[New Thread 3850398.3887449]
[New Thread 3850398.3887500]
[New Thread 3850398.3887551]
[New Thread 3850398.3887602]
[New Thread 3850398.3887653]
...
Thread 1 "attach-many-sho" received signal SIGINT, Interrupt.
0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80)
at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c
(gdb)
Above, we only see "New Thread" notifications, even though threads
were deleted.
After this patch, we'll see:
(gdb) c
Continuing.
^C[Thread 3558643.3577053 exited]
[Thread 3558643.3577104 exited]
[Thread 3558643.3577155 exited]
[Thread 3558643.3579603 exited]
...
[New Thread 3558643.3597415]
[New Thread 3558643.3600015]
[New Thread 3558643.3599965]
...
Thread 1 "attach-many-sho" received signal SIGINT, Interrupt.
0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80)
at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c
(gdb) q
This commit fixes this by moving the thread exit printing to common
code instead, triggered from within delete_thread (or rather,
set_thread_exited).
There's one wrinkle, though. While most targest want to print:
[Thread ... exited]
the Windows target wants to print:
[Thread ... exited with code <exit_code>]
... and sometimes wants to suppress the notification for the main
thread. To address that, this commits adds a delete_thread_with_code
function, only used by that target (so far).
This fix was originally posted as part of a larger series:
https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-1-pedro@palves.net/
But didn't really need to be part of that series. In order to get
this fix merged sooner, I (Andrew Burgess) have rebased this commit
outside of the original series. Any bugs introduced while splitting
this patch out and rebasing, are entirely my own.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30129
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
|
|
Remove the static mi_parse::make functions, and instead use the
mi_parse constructor.
This is a partial revert of the commit:
commit fde3f93adb50c9937cd2e1c93561aea2fd167156
Date: Mon Mar 20 10:56:55 2023 -0600
Introduce "static constructor" for mi_parse
which introduced the mi_parse::make functions, though after discussion
on the list the reasons for seem to have been lost[1]. Given there
are no test regressions when moving back to using the constructors, I
propose we should do that for now.
There should be no user visible changes after this commit.
[1] https://inbox.sourceware.org/gdb-patches/20230404-dap-loaded-sources-v2-5-93f229095e03@adacore.com/
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Have the mi_out_new function return a std::unique_ptr instead of a raw
pointer. Update the two uses of mi_out_new.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I found that most spots including psymtab.h do not need it. This
patch removes these includes, and also one unnecessary include of
psympriv.h.
|
|
This commit extends the breakpoint mechanism to allow for inferior
specific breakpoints (but not watchpoints in this commit).
As GDB gains better support for multiple connections, and so for
running multiple (possibly unrelated) inferiors, then it is not hard
to imagine that a user might wish to create breakpoints that apply to
any thread in a single inferior. To achieve this currently, the user
would need to create a condition possibly making use of the $_inferior
convenience variable, which, though functional, isn't the most user
friendly.
This commit adds a new 'inferior' keyword that allows for the creation
of inferior specific breakpoints.
Inferior specific breakpoints are automatically deleted when the
associated inferior is removed from GDB, this is similar to how
thread-specific breakpoints are deleted when the associated thread is
deleted.
Watchpoints are already per-program-space, which in most cases mean
watchpoints are already inferior specific. There is a small window
where inferior-specific watchpoints might make sense, which is after a
vfork, when two processes are sharing the same address space.
However, I'm leaving that as an exercise for another day. For now,
attempting to use the inferior keyword with a watchpoint will give an
error, like this:
(gdb) watch a8 inferior 1
Cannot use 'inferior' keyword with watchpoints
A final note on the implementation: currently, inferior specific
breakpoints, like thread-specific breakpoints, are inserted into every
inferior, GDB then checks once the inferior stops if we are in the
correct thread or inferior, and resumes automatically if we stopped in
the wrong thread/inferior.
An obvious optimisation here is to only insert breakpoint locations
into the specific program space (which mostly means inferior) that
contains either the inferior or thread we are interested in. This
would reduce the number times GDB has to stop and then resume again in
a multi-inferior setup.
I have a series on the mailing list[1] that implements this
optimisation for thread-specific breakpoints. Once this series has
landed I'll update that series to also handle inferior specific
breakpoints in the same way. For now, inferior specific breakpoints
are just slightly less optimal, but this is no different to
thread-specific breakpoints in a multi-inferior debug session, so I
don't see this as a huge problem.
[1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/
|
|
Simon noticed a crash that could be caused via new Python
gdb.execute_mi function. Looking into this, I found a few unchecked
casts to mi_interp, like:
- struct mi_interp *mi = (struct mi_interp *) command_interp ();
This patch replaces all such casts with safer variants.
For -gdb-exit and mi_load_progress, I chose to have the functions
simply not generate any output. It didn't seem useful to do so.
Some casts I eliminated by adding a parameter to a function. Then, in
mi_execute_command, I changed the code to use
gdb::checked_static_cast. This is appropriate because this particular
overload can only be called by the MI interpreter.
There does not seem to be a very good way to test -gdb-exit.
Regression tested on x86-64 Fedora 36.
|
|
This changes mi_parse::command to be a unique_xmalloc_ptr and fixes up
all the uses. This avoids some manual memory management. std::string
is not used here due to how the Python API works -- this approach
avoids an extra copy there.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
This changes the MI "token" to be a std::string, removing some manual
memory management. It also makes current_token 'const' in order to
support this change.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
This changes the ada_catchpoint to require an rvalue ref, so that
ownership of the exception string can be transferred to the catchpoint
object.
|
|
Fix a few typos:
- implemention -> implementation
- convertion(s) -> conversion(s)
- backlashes -> backslashes
- signoring -> ignoring
- (un)ambigious -> (un)ambiguous
- occured -> occurred
- hidding -> hiding
- temporarilly -> temporarily
- immediatelly -> immediately
- sillyness -> silliness
- similiar -> similar
- porkuser -> pokeuser
- thats -> that
- alway -> always
- supercede -> supersede
- accomodate -> accommodate
- aquire -> acquire
- priveleged -> privileged
- priviliged -> privileged
- priviledges -> privileges
- privilige -> privilege
- recieve -> receive
- (p)refered -> (p)referred
- succesfully -> successfully
- successfuly -> successfully
- responsability -> responsibility
- wether -> whether
- wich -> which
- disasbleable -> disableable
- descriminant -> discriminant
- construcstor -> constructor
- underlaying -> underlying
- underyling -> underlying
- structureal -> structural
- appearences -> appearances
- terciarily -> tertiarily
- resgisters -> registers
- reacheable -> reachable
- likelyhood -> likelihood
- intepreter -> interpreter
- disassemly -> disassembly
- covnersion -> conversion
- conviently -> conveniently
- atttribute -> attribute
- struction -> struct
- resonable -> reasonable
- popupated -> populated
- namespaxe -> namespace
- intialize -> initialize
- identifer(s) -> identifier(s)
- expection -> exception
- exectuted -> executed
- dungerous -> dangerous
- dissapear -> disappear
- completly -> completely
- (inter)changable -> (inter)changeable
- beakpoint -> breakpoint
- automativ -> automatic
- alocating -> allocating
- agressive -> aggressive
- writting -> writing
- reguires -> requires
- registed -> registered
- recuding -> reducing
- opeartor -> operator
- ommitted -> omitted
- modifing -> modifying
- intances -> instances
- imbedded -> embedded
- gdbaarch -> gdbarch
- exection -> execution
- direcive -> directive
- demanged -> demangled
- decidely -> decidedly
- argments -> arguments
- agrument -> argument
- amespace -> namespace
- targtet -> target
- supress(ed) -> suppress(ed)
- startum -> stratum
- squence -> sequence
- prompty -> prompt
- overlow -> overflow
- memember -> member
- languge -> language
- geneate -> generate
- funcion -> function
- exising -> existing
- dinking -> syncing
- destroh -> destroy
- clenaed -> cleaned
- changep -> changedp (name of variable)
- arround -> around
- aproach -> approach
- whould -> would
- symobl -> symbol
- recuse -> recurse
- outter -> outer
- freeds -> frees
- contex -> context
Tested on x86_64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
I found the documentation for -dprintf-insert a bit unclear. It
didn't mention the possibility of multiple arguments, and I also
noticed that it implied that the format parameter is optional, which
it is not.
While looking into this I also noticed a few comments in the
implementation that could also be improved.
Then, I noticed a repeated call to strlen in a loop condition, so I
fixed this up as well.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Same idea as previous patches, but for memory_changed.
Change-Id: Ic19f20c24d8a6431d4a89c5625e8ef4898f76e82
|
|
Same idea as previous patches, but for command_param_changed.
Change-Id: I7c2196343423360da05f016f8ffa871c064092bb
|
|
Same idea as previous patches, but for breakpoint_modified.
Change-Id: I4f0a9edea912de431e32451d74224b2022a7c328
|
|
Same idea as previous patches, but for breakpoint_deleted.
Change-Id: I59c231ce963491bb1eee1432ee1090138f09e19c
|
|
Same idea as previous patches, but for breakpoint_created.
Change-Id: I614113c924edc243590018b8fb3bf69cb62215ef
|
|
Same idea as previous patches, but for tsv_modified.
Change-Id: I55454a2386d5450040b3a353909b26f389a43682
|
|
Same idea as previous patches, but for tsv_deleted.
Change-Id: I71b0502b493da7b6e293bee02aeca98de83d4b75
|
|
Same idea as previous patches, but for tsv_created.
Change-Id: I9c30ecfdbd78ca015d613f43a0c0aef6c7eb32b5
|
|
Same idea as previous patches, but for traceframe_changed.
Change-Id: Ia473f07d70d57b30aca0094d0e0585d7e0d95637
|
|
Same idea as previous patches, but for about_to_proceed. We only need
(and want, as far as the mi_interp implementation is concerned) to
notify the interpreter that caused the proceed.
Change-Id: Id259bca10dbc3d43d46607ff7b95243a9cbe2f89
|
|
Same idea as previous patches, but for solib_unloaded.
Change-Id: Iad847de93f0b38b5c90679a173d3beeaed7af6c5
|
|
Same idea as previous patches, but for solib_loaded
Change-Id: I85edb0a4b377f4b2c39ffccf31cb75f38bae0f55
|
|
Same idea as previous patches, but for target_resumed.
Change-Id: I66fa28d1d41a1f3c4fb0d6a470137d493eac3c8c
|
|
Same idea as previous patches, but for record_changed
Change-Id: I5eeeacd703af8401c315060514c94e8e6439cc40
|
|
Same idea as previous patches, but for inferior_removed.
Change-Id: I7971840bbbdcfabf77e2ded7584830c9dfdd10d0
|
|
Same idea as previous patches, but for inferior_disappeared.
For symmetry with on_inferior_appeared, I named this one
on_inferior_disappeared, despite the observer being called
inferior_exit. This is called when detaching an inferior, so I think
that calling it "disappeared" is a bit less misleading (the observer
should probably be renamed later).
Change-Id: I372101586bc9454997953c1e540a2a6685f53ef6
|
|
Same idea as previous patches, but for inferior_appeared.
Change-Id: Ibe4feba34274549a886b1dfb5b3f8d59ae79e1b5
|
|
Same idea as previous patches, but for inferior_added.
mi_interp::init avoided using mi_inferior_added, since, as the comment
used to say, it would notify all MI interpreters. Now, it's easy to
only notify the new interpreter, so it's possible to just call the
on_inferior_added method in mi_interp::init.
Change-Id: I0eddbd5367217d1c982516982089913019ef309f
|
|
Same idea as previous patches, but for thread_exited.
Change-Id: I4be974cbe58cf635453fef503c2d77c82522cbd9
|
|
Same idea as previous patches, but for new_thread.
Change-Id: Ib70ae3421b736fd69d86c4e7c708bec349aa256c
|
|
Same as previous patches, but for user_selected_context_changed.
Change-Id: I40de15be897671227d4bcf3e747f0fd595f0d5be
|
|
Same idea as the previous patches, but for command_error.
Change-Id: If6098225dd72fad8be13b3023b35bc8bc48efb9d
|
|
Same as previous patches, but for sync_execution_done. Except that
here, we only want to notify the interpreter that is executing the
command, not all interpreters.
Change-Id: I729c719447b5c5f29af65dbf6fed9132e2cd308b
|
|
Same as previous patches, but for no_history.
Change-Id: I06930fe7cb4082138c6c5496c5118fe4951c10da
|
|
Same as previous patch, but for exited. Remove the exited observable,
since nothing uses it anymore, and we don't have anything coming that
will use it.
Change-Id: I358cbea0159af56752dfee7510d6a86191e722bb
|
|
Same as previous patch, but for signal_exited. Remove the signal_exited
observable, since nothing uses it anymore, and we don't have anything
coming that will use it.
Change-Id: I0dca1eab76338bf27be755786e3dad3241698b10
|
|
Same idea as the previous patch, but for the normal_stop event.
Change-Id: I4fc8ca8a51c63829dea390a2b6ce30b77f9fb863
|
|
Instead of having the interpreter code registering observers for the
signal_received observable, add a "signal_received" virtual method to
struct interp. Add a interps_notify_signal_received function that loops
over all UIs and calls the signal_received method on the interpreter.
Finally, add a notify_signal_received function that calls
interps_notify_signal_received and then notifies the observers. Replace
all existing notifications to the signal_received observers with calls
to notify_signal_received.
Before this patch, the CLI and MI code both register a signal_received
observer. These observer go over all UIs, and, for those that have a
interpreter of the right kind, print the stop notifiation.
After this patch, we have just one "loop over all UIs", inside
interps_notify_signal_received. Since the interp::on_signal_received
method gets called once for each interpreter, the implementations only
need to deal with the current interpreter (the "this" pointer).
The motivation for this patch comes from a future patch, that makes the
amdgpu code register an observer to print a warning after the CLI's
signal stop message. Since the amdgpu and the CLI code both use
observers, the order of the two messages is not stable, unless we define
the priority using the observer dependency system. However, the
approach of using virtual methods on the interpreters seems like a good
change anyway, I think it's more straightforward and simple to
understand than the current solution that uses observers. We are sure
that the amdgpu message gets printed after the CLI message, since
observers are notified after interpreters.
Keep the signal_received, even if nothing uses if, because we will be
using it in the upcoming amdgpu patch implementing the warning described
above.
Change-Id: I4d8614bb8f6e0717f4bfc2a59abded3702f23ac4
|
|
I stumbled on the mi_proceeded and running_result_record_printed
globals, which are shared by all MI interpreter instances (it's unlikely
that people use multiple MI interpreter instances, but it's possible).
After poking at it, I found this bug:
1. Start GDB in MI mode
2. Add a second MI interpreter with the new-ui command
3. Use -exec-run on the second interpreter
This is the output I get on the first interpreter:
=thread-group-added,id="i1"
~"Reading symbols from a.out...\n"
~"New UI allocated\n"
(gdb)
=thread-group-started,id="i1",pid="94718"
=thread-created,id="1",group-id="i1"
^running
*running,thread-id="all"
And this is the output I get on the second intepreter:
=thread-group-added,id="i1"
(gdb)
-exec-run
=thread-group-started,id="i1",pid="94718"
=thread-created,id="1",group-id="i1"
*running,thread-id="all"
The problem here is that the `^running` reply to the -exec-run command
is printed on the wrong UI. It is printed on the first one, it should
be printed on the second (the one on which we sent the -exec-run).
What happens under the hood is that captured_mi_execute_command, while
executing a command for the second intepreter, clears the
running_result_record_printed and mi_proceeded globals.
mi_about_to_proceed then sets mi_proceeded. Then, mi_on_resume_1 gets
called for the first intepreter first. Since the
!running_result_record_printed && mi_proceeded
condition is true, it prints a ^running, and sets
running_result_record_printed. When mi_on_resume_1 gets called for the
second interpreter, running_result_record_printed is already set, so
^running is not printed there.
It took me a while to understand the relationship between these two
variables. I think that in the end, this is what we want to track:
1. When executing an MI command, take note if that command causes a
"proceed". This is done in mi_about_to_proceed.
2. In mi_on_resume_1, if the command indeed caused a "proceed", we want
to output a ^running record. And we want to remember that we did,
because...
3. Back in captured_mi_execute_command, if we did not output a
^running, we want to output a ^done.
Moving those two variables to the mi_interp struture appears to fix it.
Only for the interpreter doing the -exec-run command does the
running_result_record_printed flag get cleared, and therefore only or
that one does the ^running record get printed.
Add a new test for this, that does pretty much what the reproducer above
shows. Without the fix, the test fails because
mi_send_resuming_command_raw never sees the ^running record.
Change-Id: I63ea30e6cb61a8e1dd5ef03377e6003381a9209b
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
I've had this patch for a while now and figured I'd update it and send
it. It changes MI commands to use a "const char * const" for their
argv parameter.
Regression tested on x86-64 Fedora 36.
Acked-By: Simon Marchi <simon.marchi@efficios.com>
|
|
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 introduces some helper methods for mi_parse that handle some of
the details of parsing. This approach lets us reuse them later.
|
|
Change the mi_parse function to be a static method of mi_parse. This
lets us remove the 'set_args' setter function.
|
|
This changes mi_parse_argv to be a method of mi_parse. This is just a
minor cleanup.
|
|
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.
|
|
This changes mi_parse to use member initializers rather than a
constructor. This is easier to follow.
|
|
SUMMARY
The '--simple-values' argument to '-stack-list-arguments' and similar
GDB/MI commands does not take reference types into account, so that
references to arbitrarily large structures are considered "simple" and
printed. This means that the '--simple-values' argument cannot be used
by IDEs when tracing the stack due to the time taken to print large
structures passed by reference.
DETAILS
Various GDB/MI commands ('-stack-list-arguments', '-stack-list-locals',
'-stack-list-variables' and so on) take a PRINT-VALUES argument which
may be '--no-values' (0), '--all-values' (1) or '--simple-values' (2).
In the '--simple-values' case, the command is supposed to print the
name, type, and value of variables with simple types, and print only the
name and type of variables with compound types.
The '--simple-values' argument ought to be suitable for IDEs that need
to update their user interface with the program's call stack every time
the program stops. However, it does not take C++ reference types into
account, and this makes the argument unsuitable for this purpose.
For example, consider the following C++ program:
struct s {
int v[10];
};
int
sum(const struct s &s)
{
int total = 0;
for (int i = 0; i < 10; ++i) total += s.v[i];
return total;
}
int
main(void)
{
struct s s = { { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } };
return sum(s);
}
If we start GDB in MI mode and continue to 'sum', the behaviour of
'-stack-list-arguments' is as follows:
(gdb)
-stack-list-arguments --simple-values
^done,stack-args=[frame={level="0",args=[{name="s",type="const s &",value="@0x7fffffffe310: {v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}}"}]},frame={level="1",args=[]}]
Note that the value of the argument 's' was printed, even though 's' is
a reference to a structure, which is not a simple value.
See https://github.com/microsoft/MIEngine/pull/673 for a case where this
behaviour caused Microsoft to avoid the use of '--simple-values' in
their MIEngine debug adapter, because it caused Visual Studio Code to
take too long to refresh the call stack in the user interface.
SOLUTIONS
There are two ways we could fix this problem, depending on whether we
consider the current behaviour to be a bug.
1. If the current behaviour is a bug, then we can update the behaviour
of '--simple-values' so that it takes reference types into account:
that is, a value is simple if it is neither an array, struct, or
union, nor a reference to an array, struct or union.
In this case we must add a feature to the '-list-features' command so
that IDEs can detect that it is safe to use the '--simple-values'
argument when refreshing the call stack.
2. If the current behaviour is not a bug, then we can add a new option
for the PRINT-VALUES argument, for example, '--scalar-values' (3),
that would be suitable for use by IDEs.
In this case we must add a feature to the '-list-features' command
so that IDEs can detect that the '--scalar-values' argument is
available for use when refreshing the call stack.
PATCH
This patch implements solution (1) as I think the current behaviour of
not printing structures, but printing references to structures, is
contrary to reasonable expectation.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29554
|
|
I'd like to move some things so they become methods on struct ui. But
first, I think that struct ui and the related things are big enough to
deserve their own file, instead of being scattered through top.{c,h} and
event-top.c.
Change-Id: I15594269ace61fd76ef80a7b58f51ff3ab6979bc
|
