binutils-gdb/gdb/break-cond-parse.c

700 lines
23 KiB
C
Raw Normal View History

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
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
}