gdb: parse pending breakpoint thread/task immediately
The initial motivation for this commit was to allow thread or inferior
specific breakpoints to only be inserted within the appropriate
inferior's program-space. The benefit of this is that inferiors for
which the breakpoint does not apply will no longer need to stop, and
then resume, for such breakpoints. This commit does not make this
change, but is a refactor to allow this to happen in a later commit.
The problem we currently have is that when a thread-specific (or
inferior-specific) breakpoint is created, the thread (or inferior)
number is only parsed by calling find_condition_and_thread_for_sals.
This function is only called for non-pending breakpoints, and requires
that we know the locations at which the breakpoint will be placed (for
expression checking in case the breakpoint is also conditional).
A consequence of this is that by the time we figure out the breakpoint
is thread-specific we have already looked up locations in all program
spaces. This feels wasteful -- if we knew the thread-id earlier then
we could reduce the work GDB does by only looking up locations within
the program space for which the breakpoint applies.
Another consequence of how find_condition_and_thread_for_sals is
called is that pending breakpoints don't currently know they are
thread-specific, nor even that they are conditional! Additionally, by
delaying parsing the thread-id, pending breakpoints can be created for
non-existent threads, this is different to how non-pending
breakpoints are handled, so I can do this:
$ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
(gdb) break foo thread 99
Function "foo" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (foo thread 99) pending.
(gdb) r
Starting program: /tmp/gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Error in re-setting breakpoint 1: Unknown thread 99.
[Inferior 1 (process 3329749) exited normally]
(gdb)
GDB only checked the validity of 'thread 99' at the point the 'foo'
location became non-pending. In contrast, if I try this:
$ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
(gdb) break main thread 99
Unknown thread 99.
(gdb)
GDB immediately checks if 'thread 99' exists. I think inconsistencies
like this are confusing, and should be fixed if possible.
In this commit the create_breakpoint function is updated so that the
extra_string, which contains the thread, inferior, task, and/or
condition information, is parsed immediately, even for pending
breakpoints.
Obviously, the condition still can't be validated until the breakpoint
becomes non-pending, but the thread, inferior, and task information
can be pulled from the extra-string, and can be validated early on,
even for pending breakpoints. The -force-condition flag is also
parsed as part of this early parsing change.
There are a couple of benefits to doing this:
1. Printing of breakpoints is more consistent now. Consider creating
a conditional breakpoint before this commit:
(gdb) set breakpoint pending on
(gdb) break pendingfunc if (0)
Function "pendingfunc" not defined.
Breakpoint 1 (pendingfunc if (0)) pending.
(gdb) break main if (0)
Breakpoint 2 at 0x401198: file /tmp/hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> pendingfunc if (0)
2 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18
stop only if (0)
(gdb)
And after this commit:
(gdb) set breakpoint pending on
(gdb) break pendingfunc if (0)
Function "pendingfunc" not defined.
Breakpoint 1 (pendingfunc) pending.
(gdb) break main if (0)
Breakpoint 2 at 0x401198: file /home/andrew/tmp/hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> pendingfunc
stop only if (0)
2 breakpoint keep y 0x0000000000401198 in main at /home/andrew/tmp/hello.c:18
stop only if (0)
(gdb)
Notice that the display of the condition is now the same for the
pending and non-pending breakpoints.
The same is true for the thread, inferior, or task information in
thread, inferior, or task specific breakpoints; this information is
displayed on its own line rather than being part of the 'What'
field.
2. We can check that the thread exists as soon as the pending
breakpoint is created. Currently there is a weird difference
between pending and non-pending breakpoints when creating a
thread-specific breakpoint.
A pending thread-specific breakpoint only checks its thread when it
becomes non-pending, at which point the thread the breakpoint was
intended for might have exited. Here's the behaviour before this
commit:
(gdb) set breakpoint pending on
(gdb) break foo thread 2
Function "foo" not defined.
Breakpoint 2 (foo thread 2) pending.
(gdb) c
Continuing.
[Thread 0x7ffff7c56700 (LWP 2948835) exited]
Error in re-setting breakpoint 2: Unknown thread 2.
[Inferior 1 (process 2948832) exited normally]
(gdb)
Notice the 'Error in re-setting breakpoint 2: Unknown thread 2.'
line, this was triggered when GDB tried to make the breakpoint
non-pending, and GDB discovers that the thread no longer exists.
Compare that to the behaviour after this commit:
(gdb) set breakpoint pending on
(gdb) break foo thread 2
Function "foo" not defined.
Breakpoint 2 (foo) pending.
(gdb) c
Continuing.
[Thread 0x7ffff7c56700 (LWP 2949243) exited]
Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list.
[Inferior 1 (process 2949240) exited normally]
(gdb)
Now the behaviour for pending breakpoints is identical to
non-pending breakpoints, the thread specific breakpoint is removed
as soon as the thread the breakpoint is associated with exits.
There is an additional change; when the pending breakpoint is
created prior to this patch we see this line:
Breakpoint 2 (foo thread 2) pending.
While after this patch we get this line:
Breakpoint 2 (foo) pending.
Notice that 'thread 2' has disappeared. This might look like a
regression, but I don't think it is. That we said 'thread 2'
before was just a consequence of the lazy parsing of the breakpoint
specification, while with this patch GDB understands, and has
parsed away the 'thread 2' bit of the spec. If folk think the old
information was useful then this would be trivial to add back in
code_breakpoint::say_where.
As a result of this commit the breakpoints 'extra_string' field is now
only used by bp_dprintf type breakpoints to hold the printf format and
arguments. This string should always be empty for other breakpoint
types. This allows some cleanup in print_breakpoint_location.
In code_breakpoint::code_breakpoint I've changed an error case into an
assert. This is because the error is now handled earlier in
create_breakpoint. As a result we know that by this point, the
extra_string will always be nullptr for anything other than a
bp_dprintf style breakpoint.
The find_condition_and_thread_for_sals function is now no longer
needed, this was previously doing the delayed splitting of the extra
string into thread, task, and condition, but this is now all done in
create_breakpoint, so find_condition_and_thread_for_sals can be
deleted, and the code that calls this in
code_breakpoint::location_spec_to_sals can be removed. With this
update this code would only ever be reached for bp_dprintf style
breakpoints, and in these cases the extra_string should not contain
anything other than format and args.
The most interesting changes are all in create_breakpoint and in the
new file break-cond-parse.c. We have a new block of code early on in
create_breakpoint that is responsible for splitting the extra_string
into its component parts by calling create_breakpoint_parse_arg_string
a function in the new break-cond-parse.c file. This means that some
of the later code can be simplified a little.
The new break-cond-parse.c file implements the splitting up the
extra_string and finding all the parts, as well as some self-tests for
the new function.
Finally, now we know all the breakpoint details, these can be stored
within the breakpoint object if we end up creating a deferred
breakpoint. Additionally, if we are creating a deferred bp_dprintf we
can parse the extra_string to build the printf command.
The implementation here aims to maintain backwards compatibility as
much as possible, this means that:
1. We support abbreviations of 'thread', 'task', and 'inferior' in
some places on the breakpoint line. The handling of abbreviations
has (before this patch) been a little weird, so this works:
(gdb) break *main th 1
And creates a breakpoint at '*main' for thread 1 only, while this
does not work:
(gdb) break main th 1
In this case GDB will try to find the symbol 'main th 1'. This
weirdness exists before and after this patch.
2. The handling of '-force-condition' is odd, if this flag appears
immediately after a condition then it will be treated as part of the
condition, e.g.:
(gdb) break main if 0 -force-condition
No symbol "force" in current context.
But we are fine with these alternatives:
(gdb) break main if 0 thread 1 -force-condition
(gdb) break main -force-condition if 0
Again, this is just a quirk of how the breakpoint line used to be
parsed, but I've maintained this for backward compatibility. During
review it was suggested that -force-condition should become an
actual breakpoint flag (i.e. only valid after the 'break' command
but before the function name), and I don't think that would be a
terrible idea, however, that's not currently a trivial change, and I
think should be done as a separate piece of work. For now, this
patch just maintains the current behaviour.
The implementation works by first splitting the breakpoint condition
string (everything after the location specification) into a list of
tokens, each token has a type and a value. (e.g. we have a THREAD
token where the value is the thread-id string). The list of tokens is
validated, and in some cases, tokens are merged. Then the values are
extracted from the remaining token list.
Consider this breakpoint command:
(gdb) break main thread 1 if argc == 2
The condition string passed to create_breakpoint_parse_arg_string is
going to be 'thread 1 if argc == 2', which is then split into the
tokens:
{ THREAD: "1" } { CONDITION: "argc == 2" }
The thread-id (1) and the condition string 'argc == 2' are extracted
from these tokens and returns back to create_breakpoint.
Now consider this breakpoint command:
(gdb) break some_function if ( some_var == thread )
Here the user wants a breakpoint if 'some_var' is equal to the
variable 'thread'. However, when this is initially parsed we will
find these tokens:
{ CONDITION: "( some_var == " } { THREAD: ")" }
This is a consequence of how we have to try and figure out the
contents of the 'if' condition without actually parsing the
expression; parsing the expression requires that we know the location
in order to lookup the variables by name, and this can't be done for
pending breakpoints (their location isn't known yet), and one of the
points of this work is that we extract things like thread-id for
pending breakpoints.
And so, it is in this case that token merging takes place. We check
if the value of a token appearing immediately after the CONDITION
token looks valid. In this case, does ')' look like a valid
thread-id. Clearly, in this case ')' does not, and so me merge the
THREAD token into the condition token, giving:
{ CONDITION: "( some_var == thread )" }
Which is what we want.
I'm sure that we might still be able to come up with some edge cases
where the parser makes the wrong choice. I think long term the best
way to work around these would be to move the thread, inferior, task,
and -force-condition flags to be "real" command options for the break
command. I am looking into doing this, but can't guarantee if/when
that work would be completed, so this patch should be reviewed assume
that the work will never arrive (though I hope it will).
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-03-31 02:21:22 +08:00
|
|
|
/* Copyright (C) 2023 Free Software Foundation, Inc.
|
|
|
|
|
|
|
|
This file is part of GDB.
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
|
|
|
|
#include "defs.h"
|
|
|
|
#include "gdbsupport/gdb_assert.h"
|
|
|
|
#include "gdbsupport/selftest.h"
|
|
|
|
#include "test-target.h"
|
|
|
|
#include "scoped-mock-context.h"
|
|
|
|
#include "break-cond-parse.h"
|
|
|
|
#include "tid-parse.h"
|
|
|
|
#include "ada-lang.h"
|
|
|
|
#include "exceptions.h"
|
|
|
|
|
|
|
|
/* When parsing tokens from a string, which direction are we parsing?
|
|
|
|
|
|
|
|
Given the following string and pointer 'ptr':
|
|
|
|
|
|
|
|
ABC DEF GHI JKL
|
|
|
|
^
|
|
|
|
ptr
|
|
|
|
|
|
|
|
Parsing 'forward' will return the token 'GHI' and update 'ptr' to point
|
|
|
|
between GHI and JKL. Parsing 'backward' will return the token 'DEF' and
|
|
|
|
update 'ptr' to point between ABC and DEF.
|
|
|
|
*/
|
|
|
|
|
|
|
|
enum class parse_direction
|
|
|
|
{
|
|
|
|
/* Parse the next token forwards. */
|
|
|
|
forward,
|
|
|
|
|
|
|
|
/* Parse the previous token backwards. */
|
|
|
|
backward
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Find the next token in DIRECTION from *CURR. */
|
|
|
|
|
|
|
|
static std::string_view
|
|
|
|
find_next_token (const char **curr, parse_direction direction)
|
|
|
|
{
|
|
|
|
const char *tok_start, *tok_end;
|
|
|
|
|
|
|
|
gdb_assert (**curr != '\0');
|
|
|
|
|
|
|
|
if (direction == parse_direction::forward)
|
|
|
|
{
|
|
|
|
*curr = skip_spaces (*curr);
|
|
|
|
tok_start = *curr;
|
|
|
|
*curr = skip_to_space (*curr);
|
|
|
|
tok_end = *curr - 1;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
gdb_assert (direction == parse_direction::backward);
|
|
|
|
|
|
|
|
while (isspace (**curr))
|
|
|
|
--(*curr);
|
|
|
|
|
|
|
|
tok_end = *curr;
|
|
|
|
|
|
|
|
while (!isspace (**curr))
|
|
|
|
--(*curr);
|
|
|
|
|
|
|
|
tok_start = (*curr) + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return std::string_view (tok_start, tok_end - tok_start + 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* A class that represents a complete parsed token. Each token has a type
|
|
|
|
and a std::string_view into the original breakpoint condition string. */
|
|
|
|
|
|
|
|
struct token
|
|
|
|
{
|
|
|
|
/* The types a token might take. */
|
|
|
|
enum class type
|
|
|
|
{
|
|
|
|
/* These are the token types for the 'if', 'thread', 'inferior', and
|
|
|
|
'task' keywords. The m_content for these token types is the value
|
|
|
|
passed to the keyword, not the keyword itself. */
|
|
|
|
CONDITION,
|
|
|
|
THREAD,
|
|
|
|
INFERIOR,
|
|
|
|
TASK,
|
|
|
|
|
|
|
|
/* This is the token used when we find unknown content, the m_content
|
|
|
|
for this token is the rest of the input string. */
|
|
|
|
REST,
|
|
|
|
|
|
|
|
/* This is the token for the -force-condition token, the m_content for
|
|
|
|
this token contains the keyword itself. */
|
|
|
|
FORCE
|
|
|
|
};
|
|
|
|
|
|
|
|
token (enum type type, std::string_view content)
|
|
|
|
: m_type (type),
|
|
|
|
m_content (std::move (content))
|
|
|
|
{
|
|
|
|
/* Nothing. */
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return a string representing this token. Only used for debug. */
|
|
|
|
std::string to_string () const
|
|
|
|
{
|
|
|
|
switch (m_type)
|
|
|
|
{
|
|
|
|
case type::CONDITION:
|
|
|
|
return string_printf ("{ CONDITION: \"%s\" }",
|
|
|
|
std::string (m_content).c_str ());
|
|
|
|
case type::THREAD:
|
|
|
|
return string_printf ("{ THREAD: \"%s\" }",
|
|
|
|
std::string (m_content).c_str ());
|
|
|
|
case type::INFERIOR:
|
|
|
|
return string_printf ("{ INFERIOR: \"%s\" }",
|
|
|
|
std::string (m_content).c_str ());
|
|
|
|
case type::TASK:
|
|
|
|
return string_printf ("{ TASK: \"%s\" }",
|
|
|
|
std::string (m_content).c_str ());
|
|
|
|
case type::REST:
|
|
|
|
return string_printf ("{ REST: \"%s\" }",
|
|
|
|
std::string (m_content).c_str ());
|
|
|
|
case type::FORCE:
|
|
|
|
return string_printf ("{ FORCE }");
|
|
|
|
default:
|
|
|
|
return "** unknown **";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The type of this token. */
|
|
|
|
const type &get_type () const
|
|
|
|
{
|
|
|
|
return m_type;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return the value of this token. */
|
|
|
|
const std::string_view &get_value () const
|
|
|
|
{
|
|
|
|
gdb_assert (m_content.size () > 0);
|
|
|
|
return m_content;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Extend this token with the contents of OTHER. This only makes sense
|
|
|
|
if OTHER is the next token after this one in the original string,
|
|
|
|
however, enforcing that restriction is left to the caller of this
|
|
|
|
function.
|
|
|
|
|
|
|
|
When OTHER is a keyword/value token, e.g. 'thread 1', the m_content
|
|
|
|
for OTHER will only point to the '1'. However, as the m_content is a
|
|
|
|
std::string_view, then when we merge the m_content of OTHER into this
|
|
|
|
token we automatically merge in the 'thread' part too, as it
|
|
|
|
naturally sits between this token and OTHER. */
|
|
|
|
|
|
|
|
void
|
|
|
|
extend (const token &other)
|
|
|
|
{
|
|
|
|
m_content = std::string_view (this->m_content.data (),
|
|
|
|
(other.m_content.data ()
|
|
|
|
- this->m_content.data ()
|
|
|
|
+ other.m_content.size ()));
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
/* The type of this token. */
|
|
|
|
type m_type;
|
|
|
|
|
|
|
|
/* The important content part of this token. The extend member function
|
|
|
|
depends on this being a std::string_view. */
|
|
|
|
std::string_view m_content;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Split STR, a breakpoint condition string, into a vector of tokens where
|
|
|
|
each token represents a component of the condition. Tokens are first
|
|
|
|
parsed from the front of STR until we encounter an 'if' token. At this
|
|
|
|
point tokens are parsed from the end of STR until we encounter an
|
|
|
|
unknown token, which we assume is the other end of the 'if' condition.
|
|
|
|
If when scanning forward we encounter an unknown token then the
|
|
|
|
remainder of STR is placed into a 'rest' token (the rest of the
|
|
|
|
string), and no backward scan is performed. */
|
|
|
|
|
|
|
|
static std::vector<token>
|
|
|
|
parse_all_tokens (const char *str)
|
|
|
|
{
|
|
|
|
gdb_assert (str != nullptr);
|
|
|
|
|
|
|
|
std::vector<token> forward_results;
|
|
|
|
std::vector<token> backward_results;
|
|
|
|
|
|
|
|
const char *cond_start = nullptr;
|
|
|
|
const char *cond_end = nullptr;
|
|
|
|
parse_direction direction = parse_direction::forward;
|
|
|
|
std::vector<token> *curr_results = &forward_results;
|
|
|
|
while (*str != '\0')
|
|
|
|
{
|
|
|
|
/* Find the next token. If moving backward and this token starts at
|
|
|
|
the same location as the condition then we must have found the
|
|
|
|
other end of the condition string -- we're done. */
|
|
|
|
std::string_view t = find_next_token (&str, direction);
|
|
|
|
if (direction == parse_direction::backward && t.data () <= cond_start)
|
|
|
|
{
|
|
|
|
cond_end = &t.back ();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We only have a single flag option to check for. All the other
|
|
|
|
options take a value so require an additional token to be found.
|
|
|
|
Additionally, we require that this flag be at least '-f', we
|
|
|
|
don't allow it to be abbreviated to '-'. */
|
|
|
|
if (t.length () > 1 && startswith ("-force-condition", t))
|
|
|
|
{
|
|
|
|
curr_results->emplace_back (token::type::FORCE, t);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Maybe the first token was the last token in the string. If this
|
|
|
|
is the case then we definitely can't try to extract a value
|
|
|
|
token. This also means that the token T is meaningless. Reset
|
|
|
|
TOK to point at the start of the unknown content and break out of
|
|
|
|
the loop. We'll record the unknown part of the string outside of
|
|
|
|
the scanning loop (below). */
|
|
|
|
if (direction == parse_direction::forward && *str == '\0')
|
|
|
|
{
|
|
|
|
str = t.data ();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* As before, find the next token and, if we are scanning backwards,
|
|
|
|
check that we have not reached the start of the condition string. */
|
|
|
|
std::string_view v = find_next_token (&str, direction);
|
|
|
|
if (direction == parse_direction::backward && v.data () <= cond_start)
|
|
|
|
{
|
|
|
|
/* Use token T here as that must also be part of the condition
|
|
|
|
string. */
|
|
|
|
cond_end = &t.back ();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* When moving backward we will first parse the value token then the
|
|
|
|
keyword token, so swap them now. */
|
|
|
|
if (direction == parse_direction::backward)
|
|
|
|
std::swap (t, v);
|
|
|
|
|
|
|
|
/* Check for valid option in token T. If we find a valid option then
|
|
|
|
parse the value from the token V. Except for 'if', that's handled
|
|
|
|
differently.
|
|
|
|
|
|
|
|
For the 'if' token we need to capture the entire condition
|
|
|
|
string, so record the start of the condition string and then
|
|
|
|
start scanning backwards looking for the end of the condition
|
|
|
|
string.
|
|
|
|
|
|
|
|
The order of these checks is important, at least the check for
|
|
|
|
'thread' must occur before the check for 'task'. We accept
|
|
|
|
abbreviations of these token names, and 't' should resolve to
|
|
|
|
'thread', which will only happen if we check 'thread' first. */
|
|
|
|
if (direction == parse_direction::forward && startswith ("if", t))
|
|
|
|
{
|
|
|
|
cond_start = v.data ();
|
|
|
|
str = str + strlen (str);
|
|
|
|
gdb_assert (*str == '\0');
|
|
|
|
--str;
|
|
|
|
direction = parse_direction::backward;
|
|
|
|
curr_results = &backward_results;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
else if (startswith ("thread", t))
|
|
|
|
curr_results->emplace_back (token::type::THREAD, v);
|
|
|
|
else if (startswith ("inferior", t))
|
|
|
|
curr_results->emplace_back (token::type::INFERIOR, v);
|
|
|
|
else if (startswith ("task", t))
|
|
|
|
curr_results->emplace_back (token::type::TASK, v);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* An unknown token. If we are scanning forward then reset TOK
|
|
|
|
to point at the start of the unknown content, we record this
|
|
|
|
outside of the scanning loop (below).
|
|
|
|
|
|
|
|
If we are scanning backward then unknown content is assumed to
|
|
|
|
be the other end of the condition string, obviously, this is
|
|
|
|
just a heuristic, we could be looking at a mistyped command
|
|
|
|
line, but this will be spotted when the condition is
|
|
|
|
eventually evaluated.
|
|
|
|
|
|
|
|
Either way, no more scanning is required after this. */
|
|
|
|
if (direction == parse_direction::forward)
|
|
|
|
str = t.data ();
|
|
|
|
else
|
|
|
|
{
|
|
|
|
gdb_assert (direction == parse_direction::backward);
|
|
|
|
cond_end = &v.back ();
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cond_start != nullptr)
|
|
|
|
{
|
|
|
|
/* If we found the start of a condition string then we should have
|
|
|
|
switched to backward scan mode, and found the end of the condition
|
|
|
|
string. Capture the whole condition string into COND_STRING
|
|
|
|
now. */
|
|
|
|
gdb_assert (direction == parse_direction::backward);
|
|
|
|
gdb_assert (cond_end != nullptr);
|
|
|
|
|
|
|
|
std::string_view v (cond_start, cond_end - cond_start + 1);
|
|
|
|
|
|
|
|
forward_results.emplace_back (token::type::CONDITION, v);
|
|
|
|
}
|
|
|
|
else if (*str != '\0')
|
|
|
|
{
|
|
|
|
/* If we didn't have a condition start pointer then we should still
|
|
|
|
be in forward scanning mode. If we didn't reach the end of the
|
|
|
|
input string (TOK is not at the null character) then the rest of
|
|
|
|
the input string is garbage that we didn't understand.
|
|
|
|
|
|
|
|
Record the unknown content into REST. The caller of this function
|
|
|
|
will report this as an error later on. We could report the error
|
|
|
|
here, but we prefer to allow the caller to run other checks, and
|
|
|
|
prioritise other errors before reporting this problem. */
|
|
|
|
gdb_assert (direction == parse_direction::forward);
|
|
|
|
gdb_assert (cond_end == nullptr);
|
|
|
|
|
|
|
|
std::string_view v (str, strlen (str));
|
|
|
|
|
|
|
|
forward_results.emplace_back (token::type::REST, v);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If we have tokens in the BACKWARD_RESULTS vector then this means that
|
|
|
|
we found an 'if' condition (which will be the last thing in the
|
|
|
|
FORWARD_RESULTS vector), and then we started a backward scan.
|
|
|
|
|
|
|
|
The last tokens from the input string (those after the 'if' condition)
|
|
|
|
will be the first tokens added to the BACKWARD_RESULTS vector, so the
|
|
|
|
last items in the BACKWARD_RESULTS vector are those next to the 'if'
|
|
|
|
condition.
|
|
|
|
|
|
|
|
Check the tokens in the BACKWARD_RESULTS vector from back to front.
|
|
|
|
If the tokens look invalid then we assume that they are actually part
|
|
|
|
of the 'if' condition, and merge the token with the 'if' condition.
|
|
|
|
If it turns out that this was incorrect and that instead the user just
|
|
|
|
messed up entering the token value, then this will show as an error
|
|
|
|
when parsing the 'if' condition.
|
|
|
|
|
|
|
|
Doing this allows us to handle things like:
|
|
|
|
|
|
|
|
break function if ( variable == thread )
|
|
|
|
|
|
|
|
Where 'thread' is a local variable within 'function'. When parsing
|
|
|
|
this we will initially see 'thread )' as a thread token with ')' as
|
|
|
|
the value. However, the following code will spot that ')' is not a
|
|
|
|
valid thread-id, and so we merge 'thread )' into the 'if' condition
|
|
|
|
string.
|
|
|
|
|
|
|
|
This code also handles the special treatment for '-force-condition',
|
|
|
|
which exists for backwards compatibility reasons. Traditionally this
|
|
|
|
flag, if it occurred immediately after the 'if' condition, would be
|
|
|
|
treated as part of the 'if' condition. When the breakpoint condition
|
2024-11-23 19:20:34 +08:00
|
|
|
parsing code was rewritten, this behavior was retained. */
|
gdb: parse pending breakpoint thread/task immediately
The initial motivation for this commit was to allow thread or inferior
specific breakpoints to only be inserted within the appropriate
inferior's program-space. The benefit of this is that inferiors for
which the breakpoint does not apply will no longer need to stop, and
then resume, for such breakpoints. This commit does not make this
change, but is a refactor to allow this to happen in a later commit.
The problem we currently have is that when a thread-specific (or
inferior-specific) breakpoint is created, the thread (or inferior)
number is only parsed by calling find_condition_and_thread_for_sals.
This function is only called for non-pending breakpoints, and requires
that we know the locations at which the breakpoint will be placed (for
expression checking in case the breakpoint is also conditional).
A consequence of this is that by the time we figure out the breakpoint
is thread-specific we have already looked up locations in all program
spaces. This feels wasteful -- if we knew the thread-id earlier then
we could reduce the work GDB does by only looking up locations within
the program space for which the breakpoint applies.
Another consequence of how find_condition_and_thread_for_sals is
called is that pending breakpoints don't currently know they are
thread-specific, nor even that they are conditional! Additionally, by
delaying parsing the thread-id, pending breakpoints can be created for
non-existent threads, this is different to how non-pending
breakpoints are handled, so I can do this:
$ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
(gdb) break foo thread 99
Function "foo" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (foo thread 99) pending.
(gdb) r
Starting program: /tmp/gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Error in re-setting breakpoint 1: Unknown thread 99.
[Inferior 1 (process 3329749) exited normally]
(gdb)
GDB only checked the validity of 'thread 99' at the point the 'foo'
location became non-pending. In contrast, if I try this:
$ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
(gdb) break main thread 99
Unknown thread 99.
(gdb)
GDB immediately checks if 'thread 99' exists. I think inconsistencies
like this are confusing, and should be fixed if possible.
In this commit the create_breakpoint function is updated so that the
extra_string, which contains the thread, inferior, task, and/or
condition information, is parsed immediately, even for pending
breakpoints.
Obviously, the condition still can't be validated until the breakpoint
becomes non-pending, but the thread, inferior, and task information
can be pulled from the extra-string, and can be validated early on,
even for pending breakpoints. The -force-condition flag is also
parsed as part of this early parsing change.
There are a couple of benefits to doing this:
1. Printing of breakpoints is more consistent now. Consider creating
a conditional breakpoint before this commit:
(gdb) set breakpoint pending on
(gdb) break pendingfunc if (0)
Function "pendingfunc" not defined.
Breakpoint 1 (pendingfunc if (0)) pending.
(gdb) break main if (0)
Breakpoint 2 at 0x401198: file /tmp/hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> pendingfunc if (0)
2 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18
stop only if (0)
(gdb)
And after this commit:
(gdb) set breakpoint pending on
(gdb) break pendingfunc if (0)
Function "pendingfunc" not defined.
Breakpoint 1 (pendingfunc) pending.
(gdb) break main if (0)
Breakpoint 2 at 0x401198: file /home/andrew/tmp/hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> pendingfunc
stop only if (0)
2 breakpoint keep y 0x0000000000401198 in main at /home/andrew/tmp/hello.c:18
stop only if (0)
(gdb)
Notice that the display of the condition is now the same for the
pending and non-pending breakpoints.
The same is true for the thread, inferior, or task information in
thread, inferior, or task specific breakpoints; this information is
displayed on its own line rather than being part of the 'What'
field.
2. We can check that the thread exists as soon as the pending
breakpoint is created. Currently there is a weird difference
between pending and non-pending breakpoints when creating a
thread-specific breakpoint.
A pending thread-specific breakpoint only checks its thread when it
becomes non-pending, at which point the thread the breakpoint was
intended for might have exited. Here's the behaviour before this
commit:
(gdb) set breakpoint pending on
(gdb) break foo thread 2
Function "foo" not defined.
Breakpoint 2 (foo thread 2) pending.
(gdb) c
Continuing.
[Thread 0x7ffff7c56700 (LWP 2948835) exited]
Error in re-setting breakpoint 2: Unknown thread 2.
[Inferior 1 (process 2948832) exited normally]
(gdb)
Notice the 'Error in re-setting breakpoint 2: Unknown thread 2.'
line, this was triggered when GDB tried to make the breakpoint
non-pending, and GDB discovers that the thread no longer exists.
Compare that to the behaviour after this commit:
(gdb) set breakpoint pending on
(gdb) break foo thread 2
Function "foo" not defined.
Breakpoint 2 (foo) pending.
(gdb) c
Continuing.
[Thread 0x7ffff7c56700 (LWP 2949243) exited]
Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list.
[Inferior 1 (process 2949240) exited normally]
(gdb)
Now the behaviour for pending breakpoints is identical to
non-pending breakpoints, the thread specific breakpoint is removed
as soon as the thread the breakpoint is associated with exits.
There is an additional change; when the pending breakpoint is
created prior to this patch we see this line:
Breakpoint 2 (foo thread 2) pending.
While after this patch we get this line:
Breakpoint 2 (foo) pending.
Notice that 'thread 2' has disappeared. This might look like a
regression, but I don't think it is. That we said 'thread 2'
before was just a consequence of the lazy parsing of the breakpoint
specification, while with this patch GDB understands, and has
parsed away the 'thread 2' bit of the spec. If folk think the old
information was useful then this would be trivial to add back in
code_breakpoint::say_where.
As a result of this commit the breakpoints 'extra_string' field is now
only used by bp_dprintf type breakpoints to hold the printf format and
arguments. This string should always be empty for other breakpoint
types. This allows some cleanup in print_breakpoint_location.
In code_breakpoint::code_breakpoint I've changed an error case into an
assert. This is because the error is now handled earlier in
create_breakpoint. As a result we know that by this point, the
extra_string will always be nullptr for anything other than a
bp_dprintf style breakpoint.
The find_condition_and_thread_for_sals function is now no longer
needed, this was previously doing the delayed splitting of the extra
string into thread, task, and condition, but this is now all done in
create_breakpoint, so find_condition_and_thread_for_sals can be
deleted, and the code that calls this in
code_breakpoint::location_spec_to_sals can be removed. With this
update this code would only ever be reached for bp_dprintf style
breakpoints, and in these cases the extra_string should not contain
anything other than format and args.
The most interesting changes are all in create_breakpoint and in the
new file break-cond-parse.c. We have a new block of code early on in
create_breakpoint that is responsible for splitting the extra_string
into its component parts by calling create_breakpoint_parse_arg_string
a function in the new break-cond-parse.c file. This means that some
of the later code can be simplified a little.
The new break-cond-parse.c file implements the splitting up the
extra_string and finding all the parts, as well as some self-tests for
the new function.
Finally, now we know all the breakpoint details, these can be stored
within the breakpoint object if we end up creating a deferred
breakpoint. Additionally, if we are creating a deferred bp_dprintf we
can parse the extra_string to build the printf command.
The implementation here aims to maintain backwards compatibility as
much as possible, this means that:
1. We support abbreviations of 'thread', 'task', and 'inferior' in
some places on the breakpoint line. The handling of abbreviations
has (before this patch) been a little weird, so this works:
(gdb) break *main th 1
And creates a breakpoint at '*main' for thread 1 only, while this
does not work:
(gdb) break main th 1
In this case GDB will try to find the symbol 'main th 1'. This
weirdness exists before and after this patch.
2. The handling of '-force-condition' is odd, if this flag appears
immediately after a condition then it will be treated as part of the
condition, e.g.:
(gdb) break main if 0 -force-condition
No symbol "force" in current context.
But we are fine with these alternatives:
(gdb) break main if 0 thread 1 -force-condition
(gdb) break main -force-condition if 0
Again, this is just a quirk of how the breakpoint line used to be
parsed, but I've maintained this for backward compatibility. During
review it was suggested that -force-condition should become an
actual breakpoint flag (i.e. only valid after the 'break' command
but before the function name), and I don't think that would be a
terrible idea, however, that's not currently a trivial change, and I
think should be done as a separate piece of work. For now, this
patch just maintains the current behaviour.
The implementation works by first splitting the breakpoint condition
string (everything after the location specification) into a list of
tokens, each token has a type and a value. (e.g. we have a THREAD
token where the value is the thread-id string). The list of tokens is
validated, and in some cases, tokens are merged. Then the values are
extracted from the remaining token list.
Consider this breakpoint command:
(gdb) break main thread 1 if argc == 2
The condition string passed to create_breakpoint_parse_arg_string is
going to be 'thread 1 if argc == 2', which is then split into the
tokens:
{ THREAD: "1" } { CONDITION: "argc == 2" }
The thread-id (1) and the condition string 'argc == 2' are extracted
from these tokens and returns back to create_breakpoint.
Now consider this breakpoint command:
(gdb) break some_function if ( some_var == thread )
Here the user wants a breakpoint if 'some_var' is equal to the
variable 'thread'. However, when this is initially parsed we will
find these tokens:
{ CONDITION: "( some_var == " } { THREAD: ")" }
This is a consequence of how we have to try and figure out the
contents of the 'if' condition without actually parsing the
expression; parsing the expression requires that we know the location
in order to lookup the variables by name, and this can't be done for
pending breakpoints (their location isn't known yet), and one of the
points of this work is that we extract things like thread-id for
pending breakpoints.
And so, it is in this case that token merging takes place. We check
if the value of a token appearing immediately after the CONDITION
token looks valid. In this case, does ')' look like a valid
thread-id. Clearly, in this case ')' does not, and so me merge the
THREAD token into the condition token, giving:
{ CONDITION: "( some_var == thread )" }
Which is what we want.
I'm sure that we might still be able to come up with some edge cases
where the parser makes the wrong choice. I think long term the best
way to work around these would be to move the thread, inferior, task,
and -force-condition flags to be "real" command options for the break
command. I am looking into doing this, but can't guarantee if/when
that work would be completed, so this patch should be reviewed assume
that the work will never arrive (though I hope it will).
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-03-31 02:21:22 +08:00
|
|
|
gdb_assert (backward_results.empty ()
|
|
|
|
|| (forward_results.back ().get_type ()
|
|
|
|
== token::type::CONDITION));
|
|
|
|
while (!backward_results.empty ())
|
|
|
|
{
|
|
|
|
token &t = backward_results.back ();
|
|
|
|
|
|
|
|
if (t.get_type () == token::type::FORCE)
|
|
|
|
forward_results.back ().extend (std::move (t));
|
|
|
|
else if (t.get_type () == token::type::THREAD)
|
|
|
|
{
|
|
|
|
const char *end;
|
|
|
|
std::string v (t.get_value ());
|
|
|
|
if (is_thread_id (v.c_str (), &end) && *end == '\0')
|
|
|
|
break;
|
|
|
|
forward_results.back ().extend (std::move (t));
|
|
|
|
}
|
|
|
|
else if (t.get_type () == token::type::INFERIOR
|
|
|
|
|| t.get_type () == token::type::TASK)
|
|
|
|
{
|
|
|
|
/* Place the token's value into a null-terminated string, parse
|
|
|
|
the string as a number and check that the entire string was
|
|
|
|
parsed. If this is true then this looks like a valid inferior
|
|
|
|
or task number, otherwise, assume an invalid id, and merge
|
|
|
|
this token with the 'if' token. */
|
|
|
|
char *end;
|
|
|
|
std::string v (t.get_value ());
|
|
|
|
(void) strtol (v.c_str (), &end, 0);
|
|
|
|
if (end > v.c_str () && *end == '\0')
|
|
|
|
break;
|
|
|
|
forward_results.back ().extend (std::move (t));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
gdb_assert_not_reached ("unexpected token type");
|
|
|
|
|
|
|
|
/* If we found an actual valid token above then we will have broken
|
|
|
|
out of the loop. We only get here if the token was merged with
|
|
|
|
the 'if' condition, in which case we can discard the last token
|
|
|
|
and then check the token before that. */
|
|
|
|
backward_results.pop_back ();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If after the above checks we still have some tokens in the
|
|
|
|
BACKWARD_RESULTS vector, then these need to be appended to the
|
|
|
|
FORWARD_RESULTS vector. However, we first reverse the order so that
|
|
|
|
FORWARD_RESULTS retains the tokens in the order they appeared in the
|
|
|
|
input string. */
|
|
|
|
if (!backward_results.empty ())
|
|
|
|
forward_results.insert (forward_results.end (),
|
|
|
|
backward_results.rbegin (),
|
|
|
|
backward_results.rend ());
|
|
|
|
|
|
|
|
return forward_results;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Called when the global debug_breakpoint is true. Prints VEC to the
|
|
|
|
debug output stream. */
|
|
|
|
|
|
|
|
static void
|
|
|
|
dump_condition_tokens (const std::vector<token> &vec)
|
|
|
|
{
|
|
|
|
gdb_assert (debug_breakpoint);
|
|
|
|
|
|
|
|
bool first = true;
|
|
|
|
std::string str = "Tokens: ";
|
|
|
|
for (const token &t : vec)
|
|
|
|
{
|
|
|
|
if (!first)
|
|
|
|
str += " ";
|
|
|
|
first = false;
|
|
|
|
str += t.to_string ();
|
|
|
|
}
|
|
|
|
breakpoint_debug_printf ("%s", str.c_str ());
|
|
|
|
}
|
|
|
|
|
|
|
|
/* See break-cond-parse.h. */
|
|
|
|
|
|
|
|
void
|
|
|
|
create_breakpoint_parse_arg_string
|
|
|
|
(const char *str, gdb::unique_xmalloc_ptr<char> *cond_string_ptr,
|
|
|
|
int *thread_ptr, int *inferior_ptr, int *task_ptr,
|
|
|
|
gdb::unique_xmalloc_ptr<char> *rest_ptr, bool *force_ptr)
|
|
|
|
{
|
|
|
|
/* Set up the defaults. */
|
|
|
|
cond_string_ptr->reset ();
|
|
|
|
rest_ptr->reset ();
|
|
|
|
*thread_ptr = -1;
|
|
|
|
*inferior_ptr = -1;
|
|
|
|
*task_ptr = -1;
|
|
|
|
*force_ptr = false;
|
|
|
|
|
|
|
|
if (str == nullptr)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Split STR into a series of tokens. */
|
|
|
|
std::vector<token> tokens = parse_all_tokens (str);
|
|
|
|
if (debug_breakpoint)
|
|
|
|
dump_condition_tokens (tokens);
|
|
|
|
|
|
|
|
/* Temporary variables. Initialised to the default state, then updated
|
|
|
|
as we parse TOKENS. If all of TOKENS is parsed successfully then the
|
|
|
|
state from these variables is copied into the output arguments before
|
|
|
|
the function returns. */
|
|
|
|
int thread = -1, inferior = -1, task = -1;
|
|
|
|
bool force = false;
|
|
|
|
gdb::unique_xmalloc_ptr<char> cond_string, rest;
|
|
|
|
|
|
|
|
for (const token &t : tokens)
|
|
|
|
{
|
gdb: fix use of out of scope temporary variable in break-cond-parse.c
The commit:
commit c6b486755e020095710c7494d029577ca967a13a
Date: Thu Mar 30 19:21:22 2023 +0100
gdb: parse pending breakpoint thread/task immediately
Introduce a use bug where the value of a temporary variable was being
used after it had gone out of scope. This was picked up by the
address sanitizer and would result in this error:
(gdb) maintenance selftest create_breakpoint_parse_arg_string
Running selftest create_breakpoint_parse_arg_string.
=================================================================
==2265825==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fbb08046511 at pc 0x000001632230 bp 0x7fff7c2fb770 sp 0x7fff7c2fb768
READ of size 1 at 0x7fbb08046511 thread T0
#0 0x163222f in create_breakpoint_parse_arg_string(char const*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*, int*, int*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, bool*) ../../src/gdb/break-cond-parse.c:496
#1 0x1633026 in test ../../src/gdb/break-cond-parse.c:582
#2 0x163391b in create_breakpoint_parse_arg_string_tests ../../src/gdb/break-cond-parse.c:649
#3 0x12cfebc in void std::__invoke_impl<void, void (*&)()>(std::__invoke_other, void (*&)()) /usr/include/c++/13/bits/invoke.h:61
#4 0x12cc8ee in std::enable_if<is_invocable_r_v<void, void (*&)()>, void>::type std::__invoke_r<void, void (*&)()>(void (*&)()) /usr/include/c++/13/bits/invoke.h:111
#5 0x12c81e5 in std::_Function_handler<void (), void (*)()>::_M_invoke(std::_Any_data const&) /usr/include/c++/13/bits/std_function.h:290
#6 0x18bb51d in std::function<void ()>::operator()() const /usr/include/c++/13/bits/std_function.h:591
#7 0x4193ef9 in selftests::run_tests(gdb::array_view<char const* const>, bool) ../../src/gdbsupport/selftest.cc:100
#8 0x21c2206 in maintenance_selftest ../../src/gdb/maint.c:1172
... etc ...
The problem was caused by three lines like this one:
thread_info *thr
= parse_thread_id (std::string (t.get_value ()).c_str (), &tmptok);
After parsing the thread-id TMPTOK would be left pointing into the
temporary string which had been created on this line. When on the
next line we did this:
gdb_assert (*tmptok == '\0');
The value of *TMPTOK is undefined.
Fix this by creating the std::string earlier in the scope. Now the
contents of the string will remain valid when we check *TMPTOK. The
address sanitizer issue is now resolved.
2024-09-09 04:17:55 +08:00
|
|
|
std::string tok_value (t.get_value ());
|
gdb: parse pending breakpoint thread/task immediately
The initial motivation for this commit was to allow thread or inferior
specific breakpoints to only be inserted within the appropriate
inferior's program-space. The benefit of this is that inferiors for
which the breakpoint does not apply will no longer need to stop, and
then resume, for such breakpoints. This commit does not make this
change, but is a refactor to allow this to happen in a later commit.
The problem we currently have is that when a thread-specific (or
inferior-specific) breakpoint is created, the thread (or inferior)
number is only parsed by calling find_condition_and_thread_for_sals.
This function is only called for non-pending breakpoints, and requires
that we know the locations at which the breakpoint will be placed (for
expression checking in case the breakpoint is also conditional).
A consequence of this is that by the time we figure out the breakpoint
is thread-specific we have already looked up locations in all program
spaces. This feels wasteful -- if we knew the thread-id earlier then
we could reduce the work GDB does by only looking up locations within
the program space for which the breakpoint applies.
Another consequence of how find_condition_and_thread_for_sals is
called is that pending breakpoints don't currently know they are
thread-specific, nor even that they are conditional! Additionally, by
delaying parsing the thread-id, pending breakpoints can be created for
non-existent threads, this is different to how non-pending
breakpoints are handled, so I can do this:
$ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
(gdb) break foo thread 99
Function "foo" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (foo thread 99) pending.
(gdb) r
Starting program: /tmp/gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Error in re-setting breakpoint 1: Unknown thread 99.
[Inferior 1 (process 3329749) exited normally]
(gdb)
GDB only checked the validity of 'thread 99' at the point the 'foo'
location became non-pending. In contrast, if I try this:
$ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
(gdb) break main thread 99
Unknown thread 99.
(gdb)
GDB immediately checks if 'thread 99' exists. I think inconsistencies
like this are confusing, and should be fixed if possible.
In this commit the create_breakpoint function is updated so that the
extra_string, which contains the thread, inferior, task, and/or
condition information, is parsed immediately, even for pending
breakpoints.
Obviously, the condition still can't be validated until the breakpoint
becomes non-pending, but the thread, inferior, and task information
can be pulled from the extra-string, and can be validated early on,
even for pending breakpoints. The -force-condition flag is also
parsed as part of this early parsing change.
There are a couple of benefits to doing this:
1. Printing of breakpoints is more consistent now. Consider creating
a conditional breakpoint before this commit:
(gdb) set breakpoint pending on
(gdb) break pendingfunc if (0)
Function "pendingfunc" not defined.
Breakpoint 1 (pendingfunc if (0)) pending.
(gdb) break main if (0)
Breakpoint 2 at 0x401198: file /tmp/hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> pendingfunc if (0)
2 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18
stop only if (0)
(gdb)
And after this commit:
(gdb) set breakpoint pending on
(gdb) break pendingfunc if (0)
Function "pendingfunc" not defined.
Breakpoint 1 (pendingfunc) pending.
(gdb) break main if (0)
Breakpoint 2 at 0x401198: file /home/andrew/tmp/hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> pendingfunc
stop only if (0)
2 breakpoint keep y 0x0000000000401198 in main at /home/andrew/tmp/hello.c:18
stop only if (0)
(gdb)
Notice that the display of the condition is now the same for the
pending and non-pending breakpoints.
The same is true for the thread, inferior, or task information in
thread, inferior, or task specific breakpoints; this information is
displayed on its own line rather than being part of the 'What'
field.
2. We can check that the thread exists as soon as the pending
breakpoint is created. Currently there is a weird difference
between pending and non-pending breakpoints when creating a
thread-specific breakpoint.
A pending thread-specific breakpoint only checks its thread when it
becomes non-pending, at which point the thread the breakpoint was
intended for might have exited. Here's the behaviour before this
commit:
(gdb) set breakpoint pending on
(gdb) break foo thread 2
Function "foo" not defined.
Breakpoint 2 (foo thread 2) pending.
(gdb) c
Continuing.
[Thread 0x7ffff7c56700 (LWP 2948835) exited]
Error in re-setting breakpoint 2: Unknown thread 2.
[Inferior 1 (process 2948832) exited normally]
(gdb)
Notice the 'Error in re-setting breakpoint 2: Unknown thread 2.'
line, this was triggered when GDB tried to make the breakpoint
non-pending, and GDB discovers that the thread no longer exists.
Compare that to the behaviour after this commit:
(gdb) set breakpoint pending on
(gdb) break foo thread 2
Function "foo" not defined.
Breakpoint 2 (foo) pending.
(gdb) c
Continuing.
[Thread 0x7ffff7c56700 (LWP 2949243) exited]
Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list.
[Inferior 1 (process 2949240) exited normally]
(gdb)
Now the behaviour for pending breakpoints is identical to
non-pending breakpoints, the thread specific breakpoint is removed
as soon as the thread the breakpoint is associated with exits.
There is an additional change; when the pending breakpoint is
created prior to this patch we see this line:
Breakpoint 2 (foo thread 2) pending.
While after this patch we get this line:
Breakpoint 2 (foo) pending.
Notice that 'thread 2' has disappeared. This might look like a
regression, but I don't think it is. That we said 'thread 2'
before was just a consequence of the lazy parsing of the breakpoint
specification, while with this patch GDB understands, and has
parsed away the 'thread 2' bit of the spec. If folk think the old
information was useful then this would be trivial to add back in
code_breakpoint::say_where.
As a result of this commit the breakpoints 'extra_string' field is now
only used by bp_dprintf type breakpoints to hold the printf format and
arguments. This string should always be empty for other breakpoint
types. This allows some cleanup in print_breakpoint_location.
In code_breakpoint::code_breakpoint I've changed an error case into an
assert. This is because the error is now handled earlier in
create_breakpoint. As a result we know that by this point, the
extra_string will always be nullptr for anything other than a
bp_dprintf style breakpoint.
The find_condition_and_thread_for_sals function is now no longer
needed, this was previously doing the delayed splitting of the extra
string into thread, task, and condition, but this is now all done in
create_breakpoint, so find_condition_and_thread_for_sals can be
deleted, and the code that calls this in
code_breakpoint::location_spec_to_sals can be removed. With this
update this code would only ever be reached for bp_dprintf style
breakpoints, and in these cases the extra_string should not contain
anything other than format and args.
The most interesting changes are all in create_breakpoint and in the
new file break-cond-parse.c. We have a new block of code early on in
create_breakpoint that is responsible for splitting the extra_string
into its component parts by calling create_breakpoint_parse_arg_string
a function in the new break-cond-parse.c file. This means that some
of the later code can be simplified a little.
The new break-cond-parse.c file implements the splitting up the
extra_string and finding all the parts, as well as some self-tests for
the new function.
Finally, now we know all the breakpoint details, these can be stored
within the breakpoint object if we end up creating a deferred
breakpoint. Additionally, if we are creating a deferred bp_dprintf we
can parse the extra_string to build the printf command.
The implementation here aims to maintain backwards compatibility as
much as possible, this means that:
1. We support abbreviations of 'thread', 'task', and 'inferior' in
some places on the breakpoint line. The handling of abbreviations
has (before this patch) been a little weird, so this works:
(gdb) break *main th 1
And creates a breakpoint at '*main' for thread 1 only, while this
does not work:
(gdb) break main th 1
In this case GDB will try to find the symbol 'main th 1'. This
weirdness exists before and after this patch.
2. The handling of '-force-condition' is odd, if this flag appears
immediately after a condition then it will be treated as part of the
condition, e.g.:
(gdb) break main if 0 -force-condition
No symbol "force" in current context.
But we are fine with these alternatives:
(gdb) break main if 0 thread 1 -force-condition
(gdb) break main -force-condition if 0
Again, this is just a quirk of how the breakpoint line used to be
parsed, but I've maintained this for backward compatibility. During
review it was suggested that -force-condition should become an
actual breakpoint flag (i.e. only valid after the 'break' command
but before the function name), and I don't think that would be a
terrible idea, however, that's not currently a trivial change, and I
think should be done as a separate piece of work. For now, this
patch just maintains the current behaviour.
The implementation works by first splitting the breakpoint condition
string (everything after the location specification) into a list of
tokens, each token has a type and a value. (e.g. we have a THREAD
token where the value is the thread-id string). The list of tokens is
validated, and in some cases, tokens are merged. Then the values are
extracted from the remaining token list.
Consider this breakpoint command:
(gdb) break main thread 1 if argc == 2
The condition string passed to create_breakpoint_parse_arg_string is
going to be 'thread 1 if argc == 2', which is then split into the
tokens:
{ THREAD: "1" } { CONDITION: "argc == 2" }
The thread-id (1) and the condition string 'argc == 2' are extracted
from these tokens and returns back to create_breakpoint.
Now consider this breakpoint command:
(gdb) break some_function if ( some_var == thread )
Here the user wants a breakpoint if 'some_var' is equal to the
variable 'thread'. However, when this is initially parsed we will
find these tokens:
{ CONDITION: "( some_var == " } { THREAD: ")" }
This is a consequence of how we have to try and figure out the
contents of the 'if' condition without actually parsing the
expression; parsing the expression requires that we know the location
in order to lookup the variables by name, and this can't be done for
pending breakpoints (their location isn't known yet), and one of the
points of this work is that we extract things like thread-id for
pending breakpoints.
And so, it is in this case that token merging takes place. We check
if the value of a token appearing immediately after the CONDITION
token looks valid. In this case, does ')' look like a valid
thread-id. Clearly, in this case ')' does not, and so me merge the
THREAD token into the condition token, giving:
{ CONDITION: "( some_var == thread )" }
Which is what we want.
I'm sure that we might still be able to come up with some edge cases
where the parser makes the wrong choice. I think long term the best
way to work around these would be to move the thread, inferior, task,
and -force-condition flags to be "real" command options for the break
command. I am looking into doing this, but can't guarantee if/when
that work would be completed, so this patch should be reviewed assume
that the work will never arrive (though I hope it will).
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-03-31 02:21:22 +08:00
|
|
|
switch (t.get_type ())
|
|
|
|
{
|
|
|
|
case token::type::FORCE:
|
|
|
|
force = true;
|
|
|
|
break;
|
|
|
|
case token::type::THREAD:
|
|
|
|
{
|
|
|
|
if (thread != -1)
|
|
|
|
error ("You can specify only one thread.");
|
|
|
|
if (task != -1 || inferior != -1)
|
|
|
|
error ("You can specify only one of thread, inferior, or task.");
|
|
|
|
const char *tmptok;
|
gdb: fix use of out of scope temporary variable in break-cond-parse.c
The commit:
commit c6b486755e020095710c7494d029577ca967a13a
Date: Thu Mar 30 19:21:22 2023 +0100
gdb: parse pending breakpoint thread/task immediately
Introduce a use bug where the value of a temporary variable was being
used after it had gone out of scope. This was picked up by the
address sanitizer and would result in this error:
(gdb) maintenance selftest create_breakpoint_parse_arg_string
Running selftest create_breakpoint_parse_arg_string.
=================================================================
==2265825==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fbb08046511 at pc 0x000001632230 bp 0x7fff7c2fb770 sp 0x7fff7c2fb768
READ of size 1 at 0x7fbb08046511 thread T0
#0 0x163222f in create_breakpoint_parse_arg_string(char const*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*, int*, int*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, bool*) ../../src/gdb/break-cond-parse.c:496
#1 0x1633026 in test ../../src/gdb/break-cond-parse.c:582
#2 0x163391b in create_breakpoint_parse_arg_string_tests ../../src/gdb/break-cond-parse.c:649
#3 0x12cfebc in void std::__invoke_impl<void, void (*&)()>(std::__invoke_other, void (*&)()) /usr/include/c++/13/bits/invoke.h:61
#4 0x12cc8ee in std::enable_if<is_invocable_r_v<void, void (*&)()>, void>::type std::__invoke_r<void, void (*&)()>(void (*&)()) /usr/include/c++/13/bits/invoke.h:111
#5 0x12c81e5 in std::_Function_handler<void (), void (*)()>::_M_invoke(std::_Any_data const&) /usr/include/c++/13/bits/std_function.h:290
#6 0x18bb51d in std::function<void ()>::operator()() const /usr/include/c++/13/bits/std_function.h:591
#7 0x4193ef9 in selftests::run_tests(gdb::array_view<char const* const>, bool) ../../src/gdbsupport/selftest.cc:100
#8 0x21c2206 in maintenance_selftest ../../src/gdb/maint.c:1172
... etc ...
The problem was caused by three lines like this one:
thread_info *thr
= parse_thread_id (std::string (t.get_value ()).c_str (), &tmptok);
After parsing the thread-id TMPTOK would be left pointing into the
temporary string which had been created on this line. When on the
next line we did this:
gdb_assert (*tmptok == '\0');
The value of *TMPTOK is undefined.
Fix this by creating the std::string earlier in the scope. Now the
contents of the string will remain valid when we check *TMPTOK. The
address sanitizer issue is now resolved.
2024-09-09 04:17:55 +08:00
|
|
|
thread_info *thr = parse_thread_id (tok_value.c_str (), &tmptok);
|
gdb: parse pending breakpoint thread/task immediately
The initial motivation for this commit was to allow thread or inferior
specific breakpoints to only be inserted within the appropriate
inferior's program-space. The benefit of this is that inferiors for
which the breakpoint does not apply will no longer need to stop, and
then resume, for such breakpoints. This commit does not make this
change, but is a refactor to allow this to happen in a later commit.
The problem we currently have is that when a thread-specific (or
inferior-specific) breakpoint is created, the thread (or inferior)
number is only parsed by calling find_condition_and_thread_for_sals.
This function is only called for non-pending breakpoints, and requires
that we know the locations at which the breakpoint will be placed (for
expression checking in case the breakpoint is also conditional).
A consequence of this is that by the time we figure out the breakpoint
is thread-specific we have already looked up locations in all program
spaces. This feels wasteful -- if we knew the thread-id earlier then
we could reduce the work GDB does by only looking up locations within
the program space for which the breakpoint applies.
Another consequence of how find_condition_and_thread_for_sals is
called is that pending breakpoints don't currently know they are
thread-specific, nor even that they are conditional! Additionally, by
delaying parsing the thread-id, pending breakpoints can be created for
non-existent threads, this is different to how non-pending
breakpoints are handled, so I can do this:
$ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
(gdb) break foo thread 99
Function "foo" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (foo thread 99) pending.
(gdb) r
Starting program: /tmp/gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Error in re-setting breakpoint 1: Unknown thread 99.
[Inferior 1 (process 3329749) exited normally]
(gdb)
GDB only checked the validity of 'thread 99' at the point the 'foo'
location became non-pending. In contrast, if I try this:
$ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
(gdb) break main thread 99
Unknown thread 99.
(gdb)
GDB immediately checks if 'thread 99' exists. I think inconsistencies
like this are confusing, and should be fixed if possible.
In this commit the create_breakpoint function is updated so that the
extra_string, which contains the thread, inferior, task, and/or
condition information, is parsed immediately, even for pending
breakpoints.
Obviously, the condition still can't be validated until the breakpoint
becomes non-pending, but the thread, inferior, and task information
can be pulled from the extra-string, and can be validated early on,
even for pending breakpoints. The -force-condition flag is also
parsed as part of this early parsing change.
There are a couple of benefits to doing this:
1. Printing of breakpoints is more consistent now. Consider creating
a conditional breakpoint before this commit:
(gdb) set breakpoint pending on
(gdb) break pendingfunc if (0)
Function "pendingfunc" not defined.
Breakpoint 1 (pendingfunc if (0)) pending.
(gdb) break main if (0)
Breakpoint 2 at 0x401198: file /tmp/hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> pendingfunc if (0)
2 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18
stop only if (0)
(gdb)
And after this commit:
(gdb) set breakpoint pending on
(gdb) break pendingfunc if (0)
Function "pendingfunc" not defined.
Breakpoint 1 (pendingfunc) pending.
(gdb) break main if (0)
Breakpoint 2 at 0x401198: file /home/andrew/tmp/hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> pendingfunc
stop only if (0)
2 breakpoint keep y 0x0000000000401198 in main at /home/andrew/tmp/hello.c:18
stop only if (0)
(gdb)
Notice that the display of the condition is now the same for the
pending and non-pending breakpoints.
The same is true for the thread, inferior, or task information in
thread, inferior, or task specific breakpoints; this information is
displayed on its own line rather than being part of the 'What'
field.
2. We can check that the thread exists as soon as the pending
breakpoint is created. Currently there is a weird difference
between pending and non-pending breakpoints when creating a
thread-specific breakpoint.
A pending thread-specific breakpoint only checks its thread when it
becomes non-pending, at which point the thread the breakpoint was
intended for might have exited. Here's the behaviour before this
commit:
(gdb) set breakpoint pending on
(gdb) break foo thread 2
Function "foo" not defined.
Breakpoint 2 (foo thread 2) pending.
(gdb) c
Continuing.
[Thread 0x7ffff7c56700 (LWP 2948835) exited]
Error in re-setting breakpoint 2: Unknown thread 2.
[Inferior 1 (process 2948832) exited normally]
(gdb)
Notice the 'Error in re-setting breakpoint 2: Unknown thread 2.'
line, this was triggered when GDB tried to make the breakpoint
non-pending, and GDB discovers that the thread no longer exists.
Compare that to the behaviour after this commit:
(gdb) set breakpoint pending on
(gdb) break foo thread 2
Function "foo" not defined.
Breakpoint 2 (foo) pending.
(gdb) c
Continuing.
[Thread 0x7ffff7c56700 (LWP 2949243) exited]
Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list.
[Inferior 1 (process 2949240) exited normally]
(gdb)
Now the behaviour for pending breakpoints is identical to
non-pending breakpoints, the thread specific breakpoint is removed
as soon as the thread the breakpoint is associated with exits.
There is an additional change; when the pending breakpoint is
created prior to this patch we see this line:
Breakpoint 2 (foo thread 2) pending.
While after this patch we get this line:
Breakpoint 2 (foo) pending.
Notice that 'thread 2' has disappeared. This might look like a
regression, but I don't think it is. That we said 'thread 2'
before was just a consequence of the lazy parsing of the breakpoint
specification, while with this patch GDB understands, and has
parsed away the 'thread 2' bit of the spec. If folk think the old
information was useful then this would be trivial to add back in
code_breakpoint::say_where.
As a result of this commit the breakpoints 'extra_string' field is now
only used by bp_dprintf type breakpoints to hold the printf format and
arguments. This string should always be empty for other breakpoint
types. This allows some cleanup in print_breakpoint_location.
In code_breakpoint::code_breakpoint I've changed an error case into an
assert. This is because the error is now handled earlier in
create_breakpoint. As a result we know that by this point, the
extra_string will always be nullptr for anything other than a
bp_dprintf style breakpoint.
The find_condition_and_thread_for_sals function is now no longer
needed, this was previously doing the delayed splitting of the extra
string into thread, task, and condition, but this is now all done in
create_breakpoint, so find_condition_and_thread_for_sals can be
deleted, and the code that calls this in
code_breakpoint::location_spec_to_sals can be removed. With this
update this code would only ever be reached for bp_dprintf style
breakpoints, and in these cases the extra_string should not contain
anything other than format and args.
The most interesting changes are all in create_breakpoint and in the
new file break-cond-parse.c. We have a new block of code early on in
create_breakpoint that is responsible for splitting the extra_string
into its component parts by calling create_breakpoint_parse_arg_string
a function in the new break-cond-parse.c file. This means that some
of the later code can be simplified a little.
The new break-cond-parse.c file implements the splitting up the
extra_string and finding all the parts, as well as some self-tests for
the new function.
Finally, now we know all the breakpoint details, these can be stored
within the breakpoint object if we end up creating a deferred
breakpoint. Additionally, if we are creating a deferred bp_dprintf we
can parse the extra_string to build the printf command.
The implementation here aims to maintain backwards compatibility as
much as possible, this means that:
1. We support abbreviations of 'thread', 'task', and 'inferior' in
some places on the breakpoint line. The handling of abbreviations
has (before this patch) been a little weird, so this works:
(gdb) break *main th 1
And creates a breakpoint at '*main' for thread 1 only, while this
does not work:
(gdb) break main th 1
In this case GDB will try to find the symbol 'main th 1'. This
weirdness exists before and after this patch.
2. The handling of '-force-condition' is odd, if this flag appears
immediately after a condition then it will be treated as part of the
condition, e.g.:
(gdb) break main if 0 -force-condition
No symbol "force" in current context.
But we are fine with these alternatives:
(gdb) break main if 0 thread 1 -force-condition
(gdb) break main -force-condition if 0
Again, this is just a quirk of how the breakpoint line used to be
parsed, but I've maintained this for backward compatibility. During
review it was suggested that -force-condition should become an
actual breakpoint flag (i.e. only valid after the 'break' command
but before the function name), and I don't think that would be a
terrible idea, however, that's not currently a trivial change, and I
think should be done as a separate piece of work. For now, this
patch just maintains the current behaviour.
The implementation works by first splitting the breakpoint condition
string (everything after the location specification) into a list of
tokens, each token has a type and a value. (e.g. we have a THREAD
token where the value is the thread-id string). The list of tokens is
validated, and in some cases, tokens are merged. Then the values are
extracted from the remaining token list.
Consider this breakpoint command:
(gdb) break main thread 1 if argc == 2
The condition string passed to create_breakpoint_parse_arg_string is
going to be 'thread 1 if argc == 2', which is then split into the
tokens:
{ THREAD: "1" } { CONDITION: "argc == 2" }
The thread-id (1) and the condition string 'argc == 2' are extracted
from these tokens and returns back to create_breakpoint.
Now consider this breakpoint command:
(gdb) break some_function if ( some_var == thread )
Here the user wants a breakpoint if 'some_var' is equal to the
variable 'thread'. However, when this is initially parsed we will
find these tokens:
{ CONDITION: "( some_var == " } { THREAD: ")" }
This is a consequence of how we have to try and figure out the
contents of the 'if' condition without actually parsing the
expression; parsing the expression requires that we know the location
in order to lookup the variables by name, and this can't be done for
pending breakpoints (their location isn't known yet), and one of the
points of this work is that we extract things like thread-id for
pending breakpoints.
And so, it is in this case that token merging takes place. We check
if the value of a token appearing immediately after the CONDITION
token looks valid. In this case, does ')' look like a valid
thread-id. Clearly, in this case ')' does not, and so me merge the
THREAD token into the condition token, giving:
{ CONDITION: "( some_var == thread )" }
Which is what we want.
I'm sure that we might still be able to come up with some edge cases
where the parser makes the wrong choice. I think long term the best
way to work around these would be to move the thread, inferior, task,
and -force-condition flags to be "real" command options for the break
command. I am looking into doing this, but can't guarantee if/when
that work would be completed, so this patch should be reviewed assume
that the work will never arrive (though I hope it will).
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-03-31 02:21:22 +08:00
|
|
|
gdb_assert (*tmptok == '\0');
|
|
|
|
thread = thr->global_num;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case token::type::INFERIOR:
|
|
|
|
{
|
|
|
|
if (inferior != -1)
|
|
|
|
error ("You can specify only one inferior.");
|
|
|
|
if (task != -1 || thread != -1)
|
|
|
|
error ("You can specify only one of thread, inferior, or task.");
|
|
|
|
char *tmptok;
|
gdb: fix use of out of scope temporary variable in break-cond-parse.c
The commit:
commit c6b486755e020095710c7494d029577ca967a13a
Date: Thu Mar 30 19:21:22 2023 +0100
gdb: parse pending breakpoint thread/task immediately
Introduce a use bug where the value of a temporary variable was being
used after it had gone out of scope. This was picked up by the
address sanitizer and would result in this error:
(gdb) maintenance selftest create_breakpoint_parse_arg_string
Running selftest create_breakpoint_parse_arg_string.
=================================================================
==2265825==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fbb08046511 at pc 0x000001632230 bp 0x7fff7c2fb770 sp 0x7fff7c2fb768
READ of size 1 at 0x7fbb08046511 thread T0
#0 0x163222f in create_breakpoint_parse_arg_string(char const*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*, int*, int*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, bool*) ../../src/gdb/break-cond-parse.c:496
#1 0x1633026 in test ../../src/gdb/break-cond-parse.c:582
#2 0x163391b in create_breakpoint_parse_arg_string_tests ../../src/gdb/break-cond-parse.c:649
#3 0x12cfebc in void std::__invoke_impl<void, void (*&)()>(std::__invoke_other, void (*&)()) /usr/include/c++/13/bits/invoke.h:61
#4 0x12cc8ee in std::enable_if<is_invocable_r_v<void, void (*&)()>, void>::type std::__invoke_r<void, void (*&)()>(void (*&)()) /usr/include/c++/13/bits/invoke.h:111
#5 0x12c81e5 in std::_Function_handler<void (), void (*)()>::_M_invoke(std::_Any_data const&) /usr/include/c++/13/bits/std_function.h:290
#6 0x18bb51d in std::function<void ()>::operator()() const /usr/include/c++/13/bits/std_function.h:591
#7 0x4193ef9 in selftests::run_tests(gdb::array_view<char const* const>, bool) ../../src/gdbsupport/selftest.cc:100
#8 0x21c2206 in maintenance_selftest ../../src/gdb/maint.c:1172
... etc ...
The problem was caused by three lines like this one:
thread_info *thr
= parse_thread_id (std::string (t.get_value ()).c_str (), &tmptok);
After parsing the thread-id TMPTOK would be left pointing into the
temporary string which had been created on this line. When on the
next line we did this:
gdb_assert (*tmptok == '\0');
The value of *TMPTOK is undefined.
Fix this by creating the std::string earlier in the scope. Now the
contents of the string will remain valid when we check *TMPTOK. The
address sanitizer issue is now resolved.
2024-09-09 04:17:55 +08:00
|
|
|
long inferior_id = strtol (tok_value.c_str (), &tmptok, 0);
|
gdb: parse pending breakpoint thread/task immediately
The initial motivation for this commit was to allow thread or inferior
specific breakpoints to only be inserted within the appropriate
inferior's program-space. The benefit of this is that inferiors for
which the breakpoint does not apply will no longer need to stop, and
then resume, for such breakpoints. This commit does not make this
change, but is a refactor to allow this to happen in a later commit.
The problem we currently have is that when a thread-specific (or
inferior-specific) breakpoint is created, the thread (or inferior)
number is only parsed by calling find_condition_and_thread_for_sals.
This function is only called for non-pending breakpoints, and requires
that we know the locations at which the breakpoint will be placed (for
expression checking in case the breakpoint is also conditional).
A consequence of this is that by the time we figure out the breakpoint
is thread-specific we have already looked up locations in all program
spaces. This feels wasteful -- if we knew the thread-id earlier then
we could reduce the work GDB does by only looking up locations within
the program space for which the breakpoint applies.
Another consequence of how find_condition_and_thread_for_sals is
called is that pending breakpoints don't currently know they are
thread-specific, nor even that they are conditional! Additionally, by
delaying parsing the thread-id, pending breakpoints can be created for
non-existent threads, this is different to how non-pending
breakpoints are handled, so I can do this:
$ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
(gdb) break foo thread 99
Function "foo" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (foo thread 99) pending.
(gdb) r
Starting program: /tmp/gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Error in re-setting breakpoint 1: Unknown thread 99.
[Inferior 1 (process 3329749) exited normally]
(gdb)
GDB only checked the validity of 'thread 99' at the point the 'foo'
location became non-pending. In contrast, if I try this:
$ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
(gdb) break main thread 99
Unknown thread 99.
(gdb)
GDB immediately checks if 'thread 99' exists. I think inconsistencies
like this are confusing, and should be fixed if possible.
In this commit the create_breakpoint function is updated so that the
extra_string, which contains the thread, inferior, task, and/or
condition information, is parsed immediately, even for pending
breakpoints.
Obviously, the condition still can't be validated until the breakpoint
becomes non-pending, but the thread, inferior, and task information
can be pulled from the extra-string, and can be validated early on,
even for pending breakpoints. The -force-condition flag is also
parsed as part of this early parsing change.
There are a couple of benefits to doing this:
1. Printing of breakpoints is more consistent now. Consider creating
a conditional breakpoint before this commit:
(gdb) set breakpoint pending on
(gdb) break pendingfunc if (0)
Function "pendingfunc" not defined.
Breakpoint 1 (pendingfunc if (0)) pending.
(gdb) break main if (0)
Breakpoint 2 at 0x401198: file /tmp/hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> pendingfunc if (0)
2 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18
stop only if (0)
(gdb)
And after this commit:
(gdb) set breakpoint pending on
(gdb) break pendingfunc if (0)
Function "pendingfunc" not defined.
Breakpoint 1 (pendingfunc) pending.
(gdb) break main if (0)
Breakpoint 2 at 0x401198: file /home/andrew/tmp/hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> pendingfunc
stop only if (0)
2 breakpoint keep y 0x0000000000401198 in main at /home/andrew/tmp/hello.c:18
stop only if (0)
(gdb)
Notice that the display of the condition is now the same for the
pending and non-pending breakpoints.
The same is true for the thread, inferior, or task information in
thread, inferior, or task specific breakpoints; this information is
displayed on its own line rather than being part of the 'What'
field.
2. We can check that the thread exists as soon as the pending
breakpoint is created. Currently there is a weird difference
between pending and non-pending breakpoints when creating a
thread-specific breakpoint.
A pending thread-specific breakpoint only checks its thread when it
becomes non-pending, at which point the thread the breakpoint was
intended for might have exited. Here's the behaviour before this
commit:
(gdb) set breakpoint pending on
(gdb) break foo thread 2
Function "foo" not defined.
Breakpoint 2 (foo thread 2) pending.
(gdb) c
Continuing.
[Thread 0x7ffff7c56700 (LWP 2948835) exited]
Error in re-setting breakpoint 2: Unknown thread 2.
[Inferior 1 (process 2948832) exited normally]
(gdb)
Notice the 'Error in re-setting breakpoint 2: Unknown thread 2.'
line, this was triggered when GDB tried to make the breakpoint
non-pending, and GDB discovers that the thread no longer exists.
Compare that to the behaviour after this commit:
(gdb) set breakpoint pending on
(gdb) break foo thread 2
Function "foo" not defined.
Breakpoint 2 (foo) pending.
(gdb) c
Continuing.
[Thread 0x7ffff7c56700 (LWP 2949243) exited]
Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list.
[Inferior 1 (process 2949240) exited normally]
(gdb)
Now the behaviour for pending breakpoints is identical to
non-pending breakpoints, the thread specific breakpoint is removed
as soon as the thread the breakpoint is associated with exits.
There is an additional change; when the pending breakpoint is
created prior to this patch we see this line:
Breakpoint 2 (foo thread 2) pending.
While after this patch we get this line:
Breakpoint 2 (foo) pending.
Notice that 'thread 2' has disappeared. This might look like a
regression, but I don't think it is. That we said 'thread 2'
before was just a consequence of the lazy parsing of the breakpoint
specification, while with this patch GDB understands, and has
parsed away the 'thread 2' bit of the spec. If folk think the old
information was useful then this would be trivial to add back in
code_breakpoint::say_where.
As a result of this commit the breakpoints 'extra_string' field is now
only used by bp_dprintf type breakpoints to hold the printf format and
arguments. This string should always be empty for other breakpoint
types. This allows some cleanup in print_breakpoint_location.
In code_breakpoint::code_breakpoint I've changed an error case into an
assert. This is because the error is now handled earlier in
create_breakpoint. As a result we know that by this point, the
extra_string will always be nullptr for anything other than a
bp_dprintf style breakpoint.
The find_condition_and_thread_for_sals function is now no longer
needed, this was previously doing the delayed splitting of the extra
string into thread, task, and condition, but this is now all done in
create_breakpoint, so find_condition_and_thread_for_sals can be
deleted, and the code that calls this in
code_breakpoint::location_spec_to_sals can be removed. With this
update this code would only ever be reached for bp_dprintf style
breakpoints, and in these cases the extra_string should not contain
anything other than format and args.
The most interesting changes are all in create_breakpoint and in the
new file break-cond-parse.c. We have a new block of code early on in
create_breakpoint that is responsible for splitting the extra_string
into its component parts by calling create_breakpoint_parse_arg_string
a function in the new break-cond-parse.c file. This means that some
of the later code can be simplified a little.
The new break-cond-parse.c file implements the splitting up the
extra_string and finding all the parts, as well as some self-tests for
the new function.
Finally, now we know all the breakpoint details, these can be stored
within the breakpoint object if we end up creating a deferred
breakpoint. Additionally, if we are creating a deferred bp_dprintf we
can parse the extra_string to build the printf command.
The implementation here aims to maintain backwards compatibility as
much as possible, this means that:
1. We support abbreviations of 'thread', 'task', and 'inferior' in
some places on the breakpoint line. The handling of abbreviations
has (before this patch) been a little weird, so this works:
(gdb) break *main th 1
And creates a breakpoint at '*main' for thread 1 only, while this
does not work:
(gdb) break main th 1
In this case GDB will try to find the symbol 'main th 1'. This
weirdness exists before and after this patch.
2. The handling of '-force-condition' is odd, if this flag appears
immediately after a condition then it will be treated as part of the
condition, e.g.:
(gdb) break main if 0 -force-condition
No symbol "force" in current context.
But we are fine with these alternatives:
(gdb) break main if 0 thread 1 -force-condition
(gdb) break main -force-condition if 0
Again, this is just a quirk of how the breakpoint line used to be
parsed, but I've maintained this for backward compatibility. During
review it was suggested that -force-condition should become an
actual breakpoint flag (i.e. only valid after the 'break' command
but before the function name), and I don't think that would be a
terrible idea, however, that's not currently a trivial change, and I
think should be done as a separate piece of work. For now, this
patch just maintains the current behaviour.
The implementation works by first splitting the breakpoint condition
string (everything after the location specification) into a list of
tokens, each token has a type and a value. (e.g. we have a THREAD
token where the value is the thread-id string). The list of tokens is
validated, and in some cases, tokens are merged. Then the values are
extracted from the remaining token list.
Consider this breakpoint command:
(gdb) break main thread 1 if argc == 2
The condition string passed to create_breakpoint_parse_arg_string is
going to be 'thread 1 if argc == 2', which is then split into the
tokens:
{ THREAD: "1" } { CONDITION: "argc == 2" }
The thread-id (1) and the condition string 'argc == 2' are extracted
from these tokens and returns back to create_breakpoint.
Now consider this breakpoint command:
(gdb) break some_function if ( some_var == thread )
Here the user wants a breakpoint if 'some_var' is equal to the
variable 'thread'. However, when this is initially parsed we will
find these tokens:
{ CONDITION: "( some_var == " } { THREAD: ")" }
This is a consequence of how we have to try and figure out the
contents of the 'if' condition without actually parsing the
expression; parsing the expression requires that we know the location
in order to lookup the variables by name, and this can't be done for
pending breakpoints (their location isn't known yet), and one of the
points of this work is that we extract things like thread-id for
pending breakpoints.
And so, it is in this case that token merging takes place. We check
if the value of a token appearing immediately after the CONDITION
token looks valid. In this case, does ')' look like a valid
thread-id. Clearly, in this case ')' does not, and so me merge the
THREAD token into the condition token, giving:
{ CONDITION: "( some_var == thread )" }
Which is what we want.
I'm sure that we might still be able to come up with some edge cases
where the parser makes the wrong choice. I think long term the best
way to work around these would be to move the thread, inferior, task,
and -force-condition flags to be "real" command options for the break
command. I am looking into doing this, but can't guarantee if/when
that work would be completed, so this patch should be reviewed assume
that the work will never arrive (though I hope it will).
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-03-31 02:21:22 +08:00
|
|
|
if (*tmptok != '\0')
|
|
|
|
error (_("Junk '%s' after inferior keyword."), tmptok);
|
|
|
|
if (inferior_id > INT_MAX)
|
|
|
|
error (_("No inferior number '%ld'"), inferior_id);
|
|
|
|
inferior = static_cast<int> (inferior_id);
|
|
|
|
struct inferior *inf = find_inferior_id (inferior);
|
|
|
|
if (inf == nullptr)
|
|
|
|
error (_("No inferior number '%d'"), inferior);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case token::type::TASK:
|
|
|
|
{
|
|
|
|
if (task != -1)
|
|
|
|
error ("You can specify only one task.");
|
|
|
|
if (inferior != -1 || thread != -1)
|
|
|
|
error ("You can specify only one of thread, inferior, or task.");
|
|
|
|
char *tmptok;
|
gdb: fix use of out of scope temporary variable in break-cond-parse.c
The commit:
commit c6b486755e020095710c7494d029577ca967a13a
Date: Thu Mar 30 19:21:22 2023 +0100
gdb: parse pending breakpoint thread/task immediately
Introduce a use bug where the value of a temporary variable was being
used after it had gone out of scope. This was picked up by the
address sanitizer and would result in this error:
(gdb) maintenance selftest create_breakpoint_parse_arg_string
Running selftest create_breakpoint_parse_arg_string.
=================================================================
==2265825==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fbb08046511 at pc 0x000001632230 bp 0x7fff7c2fb770 sp 0x7fff7c2fb768
READ of size 1 at 0x7fbb08046511 thread T0
#0 0x163222f in create_breakpoint_parse_arg_string(char const*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*, int*, int*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, bool*) ../../src/gdb/break-cond-parse.c:496
#1 0x1633026 in test ../../src/gdb/break-cond-parse.c:582
#2 0x163391b in create_breakpoint_parse_arg_string_tests ../../src/gdb/break-cond-parse.c:649
#3 0x12cfebc in void std::__invoke_impl<void, void (*&)()>(std::__invoke_other, void (*&)()) /usr/include/c++/13/bits/invoke.h:61
#4 0x12cc8ee in std::enable_if<is_invocable_r_v<void, void (*&)()>, void>::type std::__invoke_r<void, void (*&)()>(void (*&)()) /usr/include/c++/13/bits/invoke.h:111
#5 0x12c81e5 in std::_Function_handler<void (), void (*)()>::_M_invoke(std::_Any_data const&) /usr/include/c++/13/bits/std_function.h:290
#6 0x18bb51d in std::function<void ()>::operator()() const /usr/include/c++/13/bits/std_function.h:591
#7 0x4193ef9 in selftests::run_tests(gdb::array_view<char const* const>, bool) ../../src/gdbsupport/selftest.cc:100
#8 0x21c2206 in maintenance_selftest ../../src/gdb/maint.c:1172
... etc ...
The problem was caused by three lines like this one:
thread_info *thr
= parse_thread_id (std::string (t.get_value ()).c_str (), &tmptok);
After parsing the thread-id TMPTOK would be left pointing into the
temporary string which had been created on this line. When on the
next line we did this:
gdb_assert (*tmptok == '\0');
The value of *TMPTOK is undefined.
Fix this by creating the std::string earlier in the scope. Now the
contents of the string will remain valid when we check *TMPTOK. The
address sanitizer issue is now resolved.
2024-09-09 04:17:55 +08:00
|
|
|
long task_id = strtol (tok_value.c_str (), &tmptok, 0);
|
gdb: parse pending breakpoint thread/task immediately
The initial motivation for this commit was to allow thread or inferior
specific breakpoints to only be inserted within the appropriate
inferior's program-space. The benefit of this is that inferiors for
which the breakpoint does not apply will no longer need to stop, and
then resume, for such breakpoints. This commit does not make this
change, but is a refactor to allow this to happen in a later commit.
The problem we currently have is that when a thread-specific (or
inferior-specific) breakpoint is created, the thread (or inferior)
number is only parsed by calling find_condition_and_thread_for_sals.
This function is only called for non-pending breakpoints, and requires
that we know the locations at which the breakpoint will be placed (for
expression checking in case the breakpoint is also conditional).
A consequence of this is that by the time we figure out the breakpoint
is thread-specific we have already looked up locations in all program
spaces. This feels wasteful -- if we knew the thread-id earlier then
we could reduce the work GDB does by only looking up locations within
the program space for which the breakpoint applies.
Another consequence of how find_condition_and_thread_for_sals is
called is that pending breakpoints don't currently know they are
thread-specific, nor even that they are conditional! Additionally, by
delaying parsing the thread-id, pending breakpoints can be created for
non-existent threads, this is different to how non-pending
breakpoints are handled, so I can do this:
$ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
(gdb) break foo thread 99
Function "foo" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (foo thread 99) pending.
(gdb) r
Starting program: /tmp/gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Error in re-setting breakpoint 1: Unknown thread 99.
[Inferior 1 (process 3329749) exited normally]
(gdb)
GDB only checked the validity of 'thread 99' at the point the 'foo'
location became non-pending. In contrast, if I try this:
$ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp
Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp...
(gdb) break main thread 99
Unknown thread 99.
(gdb)
GDB immediately checks if 'thread 99' exists. I think inconsistencies
like this are confusing, and should be fixed if possible.
In this commit the create_breakpoint function is updated so that the
extra_string, which contains the thread, inferior, task, and/or
condition information, is parsed immediately, even for pending
breakpoints.
Obviously, the condition still can't be validated until the breakpoint
becomes non-pending, but the thread, inferior, and task information
can be pulled from the extra-string, and can be validated early on,
even for pending breakpoints. The -force-condition flag is also
parsed as part of this early parsing change.
There are a couple of benefits to doing this:
1. Printing of breakpoints is more consistent now. Consider creating
a conditional breakpoint before this commit:
(gdb) set breakpoint pending on
(gdb) break pendingfunc if (0)
Function "pendingfunc" not defined.
Breakpoint 1 (pendingfunc if (0)) pending.
(gdb) break main if (0)
Breakpoint 2 at 0x401198: file /tmp/hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> pendingfunc if (0)
2 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18
stop only if (0)
(gdb)
And after this commit:
(gdb) set breakpoint pending on
(gdb) break pendingfunc if (0)
Function "pendingfunc" not defined.
Breakpoint 1 (pendingfunc) pending.
(gdb) break main if (0)
Breakpoint 2 at 0x401198: file /home/andrew/tmp/hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <PENDING> pendingfunc
stop only if (0)
2 breakpoint keep y 0x0000000000401198 in main at /home/andrew/tmp/hello.c:18
stop only if (0)
(gdb)
Notice that the display of the condition is now the same for the
pending and non-pending breakpoints.
The same is true for the thread, inferior, or task information in
thread, inferior, or task specific breakpoints; this information is
displayed on its own line rather than being part of the 'What'
field.
2. We can check that the thread exists as soon as the pending
breakpoint is created. Currently there is a weird difference
between pending and non-pending breakpoints when creating a
thread-specific breakpoint.
A pending thread-specific breakpoint only checks its thread when it
becomes non-pending, at which point the thread the breakpoint was
intended for might have exited. Here's the behaviour before this
commit:
(gdb) set breakpoint pending on
(gdb) break foo thread 2
Function "foo" not defined.
Breakpoint 2 (foo thread 2) pending.
(gdb) c
Continuing.
[Thread 0x7ffff7c56700 (LWP 2948835) exited]
Error in re-setting breakpoint 2: Unknown thread 2.
[Inferior 1 (process 2948832) exited normally]
(gdb)
Notice the 'Error in re-setting breakpoint 2: Unknown thread 2.'
line, this was triggered when GDB tried to make the breakpoint
non-pending, and GDB discovers that the thread no longer exists.
Compare that to the behaviour after this commit:
(gdb) set breakpoint pending on
(gdb) break foo thread 2
Function "foo" not defined.
Breakpoint 2 (foo) pending.
(gdb) c
Continuing.
[Thread 0x7ffff7c56700 (LWP 2949243) exited]
Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list.
[Inferior 1 (process 2949240) exited normally]
(gdb)
Now the behaviour for pending breakpoints is identical to
non-pending breakpoints, the thread specific breakpoint is removed
as soon as the thread the breakpoint is associated with exits.
There is an additional change; when the pending breakpoint is
created prior to this patch we see this line:
Breakpoint 2 (foo thread 2) pending.
While after this patch we get this line:
Breakpoint 2 (foo) pending.
Notice that 'thread 2' has disappeared. This might look like a
regression, but I don't think it is. That we said 'thread 2'
before was just a consequence of the lazy parsing of the breakpoint
specification, while with this patch GDB understands, and has
parsed away the 'thread 2' bit of the spec. If folk think the old
information was useful then this would be trivial to add back in
code_breakpoint::say_where.
As a result of this commit the breakpoints 'extra_string' field is now
only used by bp_dprintf type breakpoints to hold the printf format and
arguments. This string should always be empty for other breakpoint
types. This allows some cleanup in print_breakpoint_location.
In code_breakpoint::code_breakpoint I've changed an error case into an
assert. This is because the error is now handled earlier in
create_breakpoint. As a result we know that by this point, the
extra_string will always be nullptr for anything other than a
bp_dprintf style breakpoint.
The find_condition_and_thread_for_sals function is now no longer
needed, this was previously doing the delayed splitting of the extra
string into thread, task, and condition, but this is now all done in
create_breakpoint, so find_condition_and_thread_for_sals can be
deleted, and the code that calls this in
code_breakpoint::location_spec_to_sals can be removed. With this
update this code would only ever be reached for bp_dprintf style
breakpoints, and in these cases the extra_string should not contain
anything other than format and args.
The most interesting changes are all in create_breakpoint and in the
new file break-cond-parse.c. We have a new block of code early on in
create_breakpoint that is responsible for splitting the extra_string
into its component parts by calling create_breakpoint_parse_arg_string
a function in the new break-cond-parse.c file. This means that some
of the later code can be simplified a little.
The new break-cond-parse.c file implements the splitting up the
extra_string and finding all the parts, as well as some self-tests for
the new function.
Finally, now we know all the breakpoint details, these can be stored
within the breakpoint object if we end up creating a deferred
breakpoint. Additionally, if we are creating a deferred bp_dprintf we
can parse the extra_string to build the printf command.
The implementation here aims to maintain backwards compatibility as
much as possible, this means that:
1. We support abbreviations of 'thread', 'task', and 'inferior' in
some places on the breakpoint line. The handling of abbreviations
has (before this patch) been a little weird, so this works:
(gdb) break *main th 1
And creates a breakpoint at '*main' for thread 1 only, while this
does not work:
(gdb) break main th 1
In this case GDB will try to find the symbol 'main th 1'. This
weirdness exists before and after this patch.
2. The handling of '-force-condition' is odd, if this flag appears
immediately after a condition then it will be treated as part of the
condition, e.g.:
(gdb) break main if 0 -force-condition
No symbol "force" in current context.
But we are fine with these alternatives:
(gdb) break main if 0 thread 1 -force-condition
(gdb) break main -force-condition if 0
Again, this is just a quirk of how the breakpoint line used to be
parsed, but I've maintained this for backward compatibility. During
review it was suggested that -force-condition should become an
actual breakpoint flag (i.e. only valid after the 'break' command
but before the function name), and I don't think that would be a
terrible idea, however, that's not currently a trivial change, and I
think should be done as a separate piece of work. For now, this
patch just maintains the current behaviour.
The implementation works by first splitting the breakpoint condition
string (everything after the location specification) into a list of
tokens, each token has a type and a value. (e.g. we have a THREAD
token where the value is the thread-id string). The list of tokens is
validated, and in some cases, tokens are merged. Then the values are
extracted from the remaining token list.
Consider this breakpoint command:
(gdb) break main thread 1 if argc == 2
The condition string passed to create_breakpoint_parse_arg_string is
going to be 'thread 1 if argc == 2', which is then split into the
tokens:
{ THREAD: "1" } { CONDITION: "argc == 2" }
The thread-id (1) and the condition string 'argc == 2' are extracted
from these tokens and returns back to create_breakpoint.
Now consider this breakpoint command:
(gdb) break some_function if ( some_var == thread )
Here the user wants a breakpoint if 'some_var' is equal to the
variable 'thread'. However, when this is initially parsed we will
find these tokens:
{ CONDITION: "( some_var == " } { THREAD: ")" }
This is a consequence of how we have to try and figure out the
contents of the 'if' condition without actually parsing the
expression; parsing the expression requires that we know the location
in order to lookup the variables by name, and this can't be done for
pending breakpoints (their location isn't known yet), and one of the
points of this work is that we extract things like thread-id for
pending breakpoints.
And so, it is in this case that token merging takes place. We check
if the value of a token appearing immediately after the CONDITION
token looks valid. In this case, does ')' look like a valid
thread-id. Clearly, in this case ')' does not, and so me merge the
THREAD token into the condition token, giving:
{ CONDITION: "( some_var == thread )" }
Which is what we want.
I'm sure that we might still be able to come up with some edge cases
where the parser makes the wrong choice. I think long term the best
way to work around these would be to move the thread, inferior, task,
and -force-condition flags to be "real" command options for the break
command. I am looking into doing this, but can't guarantee if/when
that work would be completed, so this patch should be reviewed assume
that the work will never arrive (though I hope it will).
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-03-31 02:21:22 +08:00
|
|
|
if (*tmptok != '\0')
|
|
|
|
error (_("Junk '%s' after task keyword."), tmptok);
|
|
|
|
if (task_id > INT_MAX)
|
|
|
|
error (_("Unknown task %ld"), task_id);
|
|
|
|
task = static_cast<int> (task_id);
|
|
|
|
if (!valid_task_id (task))
|
|
|
|
error (_("Unknown task %d."), task);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case token::type::CONDITION:
|
|
|
|
cond_string.reset (savestring (t.get_value ().data (),
|
|
|
|
t.get_value ().size ()));
|
|
|
|
break;
|
|
|
|
case token::type::REST:
|
|
|
|
rest.reset (savestring (t.get_value ().data (),
|
|
|
|
t.get_value ().size ()));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Move results into the output locations. */
|
|
|
|
*force_ptr = force;
|
|
|
|
*thread_ptr = thread;
|
|
|
|
*inferior_ptr = inferior;
|
|
|
|
*task_ptr = task;
|
|
|
|
rest_ptr->reset (rest.release ());
|
|
|
|
cond_string_ptr->reset (cond_string.release ());
|
|
|
|
}
|
|
|
|
|
|
|
|
#if GDB_SELF_TEST
|
|
|
|
|
|
|
|
namespace selftests {
|
|
|
|
|
|
|
|
/* Run a single test of the create_breakpoint_parse_arg_string function.
|
|
|
|
INPUT is passed to create_breakpoint_parse_arg_string while all other
|
|
|
|
arguments are the expected output from
|
|
|
|
create_breakpoint_parse_arg_string. */
|
|
|
|
|
|
|
|
static void
|
|
|
|
test (const char *input, const char *condition, int thread = -1,
|
|
|
|
int inferior = -1, int task = -1, bool force = false,
|
|
|
|
const char *rest = nullptr, const char *error_msg = nullptr)
|
|
|
|
{
|
|
|
|
gdb::unique_xmalloc_ptr<char> extracted_condition;
|
|
|
|
gdb::unique_xmalloc_ptr<char> extracted_rest;
|
|
|
|
int extracted_thread, extracted_inferior, extracted_task;
|
|
|
|
bool extracted_force_condition;
|
|
|
|
std::string exception_msg, error_str;
|
|
|
|
|
|
|
|
if (error_msg != nullptr)
|
|
|
|
error_str = std::string (error_msg) + "\n";
|
|
|
|
|
|
|
|
try
|
|
|
|
{
|
|
|
|
create_breakpoint_parse_arg_string (input, &extracted_condition,
|
|
|
|
&extracted_thread,
|
|
|
|
&extracted_inferior,
|
|
|
|
&extracted_task, &extracted_rest,
|
|
|
|
&extracted_force_condition);
|
|
|
|
}
|
|
|
|
catch (const gdb_exception_error &ex)
|
|
|
|
{
|
|
|
|
string_file buf;
|
|
|
|
|
|
|
|
exception_print (&buf, ex);
|
|
|
|
exception_msg = buf.release ();
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((condition == nullptr) != (extracted_condition.get () == nullptr)
|
|
|
|
|| (condition != nullptr
|
|
|
|
&& strcmp (condition, extracted_condition.get ()) != 0)
|
|
|
|
|| (rest == nullptr) != (extracted_rest.get () == nullptr)
|
|
|
|
|| (rest != nullptr && strcmp (rest, extracted_rest.get ()) != 0)
|
|
|
|
|| thread != extracted_thread
|
|
|
|
|| inferior != extracted_inferior
|
|
|
|
|| task != extracted_task
|
|
|
|
|| force != extracted_force_condition
|
|
|
|
|| exception_msg != error_str)
|
|
|
|
{
|
|
|
|
if (run_verbose ())
|
|
|
|
{
|
|
|
|
debug_printf ("input: '%s'\n", input);
|
|
|
|
debug_printf ("condition: '%s'\n", extracted_condition.get ());
|
|
|
|
debug_printf ("rest: '%s'\n", extracted_rest.get ());
|
|
|
|
debug_printf ("thread: %d\n", extracted_thread);
|
|
|
|
debug_printf ("inferior: %d\n", extracted_inferior);
|
|
|
|
debug_printf ("task: %d\n", extracted_task);
|
|
|
|
debug_printf ("forced: %s\n",
|
|
|
|
extracted_force_condition ? "true" : "false");
|
|
|
|
debug_printf ("exception: '%s'\n", exception_msg.c_str ());
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Report the failure. */
|
|
|
|
SELF_CHECK (false);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Wrapper for test function. Pass through the default values for all
|
|
|
|
parameters, except the last parameter, which indicates that we expect
|
|
|
|
INPUT to trigger an error. */
|
|
|
|
|
|
|
|
static void
|
|
|
|
test_error (const char *input, const char *error_msg)
|
|
|
|
{
|
|
|
|
test (input, nullptr, -1, -1, -1, false, nullptr, error_msg);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Test the create_breakpoint_parse_arg_string function. Just wraps
|
|
|
|
multiple calls to the test function above. */
|
|
|
|
|
|
|
|
static void
|
|
|
|
create_breakpoint_parse_arg_string_tests ()
|
|
|
|
{
|
|
|
|
gdbarch *arch = current_inferior ()->arch ();
|
|
|
|
scoped_restore_current_pspace_and_thread restore;
|
|
|
|
scoped_mock_context<test_target_ops> mock_target (arch);
|
|
|
|
|
|
|
|
int global_thread_num = mock_target.mock_thread.global_num;
|
|
|
|
|
|
|
|
/* Test parsing valid breakpoint condition strings. */
|
|
|
|
test (" if blah ", "blah");
|
|
|
|
test (" if blah thread 1", "blah", global_thread_num);
|
|
|
|
test (" if blah inferior 1", "blah", -1, 1);
|
|
|
|
test (" if blah thread 1 ", "blah", global_thread_num);
|
|
|
|
test ("thread 1 woof", nullptr, global_thread_num, -1, -1, false, "woof");
|
|
|
|
test ("thread 1 X", nullptr, global_thread_num, -1, -1, false, "X");
|
|
|
|
test (" if blah thread 1 -force-condition", "blah", global_thread_num,
|
|
|
|
-1, -1, true);
|
|
|
|
test (" -force-condition if blah thread 1", "blah", global_thread_num,
|
|
|
|
-1, -1, true);
|
|
|
|
test (" -force-condition if blah thread 1 ", "blah", global_thread_num,
|
|
|
|
-1, -1, true);
|
|
|
|
test ("thread 1 -force-condition if blah", "blah", global_thread_num,
|
|
|
|
-1, -1, true);
|
|
|
|
test ("if (A::outer::func ())", "(A::outer::func ())");
|
|
|
|
test ("if ( foo == thread )", "( foo == thread )");
|
|
|
|
test ("if ( foo == thread ) inferior 1", "( foo == thread )", -1, 1);
|
|
|
|
test ("if ( foo == thread ) thread 1", "( foo == thread )",
|
|
|
|
global_thread_num);
|
|
|
|
test ("if foo == thread", "foo == thread");
|
|
|
|
test ("if foo == thread 1", "foo ==", global_thread_num);
|
|
|
|
|
|
|
|
/* Test parsing some invalid breakpoint condition strings. */
|
|
|
|
test_error ("thread 1 if foo == 123 thread 1",
|
|
|
|
"You can specify only one thread.");
|
|
|
|
test_error ("thread 1 if foo == 123 inferior 1",
|
|
|
|
"You can specify only one of thread, inferior, or task.");
|
|
|
|
test_error ("thread 1 if foo == 123 task 1",
|
|
|
|
"You can specify only one of thread, inferior, or task.");
|
|
|
|
test_error ("inferior 1 if foo == 123 inferior 1",
|
|
|
|
"You can specify only one inferior.");
|
|
|
|
test_error ("inferior 1 if foo == 123 thread 1",
|
|
|
|
"You can specify only one of thread, inferior, or task.");
|
|
|
|
test_error ("inferior 1 if foo == 123 task 1",
|
|
|
|
"You can specify only one of thread, inferior, or task.");
|
|
|
|
test_error ("thread 1.2.3", "Invalid thread ID: 1.2.3");
|
|
|
|
test_error ("thread 1/2", "Invalid thread ID: 1/2");
|
|
|
|
test_error ("thread 1xxx", "Invalid thread ID: 1xxx");
|
|
|
|
test_error ("inferior 1xxx", "Junk 'xxx' after inferior keyword.");
|
|
|
|
test_error ("task 1xxx", "Junk 'xxx' after task keyword.");
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace selftests
|
|
|
|
#endif /* GDB_SELF_TEST */
|
|
|
|
|
|
|
|
void _initialize_break_cond_parse ();
|
|
|
|
void
|
|
|
|
_initialize_break_cond_parse ()
|
|
|
|
{
|
|
|
|
#if GDB_SELF_TEST
|
|
|
|
selftests::register_test
|
|
|
|
("create_breakpoint_parse_arg_string",
|
|
|
|
selftests::create_breakpoint_parse_arg_string_tests);
|
|
|
|
#endif
|
|
|
|
}
|