The bug fixed by this [1] patch was caused by an out-of-bounds access to
a value's content. The code gets the value's content (just a pointer)
and then indexes it with a non-sensical index.
This made me think of changing functions that return value contents to
return array_views instead of a plain pointer. This has the advantage
that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view
are checked, making bugs more apparent / easier to find.
This patch changes the return types of these functions, and updates
callers to call .data() on the result, meaning it's not changing
anything in practice. Additional work will be needed (which can be done
little by little) to make callers propagate the use of array_view and
reap the benefits.
[1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html
Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
The pattern for using execute_command_to_string is:
...
std::string output;
output = execute_fn_to_string (fn, term_out);
...
This results in a problem when using it in a try/catch:
...
try
{
output = execute_fn_to_string (fn, term_out)
}
catch (const gdb_exception &e)
{
/* Use output. */
}
...
If an expection was thrown during execute_fn_to_string, then the output
remains unassigned, while it could be worthwhile to known what output was
generated by gdb before the expection was thrown.
Fix this by returning the string using a parameter instead:
...
execute_fn_to_string (output, fn, term_out)
...
Also add a variant without string parameter, to support places where the
function is used while ignoring the result:
...
execute_fn_to_string (fn, term_out)
...
Tested on x86_64-linux.
String-like settings (var_string, var_filename, var_optional_filename,
var_string_noescape) currently take a pointer to a `char *` storage
variable (typically global) that holds the setting's value. I'd like to
"mordernize" this by changing them to use an std::string for storage.
An obvious reason is that string operations on std::string are often
easier to write than with C strings. And they avoid having to do any
manual memory management.
Another interesting reason is that, with `char *`, nullptr and an empty
string often both have the same meaning of "no value". String settings
are initially nullptr (unless initialized otherwise). But when doing
"set foo" (where `foo` is a string setting), the setting now points to
an empty string. For example, solib_search_path is nullptr at startup,
but points to an empty string after doing "set solib-search-path". This
leads to some code that needs to check for both to check for "no value".
Or some code that converts back and forth between NULL and "" when
getting or setting the value. I find this very error-prone, because it
is very easy to forget one or the other. With std::string, we at least
know that the variable is not "NULL". There is only one way of
representing an empty string setting, that is with an empty string.
I was wondering whether the distinction between NULL and "" would be
important for some setting, but it doesn't seem so. If that ever
happens, it would be more C++-y and self-descriptive to use
optional<string> anyway.
Actually, there's one spot where this distinction mattered, it's in
init_history, for the test gdb.base/gdbinit-history.exp. init_history
sets the history filename to the default ".gdb_history" if it sees that
the setting was never set - if history_filename is nullptr. If
history_filename is an empty string, it means the setting was explicitly
cleared, so it leaves it as-is. With the change to std::string, this
distinction doesn't exist anymore. This can be fixed by moving the code
that chooses a good default value for history_filename to
_initialize_top. This is ran before -ex commands are processed, so an
-ex command can then clear that value if needed (what
gdb.base/gdbinit-history.exp tests).
Another small improvement, in my opinion is that we can now easily
give string parameters initial values, by simply initializing the global
variables, instead of xstrdup-ing it in the _initialize function.
In Python and Guile, when registering a string-like parameter, we
allocate (with new) an std::string that is owned by the param_smob (in
Guile) and the parmpy_object (in Python) objects.
This patch started by changing all relevant add_setshow_* commands to
take an `std::string *` instead of a `char **` and fixing everything
that failed to build. That includes of course all string setting
variable and their uses.
string_option_def now uses an std::string also, because there's a
connection between options and settings (see
add_setshow_cmds_for_options).
The add_path function in source.c is really complex and twisted, I'd
rather not try to change it to work on an std::string right now.
Instead, I added an overload that copies the std:string to a `char *`
and back. This means more copying, but this is not used in a hot path
at all, so I think it is acceptable.
Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93
Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
With current master and gcc 7.5.0/8.5.0, we have this timeout:
...
(gdb) print s^M
Multiple matches for s^M
[0] cancel^M
[1] s at src/gdb/testsuite/gdb.ada/interface/foo.adb:20^M
[2] s at src/gdb/testsuite/gdb.ada/interface/foo.adb:?^M
> FAIL: gdb.ada/interface.exp: print s (timeout)
...
[ The FAIL doesn't reproduce with gcc 9.3.1. This difference in
behaviour bisects to gcc commit d70ba0c10de.
The FAIL with earlier gcc bisects to gdb commit ba8694b650. ]
The FAIL is caused by gcc generating this debug info describing a named
artificial variable:
...
<2><1204>: Abbrev Number: 31 (DW_TAG_variable)
<1205> DW_AT_name : s.14
<1209> DW_AT_type : <0x1213>
<120d> DW_AT_artificial : 1
<120d> DW_AT_location : 5 byte block: 91 e0 7d 23 18 \
(DW_OP_fbreg: -288; DW_OP_plus_uconst: 24)
...
An easy way to fix this would be to simply not put named artificial variables
into the symbol table. However, that causes regressions for Ada. It relies
on being able to get the value from such variables, using a named reference.
Fix this instead by marking the symbol as artificial, and:
- ignoring such symbols in ada_resolve_variable, which fixes the FAIL
- ignoring such ada symbols in do_print_variable_and_value, which prevents
them from showing up in "info locals"
Note that a fix for the latter was submitted here (
https://sourceware.org/pipermail/gdb-patches/2008-January/054994.html ), and
this patch borrows from it.
Tested on x86_64-linux.
Co-Authored-By: Joel Brobecker <brobecker@adacore.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28180
I believe that many calls to fprintf_symbol_filtered are incorrect.
In particular, there are some that pass a symbol's print name, like:
fprintf_symbol_filtered (gdb_stdout, sym->print_name (),
current_language->la_language, DMGL_ANSI);
fprintf_symbol_filtered uses the "demangle" global to decide whether
or not to demangle -- but print_name does this as well. This can lead
to double-demangling. Normally this could be innocuous, except I also
plan to change Ada demangling in a way that causes this to fail.
I spotted some indentation issues where we had some spaces followed by
tabs at beginning of line, that I wanted to fix. So while at it, I did
a quick grep to find and fix all I could find.
gdb/ChangeLog:
* Fix tab after space indentation issues throughout.
Change-Id: I1acb414dd9c593b474ae2b8667496584df4316fd
I wrote a small script to spot a pattern of indentation mistakes I saw
happened in breakpoint.c. And while at it I ran it on all files and
fixed what I found. No behavior changes intended, just indentation and
addition / removal of curly braces.
gdb/ChangeLog:
* Fix some indentation mistakes throughout.
gdbserver/ChangeLog:
* Fix some indentation mistakes throughout.
Change-Id: Ia01990c26c38e83a243d8f33da1d494f16315c6e
Same idea as previous patch, but for add_info_alias.
gdb/ChangeLog:
* command.h (add_info_alias): Accept target as
cmd_list_element. Update callers.
Change-Id: If830d423364bf42d7bea5ac4dd3a81adcfce6f7a
The alias creation functions currently accept a name to specify the
target command. They pass this to add_alias_cmd, which needs to lookup
the target command by name.
Given that:
- We don't support creating an alias for a command before that command
exists.
- We always use add_info_alias just after creating that target command,
and therefore have access to the target command's cmd_list_element.
... change add_com_alias to accept the target command as a
cmd_list_element (other functions are done in subsequent patches). This
ensures we don't create the alias before the target command, because you
need to get the cmd_list_element from somewhere when you call the alias
creation function. And it avoids an unecessary command lookup. So it
seems better to me in every aspect.
gdb/ChangeLog:
* command.h (add_com_alias): Accept target as
cmd_list_element. Update callers.
Change-Id: I24bed7da57221cc77606034de3023fedac015150
Some add_set_show commands return a single cmd_list_element, the one for
the "set" command. A subsequent patch will need to access the show
command's cmd_list_element as well. Change these functions to return a
new structure type that holds both pointers.
I initially only modified add_setshow_boolean_cmd (the one I needed),
but I think it's better to change the whole chain to keep everything in
sync.
gdb/ChangeLog:
* command.h (set_show_commands): New.
(add_setshow_enum_cmd, add_setshow_auto_boolean_cmd,
add_setshow_boolean_cmd, add_setshow_filename_cmd,
add_setshow_string_cmd, add_setshow_string_noescape_cmd,
add_setshow_optional_filename_cmd, add_setshow_integer_cmd,
add_setshow_uinteger_cmd, add_setshow_zinteger_cmd,
add_setshow_zuinteger_cmd, add_setshow_zuinteger_unlimited_cmd):
Return set_show_commands. Adjust callers.
* cli/cli-decode.c (add_setshow_cmd_full): Return
set_show_commands, remove result parameters, adjust callers.
Change-Id: I17492b01b76002d09effc84830f9c6db26f1db7a
Previously, the prefixname field of struct cmd_list_element was manually
set for prefix commands. This seems verbose and error prone as it
required every single call to functions adding prefix commands to
specify the prefix name while the same information can be easily
generated.
Historically, this was not possible as the prefix field was null for
many commands, but this was fixed in commit
3f4d92ebdf by Philippe Waroquiers, so
we can rely on the prefix field being set when generating the prefix
name.
This commit also fixes a use after free in this scenario:
* A command gets created via Python (using the gdb.Command class).
The prefix name member is dynamically allocated.
* An alias to the new command is created. The alias's prefixname is set
to point to the prefixname for the original command with a direct
assignment.
* A new command with the same name as the Python command is created.
* The object for the original Python command gets freed and its
prefixname gets freed as well.
* The alias is updated to point to the new command, but its prefixname
is not updated so it keeps pointing to the freed one.
gdb/ChangeLog:
* command.h (add_prefix_cmd): Remove the prefixname argument as
it can now be generated automatically. Update all callers.
(add_basic_prefix_cmd): Ditto.
(add_show_prefix_cmd): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_abbrev_prefix_cmd): Ditto.
* cli/cli-decode.c (add_prefix_cmd): Ditto.
(add_basic_prefix_cmd): Ditto.
(add_show_prefix_cmd): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_prefix_cmd_suppress_notification): Ditto.
(add_abbrev_prefix_cmd): Ditto.
* cli/cli-decode.h (struct cmd_list_element): Replace the
prefixname member variable with a method which generates the
prefix name at runtime. Update all code reading the prefix
name to use the method, and remove all code setting it.
* python/py-cmd.c (cmdpy_destroyer): Remove code to free the
prefixname member as it's now a method.
(cmdpy_function): Determine if the command is a prefix by
looking at prefixlist, not prefixname.
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
This adds a new helper method, expression::first_opcode, that extracts
the outermost opcode of an expression. This simplifies some patches
in the expression rewrite series.
Note that this patch requires the earlier patch to avoid manual
dissection of OP_TYPE operations.
2020-12-15 Tom Tromey <tom@tromey.com>
* varobj.c (varobj_create): Use first_opcode.
* value.c (init_if_undefined_command): Use first_opcode.
* typeprint.c (whatis_exp): Use first_opcode.
* tracepoint.c (validate_actionline): Use first_opcode.
(encode_actions_1): Use first_opcode.
* stack.c (return_command): Use first_opcode.
* expression.h (struct expression) <first_opcode>: New method.
* eval.c (parse_and_eval_type): Use first_opcode.
* dtrace-probe.c (dtrace_process_dof_probe): Use first_opcode.
If the remote target closes while we're reading registers/memory for
restoring the selected frame in scoped_restore_current_thread's dtor,
the corresponding TARGET_CLOSE_ERROR error is swallowed by the
scoped_restore_current_thread's dtor, because letting exceptions
escape from a dtor is bad. It isn't great to lose that errors like
that, though. I've been thinking about how to avoid it, and I came up
with this patch.
The idea here is to make scoped_restore_current_thread's dtor do as
little as possible, to avoid any work that might throw in the first
place. And to do that, instead of having the dtor call
restore_selected_frame, which re-finds the previously selected frame,
just record the frame_id/level of the desired selected frame, and have
get_selected_frame find the frame the next time it is called. In
effect, this implements most of Cagney's suggestion, here:
/* On demand, create the selected frame and then return it. If the
selected frame can not be created, this function prints then throws
an error. When MESSAGE is non-NULL, use it for the error message,
otherwize use a generic error message. */
/* FIXME: cagney/2002-11-28: At present, when there is no selected
frame, this function always returns the current (inner most) frame.
It should instead, when a thread has previously had its frame
selected (but not resumed) and the frame cache invalidated, find
and then return that thread's previously selected frame. */
extern struct frame_info *get_selected_frame (const char *message);
The only thing missing to fully implement that would be to make
reinit_frame_cache just clear selected_frame instead of calling
select_frame(NULL), and the call select_frame(NULL) explicitly in the
places where we really wanted reinit_frame_cache to go back to the
current frame too. That can done separately, though, I'm not
proposing to do that in this patch.
Note that this patch renames restore_selected_frame to
lookup_selected_frame, and adds a new restore_selected_frame function
that doesn't throw, to be paired with the also-new save_selected_frame
function.
There's a restore_selected_frame function in infrun.c that I think can
be replaced by the new one in frame.c.
Also done in this patch is make the get_selected_frame's parameter be
optional, so that we don't have to pass down nullptr explicitly all
over the place.
lookup_selected_frame should really move from thread.c to frame.c, but
I didn't do that here, just to avoid churn in the patch while it
collects comments. I did make it extern and declared it in frame.h
already, preparing for the move. I will do the move as a follow up
patch if people agree with this approach.
Incidentally, this patch alone would fix the crashes fixed by the
previous patches in the series, because with this,
scoped_restore_current_thread's constructor doesn't throw either.
gdb/ChangeLog:
* blockframe.c (block_innermost_frame): Use get_selected_frame.
* frame.c
(scoped_restore_selected_frame::scoped_restore_selected_frame):
Use save_selected_frame. Save language as well.
(scoped_restore_selected_frame::~scoped_restore_selected_frame):
Use restore_selected_frame, and restore language as well.
(selected_frame_id, selected_frame_level): New.
(selected_frame): Update comments.
(save_selected_frame, restore_selected_frame): New.
(get_selected_frame): Use lookup_selected_frame.
(get_selected_frame_if_set): Delete.
(select_frame): Record selected_frame_level and selected_frame_id.
* frame.h (scoped_restore_selected_frame) <m_level, m_lang>: New
fields.
(get_selected_frame): Make 'message' parameter optional.
(get_selected_frame_if_set): Delete declaration.
(select_frame): Update comments.
(save_selected_frame, restore_selected_frame)
(lookup_selected_frame): Declare.
* gdbthread.h (scoped_restore_current_thread) <m_lang>: New field.
* infrun.c (struct infcall_control_state) <selected_frame_level>:
New field.
(save_infcall_control_state): Use save_selected_frame.
(restore_selected_frame): Delete.
(restore_infcall_control_state): Use restore_selected_frame.
* stack.c (select_frame_command_core, frame_command_core): Use
get_selected_frame.
* thread.c (restore_selected_frame): Rename to ...
(lookup_selected_frame): ... this and make extern. Select the
current frame if the frame level is -1.
(scoped_restore_current_thread::restore): Also restore the
language.
(scoped_restore_current_thread::~scoped_restore_current_thread):
Don't try/catch.
(scoped_restore_current_thread::scoped_restore_current_thread):
Save the language as well. Use save_selected_frame.
Change-Id: I73fd1cfc40d8513c28e5596383b7ecd8bcfe700f
When running test-case gdb.fortran/mixed-lang-stack.exp, it passes, but we
find in gdb.log:
...
(gdb) bt^M
...
#7 0x000000000040113c in mixed_func_1b (a=1, b=2, c=3, d=(4,5), \
e=<error reading variable: value requires 140737488341744 bytes, which \
is more than max-value-size>, g=..., _e=6) at mixed-lang-stack.f90:87^M
...
while a bit later in gdb.log, we have instead for the same frame (after
adding a gdb_test_no_output "set print frame-arguments all" to prevent
getting "e=..."):
...
(gdb) up^M
#7 0x000000000040113c in mixed_func_1b (a=1, b=2, c=3, d=(4,5), \
e='abcdef', g=( a = 1.5, b = 2.5 ), _e=6) at mixed-lang-stack.f90:87^M
...
The difference is that in the latter case, we print the frame while it's
selected, while in the former, it's not.
The problem is that while trying to resolve the dynamic type of e in
resolve_dynamic_type, we call dwarf2_evaluate_property with a frame == NULL
argument, and then use the selected frame as the context in which to evaluate
the dwarf property, effectively evaluating a DW_OP_fbreg operation in the
wrong frame context.
Fix this by temporarily selecting the frame of which we're trying to print the
arguments in print_frame_args, borrowing code from print_frame_local_vars that
was added to fix a similar issue in commit 16c3b12f19 "error/internal-error
printing local variable during "bt full".
Build and tested on x86_64-linux.
gdb/ChangeLog:
2020-08-15 Tom de Vries <tdevries@suse.de>
PR backtrace/26390
* stack.c (print_frame_args): Temporarily set the selected
frame to FRAME while printing the frame's arguments.
gdb/testsuite/ChangeLog:
2020-08-15 Tom de Vries <tdevries@suse.de>
PR backtrace/26390
* gdb.fortran/mixed-lang-stack.exp: Call bt with -frame-arguments all.
Update expected pattern.
This undoes most of the changes from these commits:
commit ec8e2b6d30
Date: Fri Jun 14 23:43:00 2019 +0100
gdb: Don't allow annotations to influence what else GDB prints
commit 0d3abd8cc9
Date: Wed Jun 12 22:34:26 2019 +0100
gdb: Remove an update of current_source_line and current_source_symtab
as a result of the discussion here:
https://sourceware.org/pipermail/gdb/2020-April/048468.html
Having taken time to reflect on the discussion, and reading the
documentation again I believe we should revert GDB's behaviour back to
how it used to be.
The original concern that triggered the initial patch was that when
annotations were on the current source and line were updated (inside
the annotation code), while when annotations are off this update would
not occur. This was incorrect, as printing the source with the call
to print_source_lines does also update the current source and line.
Further, the documentation here:
https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Annotations.html#Source-Annotations
Clearly states:
"The following annotation is used instead of displaying source code:
^Z^Zsource filename:line:character:middle:addr
..."
So it is documented that the 'source' annotation is a replacement for,
and not in addition to, actually printing the source lie.
There are still a few issues that I can see, these are:
1. In source.c:info_line_command, when annotations are on we call
annotate_source_line, however, if annotations are off then there is
no corresponding call to print the source line. This means that a
if a user uses 'info line ...' with annotations on, and then does a
'list', they will get different results than if they had done this
with annotations off.
2. It bothers me that the call to annotate_source_line returns a
boolean, and that this controls a call to print_source_line (in
stack.c:print_frame_info).
The reason for this is that the source line annotation will only
print something if the file is found, and the line number is in
range for the file.
It seems to me like an annotation should always be printed, either
one that identifies the file and line, or one that identifies the
file and line GDB would like to access, but couldn't.
I considered changing this, but in the end decided not too, if I
extend the existing 'source' annotation to print something in all
cases then I risk breaking existing UIs that rely on the file and
line always being valid. If I add a new annotation then this might
also break existing UIs that rely on GDB itself printing the error
from within print_source_line.
Given that annotations is deprecated (as I understand it) mechanism
for UIs to interact with GDB (in favour of MI) I figure we should just
restore the old behaviour, and leave the mini-bugs in until someone
actually complains.
This isn't a straight revert of the two commits mentioned above. I've
left annotate_source_line instead of going back to the original
identify_source_line, which lived in source.c, but was really
annotation related. The API for setting the current source and line
has changed since the original patches, so I updated for that change
too. Finally I wrote the code in stack.c so that we avoided an extra
level of indentation, which I felt made things easier to read.
gdb/ChangeLog:
* annotate.c (annotate_source_line): Update return type, add call
to update current symtab and line.
* annotate.h (annotate_source_line): Update return type, and
extend header comment.
* source.c (info_line_command): Check annotation_level before
calling annotate_source_line.
* stack.c (print_frame_info): If calling annotate_source_line
returns true, then don't print any other source line information.
gdb/testsuite/ChangeLog:
* gdb.base/annota1.exp: Update expected results.
* gdb.cp/annota2.exp: Update expected results, remove duplicate
test name.
* gdb.cp/annota3.exp: Update expected results.
This commit finally does the (small) change that started this patch
series.
It ensures that the class_alias is only used for user-defined aliases.
So, the few GDB pre-defined aliases that were using the 'class_alias'
class are now using a real help class, typically the class of
the aliased command.
gdb/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* command.h (enum command_class): Improve comments, document
that class_alias is for user-defined aliases, give the class
name for each class, remove unused class_xdb.
* cli/cli-decode.c (add_com_alias): Document THECLASS intended usage.
* breakpoint.c (_initialize_breakpoint): Replace class_alias
by a precise class.
* infcmd.c (_initialize_infcmd): Likewise.
* reverse.c (_initialize_reverse): Likewise.
* stack.c (_initialize_stack): Likewise.
* symfile.c (_initialize_symfile): Likewise.
* tracepoint.c (_initialize_tracepoint): Likewise.
gdb/testsuite/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/alias.exp: Verify 'help aliases' shows user defined aliases.
Remove TYPE_CODE, changing all the call sites to use type::code
directly. This is quite a big diff, but this was mostly done using sed
and coccinelle. A few call sites were done by hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_CODE): Remove. Change all call sites to use
type::code instead.
"frame" and "f" are created twice by stack.c _initialize_stack.
Remove the second creation.
Regression tested on amd64/Debian.
2020-04-30 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* stack.c (_initialize_stack): Remove duplicated creation
of "frame" command and "f" alias.
print_block_frame_labels has been commented out since 2010.
I don't think we need it; this patch removes it.
2020-04-29 Tom Tromey <tom@tromey.com>
* stack.c (print_block_frame_labels): Remove.
A (much) later patch will remove the call to value_check_printable
from common_val_print. This will needed to preserve some details of
how optimized-out structures are printed.
However, doing this will also break dw2-op-out-param.exp. Making the
change causes "bt" to print:
However, the test wants to see:
... operand2=<optimized out>
That is, a wholly-optimized out structure should not print its fields.
So, this patch introduces a new common_val_print_checked, which calls
value_check_printable first, and then arranges to use it in the one
spot that affects the test suite.
I was not completely sure if it would be preferable to change the
test. However, I reasoned that, assuming this output was intentional
in the first place, in a backtrace space is at a premium and so this
is a reasonable approach. In other spots calling common_val_print,
this behavior is probably unintended, or at least a "don't care".
gdb/ChangeLog
2020-03-13 Tom Tromey <tom@tromey.com>
* valprint.h (common_val_print_checked): Declare.
* valprint.c (common_val_print_checked): New function.
* stack.c (print_frame_arg): Use common_val_print_checked.
This commit brings support for the DWARF line table is_stmt field to
GDB. The is_stmt field is used by the compiler when a single source
line is split into multiple assembler instructions, especially if the
assembler instructions are interleaved with instruction from other
source lines.
The compiler will set the is_stmt flag false from some instructions
from the source lines, these instructions are not a good place to
insert a breakpoint in order to stop at the source line.
Instructions which are marked with the is_stmt flag true are a good
place to insert a breakpoint for that source line.
Currently GDB ignores all instructions for which is_stmt is false.
This is fine in a lot of cases, however, there are some cases where
this means the debug experience is not as good as it could be.
Consider stopping at a random instruction, currently this instruction
will be attributed to the last line table entry before this point for
which is_stmt was true - as these are the only line table entries that
GDB tracks. This can easily be incorrect in code with even a low
level of optimisation.
With is_stmt tracking in place, when stopping at a random instruction
we now attribute the instruction back to the real source line, even
when is_stmt is false for that instruction in the line table.
When inserting breakpoints we still select line table entries for
which is_stmt is true, so the breakpoint placing behaviour should not
change.
When stepping though code (at the line level, not the instruction
level) we will still stop at instruction where is_stmt is true, I
think this is more likely to be the desired behaviour.
Instruction stepping is, of course, unchanged, stepping one
instruction at a time, but we should now report more accurate line
table information with each instruction step.
The original motivation for this work was a patch posted by Bernd
here:
https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html
As part of that thread it was suggested that many issues would be
resolved if GDB supported line table views, this isn't something I've
attempted in this patch, though reading the spec, it seems like this
would be a useful feature to support in GDB in the future. The spec
is here:
http://dwarfstd.org/ShowIssue.php?issue=170427.1
And Bernd gives a brief description of the benefits here:
https://sourceware.org/ml/gdb-patches/2020-01/msg00147.html
With that all said, I think that there is benefit to having proper
is_stmt support regardless of whether we have views support, so I
think we should consider getting this in first, and then building view
support on top of this.
The gdb.cp/step-and-next-inline.exp test is based off a test proposed
by Bernd Edlinger in this message:
https://sourceware.org/ml/gdb-patches/2019-12/msg00842.html
gdb/ChangeLog:
* buildsym-legacy.c (record_line): Pass extra parameter to
record_line.
* buildsym.c (buildsym_compunit::record_line): Take an extra
parameter, reduce duplication in the line table, and record the
is_stmt flag in the line table.
* buildsym.h (buildsym_compunit::record_line): Add extra
parameter.
* disasm.c (do_mixed_source_and_assembly_deprecated): Ignore
non-statement lines.
* dwarf2/read.c (dwarf_record_line_1): Add extra parameter, pass
this to the symtab builder.
(dwarf_finish_line): Pass extra parameter to dwarf_record_line_1.
(lnp_state_machine::record_line): Pass a suitable is_stmt flag
through to dwarf_record_line_1.
* infrun.c (process_event_stop_test): When stepping, don't stop at
a non-statement instruction, and only refresh the step info when
we land in the middle of a line's range. Also add an extra
comment.
* jit.c (jit_symtab_line_mapping_add_impl): Initialise is_stmt
field.
* record-btrace.c (btrace_find_line_range): Only record lines
marked as is-statement.
* stack.c (frame_show_address): Show the frame address if we are
in a non-statement sal.
* symmisc.c (dump_symtab_1): Print the is_stmt flag.
(maintenance_print_one_line_table): Print a header for the is_stmt
column, and include is_stmt information in the output.
* symtab.c (find_pc_sect_line): Find lines marked as statements in
preference to non-statements.
(find_pcs_for_symtab_line): Prefer is-statement entries.
(find_line_common): Likewise.
* symtab.h (struct linetable_entry): Add is_stmt field.
(struct symtab_and_line): Likewise.
* xcoffread.c (arrange_linetable): Initialise is_stmt field when
arranging the line table.
gdb/testsuite/ChangeLog:
* gdb.cp/step-and-next-inline.cc: New file.
* gdb.cp/step-and-next-inline.exp: New file.
* gdb.cp/step-and-next-inline.h: New file.
* gdb.dwarf2/dw2-is-stmt.c: New file.
* gdb.dwarf2/dw2-is-stmt.exp: New file.
* gdb.dwarf2/dw2-is-stmt-2.c: New file.
* gdb.dwarf2/dw2-is-stmt-2.exp: New file.
* gdb.dwarf2/dw2-ranges-base.exp: Update line table pattern.
Consider a test-case compiled with -g:
...
int main (void) {
static int b = 2;
return 0;
}
...
When running info locals in main, we get:
...
(gdb) info locals
No locals.
...
The info locals documentation states:
...
Print the local variables of the selected frame, each on a separate line.
These are all variables (declared either static or automatic) accessible at
the point of execution of the selected frame.
...
So, "info locals" should have printed static variable b.
The variable is present in dwarf info:
...
<2><14a>: Abbrev Number: 6 (DW_TAG_variable)
<14b> DW_AT_name : b
<153> DW_AT_const_value : 2
...
but instead of a location attribute, it has a const_value attribute, which
causes the corresponding symbol to have LOC_CONST, which causes info locals to
skip it.
Fix this by handling LOC_CONST in iterate_over_block_locals.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-02-24 Tom de Vries <tdevries@suse.de>
PR gdb/25592
* stack.c (iterate_over_block_locals): Handle LOC_CONST.
gdb/testsuite/ChangeLog:
2020-02-24 Tom de Vries <tdevries@suse.de>
PR gdb/25592
* gdb.base/info-locals-unused-static-var.c: New test.
* gdb.base/info-locals-unused-static-var.exp: New file.
In this commit:
commit ec8e2b6d30
Date: Fri Jun 14 23:43:00 2019 +0100
gdb: Don't allow annotations to influence what else GDB prints
A change was accidentally made that moved a call to do_gdb_disassembly
out of an if block guarded by 'if (source_print && sal.symtab)'. The
result was that if a user has 'set disassemble-next-line on' then the
backtrace would now include some disassembly of a few instructions in
each frame.
This change was not intentional, but was not spotted by any tests.
This commit restores the old behaviour and adds a test to ensure this
doesn't break again in the future.
gdb/ChangeLog:
* stack.c (print_frame_info): Move disassemble_next_line code
inside source_print block.
gdb/testsuite/ChangeLog:
* gdb.base/backtrace.c: New file.
* gdb.base/backtrace.exp: New file.
Change-Id: I47c52a202fa74be138382646b695827940178689
GDB crashes when doing:
(gdb) faas
Aborted
Do the needed check to avoid crashing.
gdb/ChangeLog
2019-12-06 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* stack.c (faas_command): Check a command is provided.
* thread.c (taas_command, tfaas_command): Likewise.
gdb/testsuite/ChangeLog
2019-12-06 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.threads/pthreads.exp: Test taas and tfaas without command.
* gdb.base/frameapply.exp: Test faas without command.
In stack.c we currently have a set of static global variables to track
the last displayed symtab and line. This commit moves all of these
into a class and adds an instance of the class to track the same
information.
The API into stack.c is unchanged after this cleanup.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* stack.c (set_last_displayed_sal): Delete.
(last_displayed_sal_valid): Delete.
(last_displayed_pspace): Delete.
(last_displayed_addr): Delete.
(last_displayed_symtab): Delete.
(last_displayed_line): Delete.
(class last_displayed_symtab_info_type): New.
(last_displayed_symtab_info): New static global variable.
(print_frame_info): Call methods on last_displayed_symtab_info.
(clear_last_displayed_sal): Update header comment, and make use of
last_displayed_symtab_info.
(last_displayed_sal_is_valid): Likewise.
(get_last_displayed_pspace): Likewise.
(get_last_displayed_addr): Likewise.
(get_last_displayed_symtab): Likewise.
(get_last_displayed_line): Likewise.
(get_last_displayed_sal): Likewise.
* stack.h (clear_last_displayed_sal): Update header comment.
(last_displayed_sal_is_valid): Likewise.
(get_last_displayed_pspace): Likewise.
(get_last_displayed_addr): Likewise.
(get_last_displayed_symtab): Likewise.
(get_last_displayed_line): Likewise.
(get_last_displayed_sal): Likewise.
Change-Id: Ia3dbfe267feec03108c5c8ed8bd94fc0a030c3ed
Just a clean up, should be no user visible changes after this commit.
gdb/ChangeLog:
* stack.c (frame_show_address): Convert return type to bool.
* stack.h (frame_show_address): Likewise, and update header
comment.
Change-Id: Iaaa9ebd4ff6534db19c5329f1c604932c747bd7f
This adds more uses of styled_string, changing gdb to style some
output that was previously left unstyled.
gdb/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* stack.c (print_frame, info_frame_command_core): Use
styled_string.
* linux-thread-db.c (try_thread_db_load_1)
(try_thread_db_load_from_pdir_1): Use styled_string.
* auto-load.c (file_is_auto_load_safe, execute_script_contents)
(auto_load_section_scripts, info_auto_load_local_gdbinit)
(maybe_print_unsupported_script_warning)
(maybe_print_script_not_found_warning): Use styled_string.
* ada-lang.c (user_select_syms): Use styled_string.
This introduces a new "metadata" style and changes many places in gdb
to use it. The idea here is to let the user distinguish gdb output
from output that (conceptually at least) comes directly from the
inferior. The newly-styled category includes text that gdb
traditionally surrounds in "<...>", like "<unavailable>".
I only added a single test for this. In many cases this output is
difficult to test. Also, while developing this errors in the
implementation of the new printf formats showed up as regressions.
gdb/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* p-lang.c (pascal_printstr): Use metadata style.
* value.c (show_convenience): Use metadata style.
* valprint.c (valprint_check_validity, val_print_optimized_out)
(val_print_not_saved, val_print_unavailable)
(val_print_invalid_address, generic_val_print, val_print)
(value_check_printable, val_print_array_elements): Use metadata
style.
* ui-out.h (class ui_out) <field_fmt>: New overload.
<do_field_fmt>: Add style parameter.
* ui-out.c (ui_out::field_fmt): New overload.
* typeprint.c (type_print_unknown_return_type)
(val_print_not_allocated, val_print_not_associated): Use metadata
style.
* tui/tui-out.h (class tui_ui_out) <do_field_fmt>: Add style
parameter.
* tui/tui-out.c (tui_ui_out::do_field_fmt): Update.
* tracepoint.c (tvariables_info_1): Use metadata style.
* stack.c (print_frame_arg, print_frame_info, print_frame)
(info_frame_command_core): Use metadata style.
* skip.c (info_skip_command): Use metadata style.
* rust-lang.c (rust_print_enum): Use metadata style.
* python/py-prettyprint.c (print_stack_unless_memory_error): Use
metadata style.
* python/py-framefilter.c (py_print_single_arg): Use metadata
style.
* printcmd.c (do_one_display, print_variable_and_value): Use
metadata style.
* p-valprint.c (pascal_val_print)
(pascal_object_print_value_fields): Use metadata style.
* p-typeprint.c (pascal_type_print_base): Use metadata style.
* mi/mi-out.h (class mi_ui_out) <do_field_fmt>: Add style
parameter.
* mi/mi-out.c (mi_ui_out::do_field_fmt): Update.
* m2-valprint.c (m2_print_long_set): Use metadata style.
* m2-typeprint.c (m2_print_type): Use metadata style.
* infcmd.c (print_return_value_1): Use metadata style.
* gnu-v3-abi.c (print_one_vtable): Use metadata style.
* f-valprint.c (info_common_command_for_block): Use metadata
style.
* f-typeprint.c (f_type_print_base): Use metadata style.
* expprint.c (print_subexp_standard): Use metadata style.
* cp-valprint.c (cp_print_value_fields): Use metadata style.
* cli/cli-style.h (class cli_style_option): Add constructor.
(metadata_style): Declare.
* cli/cli-style.c (metadata_style): New global.
(_initialize_cli_style): Register metadata style.
* cli-out.h (class cli_ui_out) <do_field_fmt>: Add style
parameter.
* cli-out.c (cli_ui_out::do_field_fmt): Update.
* c-typeprint.c (c_type_print_base_struct_union)
(c_type_print_base_1): Use metadata style.
* breakpoint.c (watchpoint_value_print)
(print_one_breakpoint_location): Use metadata style.
* break-catch-syscall.c (print_one_catch_syscall): Use metadata
style.
* break-catch-sig.c (signal_catchpoint_print_one): Use metadata
style.
* ada-valprint.c (val_print_packed_array_elements, printstr)
(print_field_values, ada_val_print_ref, ada_val_print): Use
metadata style.
* ada-typeprint.c (print_array_type, ada_print_type): Use metadata
style.
* ada-tasks.c (print_ada_task_info, info_task): Use metadata
style.
* ada-lang.c (user_select_syms): Use metadata style.
gdb/testsuite/ChangeLog
2019-10-01 Tom Tromey <tom@tromey.com>
* lib/gdb-utils.exp (style): Handle "metadata" argument.
* gdb.base/style.exp: Add metadata style test.
The 'info variables', its alias 'whereis', and 'info functions' all
include non-debug symbols in the output by default. The list of
non-debug symbols can sometimes be quite long, resulting in the
debug symbol based results being scrolled off the screen.
This commit adds a '-n' flag to all of the commands listed above that
excludes the non-debug symbols from the results, leaving just the
debug symbol based results.
gdb/ChangeLog:
* cli/cli-utils.c (info_print_options_defs): Delete.
(make_info_print_options_def_group): Delete.
(extract_info_print_options): Delete.
(info_print_command_completer): Delete.
(info_print_args_help): Add extra parameter, and optionally
include text about -n flag.
* cli/cli-utils.h (struct info_print_options): Delete.
(extract_info_print_options): Delete declaration.
(info_print_command_completer): Delete declaration.
(info_print_args_help): Add extra parameter, extend header
comment.
* python/python.c (gdbpy_rbreak): Pass additional parameter to
search_symbols.
* stack.c (struct info_print_options): New type.
(info_print_options_defs): New file scoped variable.
(make_info_print_options_def_group): New static function.
(info_print_command_completer): New static function.
(info_locals_command): Update to use new local functions.
(info_args_command): Likewise.
(_initialize_stack): Add extra parameter to calls to
info_print_args_help.
* symtab.c (search_symbols): Add extra parameter, use this to
possibly excluse non-debug symbols.
(symtab_symbol_info): Add extra parameter, which is passed on to
search_symbols.
(struct info_print_options): New type.
(info_print_options_defs): New file scoped variable.
(make_info_print_options_def_group): New static function.
(info_print_command_completer): New static function.
(info_variables_command): Update to use local functions, and pass
extra parameter through to symtab_symbol_info.
(info_functions_command): Likewise.
(info_types_command): Pass additional argument through to
symtab_symbol_info.
(rbreak_command): Pass extra argument to search_symbols.
(_initialize_symtab): Add extra arguments for calls to
info_print_args_help, and update help text for 'info variables',
'whereis', and 'info functions' commands.
* symtab.h (search_symbols): Add extra argument to declaration.
* NEWS: Mention new flags.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Add information about the -n flag to
"info variables" and "info functions".
gdb/testsuite/ChangeLog:
* gdb.base/info-fun.exp: Extend to test the -n flag for 'info
functions'. Reindent as needed.
* gdb.base/info-var-f1.c: New file.
* gdb.base/info-var-f2.c: New file.
* gdb.base/info-var.exp: New file.
* gdb.base/info-var.h: New file.
Add a new print_pc which prints both the PC and a new field addr_flags.
Call this wherever the PC is printed in stack.c.
Add a new gdbarch method get_pc_address_flags to obtain the addr_flag
contents. By default returns an empty string, on AArch64 this returns
PAC if the address has been masked in the frame.
Document this in the manual and NEWS file.
gdb/ChangeLog:
* NEWS (Other MI changes): New subsection.
* aarch64-tdep.c (aarch64_get_pc_address_flags): New function.
(aarch64_gdbarch_init): Add aarch64_get_pc_address_flags.
* arch-utils.c (default_get_pc_address_flags): New function.
* arch-utils.h (default_get_pc_address_flags): New declaration.
* gdbarch.sh: Add get_pc_address_flags.
* gdbarch.c: Regenerate.
* gdbarch.h: Likewise.
* stack.c (print_pc): New function.
(print_frame_info) (print_frame): Call print_pc.
gdb/doc/ChangeLog:
* gdb.texinfo (AArch64 Pointer Authentication)
(GDB/MI Breakpoint Information) (Frame Information): Document
addr_field.
This changes struct frame_arg to be self-managing and then fixes the
various users.
Tested by the buildbot.
gdb/ChangeLog
2019-08-07 Tom Tromey <tromey@adacore.com>
* stack.c (print_frame_arg, read_frame_local, read_frame_arg)
(print_frame_args): Update.
* python/py-framefilter.c (py_print_single_arg, enumerate_args):
Update.
* mi/mi-cmd-stack.c (list_arg_or_local): Update.
* frame.h (struct frame_arg): Add initializers.
<error>: Now a unique_xmalloc_ptr.
Armv8.3-a Pointer Authentication causes the function return address to be
obfuscated on entry to some functions. GDB must unmask the link register in
order to produce a backtrace.
The following patch adds markers of [PAC] to the bracktrace, to indicate
which addresses needed unmasking. This includes the backtrace when using MI.
For example, consider the following backtrace:
(gdb) bt
0 0x0000000000400490 in puts@plt ()
1 0x00000000004005dc in foo ("hello") at cbreak-lib.c:6
2 0x0000000000400604 [PAC] in bar () at cbreak-lib.c:12
3 0x0000000000400620 [PAC] in main2 () at cbreak.c:17
4 0x00000000004005b4 in main () at cbreak-3.c:10
The functions in cbreak-lib use pointer auth, which masks the return address
to the previous function, causing the addresses of bar (in the library) and main2
(in the main binary) to require unmasking in order to unwind the backtrace.
An extra bool is added alongside the prev_pc in the frame structure. At the
point at which the link register is unmasked, the AArch64 port calls into frame
to sets the bool. This is the most efficient way of doing it.
The marker is also added to the python frame printer, which is always printed if
set. The marker is not explicitly exposed to the python code.
I expect this will potentially cause issues with some tests in the testsuite
when Armv8.3 pointer authentication is used. This should be fixed up in the
the future once real hardware is available for full testsuite testing.
gdb/ChangeLog:
* NEWS: Expand the Pointer Authentication entry.
* aarch64-tdep.c (aarch64_frame_unmask_address): Rename from this.
(aarch64_frame_unmask_lr): ... to this.
(aarch64_prologue_prev_register, aarch64_dwarf2_prev_register):
Call aarch64_frame_unmask_lr.
* frame.c (struct frame_info): Add "masked" variable.
(frame_set_previous_pc_masked) (frame_get_pc_masked): New functions.
(fprint_frame): Check for masked pc.
* frame.h (frame_set_previous_pc_masked) (frame_get_pc_masked): New
declarations.
* python/py-framefilter.c (py_print_frame): Check for masked pc.
* stack.c (print_frame): Check for masked pc.
gdb/doc/ChangeLog:
* gdb.texinfo (AArch64 Pointer Authentication): New subsection.
With this patch, the help docs now respect 2 invariants:
* The first line of a command help is terminated by a '.' character.
* The last character of a command help is not a newline character.
Note that the changes for the last invariant were done by Tom, as part of :
[PATCH] Remove trailing newlines from help text
https://sourceware.org/ml/gdb-patches/2019-06/msg00050.html
but some occurrences have been re-introduced since then.
Some help docs had to be rephrased/restructured to respect the above
invariants.
Before this patch, print_doc_line was printing the first line
of a command help documentation, but stopping at the first '.'
or ',' character.
This was giving inconsistent results :
* The first line of command helps was sometimes '.' terminated,
sometimes not.
* The first line of command helps was not always designed to be
readable/understandable/unambiguous when stopping at the first
'.' or ',' character.
This e.g. created the following inconsistencies/problems:
< catch exception -- Catch Ada exceptions
< catch handlers -- Catch Ada exceptions
< catch syscall -- Catch system calls by their names
< down-silently -- Same as the `down' command
while the new help is:
> catch exception -- Catch Ada exceptions, when raised.
> catch handlers -- Catch Ada exceptions, when handled.
> catch syscall -- Catch system calls by their names, groups and/or numbers.
> down-silently -- Same as the `down' command, but does not print anything.
Also, the command help doc should not be terminated by a newline
character, but this was not respected by all commands.
The cli-option -OPT framework re-introduced some occurences.
So, the -OPT build help framework was changed to not output newlines at the
end of %OPTIONS% replacement.
This patch changes the help documentations to ensure the 2 invariants
given above.
It implied to slightly rephrase or restructure some help docs.
Based on the above invariants, print_doc_line (called by
'apropos' and 'help' commands to print the first line of a command
help) now outputs the full first line of a command help.
This all results in a lot of small changes in the produced help docs.
There are less code changes than changes in the help docs, as a lot
of docs are produced by some code (e.g. the remote packet usage settings).
gdb/ChangeLog
2019-08-07 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-decode.h (print_doc_line): Add for_value_prefix argument.
* cli/cli-decode.c (print_doc_line): Likewise. It now prints
the full first line, except when FOR_VALUE_PREFIX. In this case,
the trailing '.' is not output, and the first character is uppercased.
(print_help_for_command): Update call to print_doc_line.
(print_doc_of_command): Likewise.
* cli/cli-setshow.c (deprecated_show_value_hack): Likewise.
* cli/cli-option.c (append_indented_doc): Do not append newline.
(build_help_option): Append newline after first appended_indented_doc
only if a second call is done.
(build_help): Append 2 new lines before each option, except the first
one.
* compile/compile.c (_initialize_compile): Add new lines after
%OPTIONS%, when not at the end of the help.
Change help doc or code
producing the help doc to respect the invariants.
* maint-test-options.c (_initialize_maint_test_options): Likewise.
Also removed the new line after 'Options:', as all other commands
do not put an empty line between 'Options:' and the first option.
* printcmd.c (_initialize_printcmd): Likewise.
* stack.c (_initialize_stack): Likewise.
* interps.c (interpreter_exec_cmd): Fix "Usage:" line that was
incorrectly telling COMMAND is optional.
* ada-lang.c (_initialize_ada_language): Change help doc or code
producing the help doc to respect the invariants.
* ada-tasks.c (_initialize_ada_tasks): Likewise.
* breakpoint.c (_initialize_breakpoint): Likewise.
* cli/cli-cmds.c (_initialize_cli_cmds): Likewise.
* cli/cli-logging.c (_initialize_cli_logging): Likewise.
* cli/cli-setshow.c (_initialize_cli_setshow): Likewise.
* cli/cli-style.c (cli_style_option::add_setshow_commands,
_initialize_cli_style): Likewise.
* corelow.c (core_target_info): Likewise.
* dwarf-index-cache.c (_initialize_index_cache): Likewise.
* dwarf2read.c (_initialize_dwarf2_read): Likewise.
* filesystem.c (_initialize_filesystem): Likewise.
* frame.c (_initialize_frame): Likewise.
* gnu-nat.c (add_task_commands): Likewise.
* infcall.c (_initialize_infcall): Likewise.
* infcmd.c (_initialize_infcmd): Likewise.
* interps.c (_initialize_interpreter): Likewise.
* language.c (_initialize_language): Likewise.
* linux-fork.c (_initialize_linux_fork): Likewise.
* maint-test-settings.c (_initialize_maint_test_settings): Likewise.
* maint.c (_initialize_maint_cmds): Likewise.
* memattr.c (_initialize_mem): Likewise.
* printcmd.c (_initialize_printcmd): Likewise.
* python/lib/gdb/function/strfns.py (_MemEq, _StrLen, _StrEq,
_RegEx): Likewise.
* ravenscar-thread.c (_initialize_ravenscar): Likewise.
* record-btrace.c (_initialize_record_btrace): Likewise.
* record-full.c (_initialize_record_full): Likewise.
* record.c (_initialize_record): Likewise.
* regcache-dump.c (_initialize_regcache_dump): Likewise.
* regcache.c (_initialize_regcache): Likewise.
* remote.c (add_packet_config_cmd, init_remote_threadtests,
_initialize_remote): Likewise.
* ser-tcp.c (_initialize_ser_tcp): Likewise.
* serial.c (_initialize_serial): Likewise.
* skip.c (_initialize_step_skip): Likewise.
* source.c (_initialize_source): Likewise.
* stack.c (_initialize_stack): Likewise.
* symfile.c (_initialize_symfile): Likewise.
* symtab.c (_initialize_symtab): Likewise.
* target-descriptions.c (_initialize_target_descriptions): Likewise.
* top.c (init_main): Likewise.
* tracefile-tfile.c (tfile_target_info): Likewise.
* tracepoint.c (_initialize_tracepoint): Likewise.
* tui/tui-win.c (_initialize_tui_win): Likewise.
* utils.c (add_internal_problem_command): Likewise.
* valprint.c (value_print_option_defs): Likewise.
gdb/testsuite/ChangeLog
2019-08-07 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/style.exp: Update tests for help doc new invariants.
* gdb.base/help.exp: Likewise.
Currently some code in gdb uses build_help with N_(), like:
static const std::string compile_print_help
= gdb::option::build_help (N_("\
I believe this is incorrect. The N_ macro is used to mark text that
should end up in the message catalog, but which will be translated by
a later call to gettext.
However, in this case, there is no later call to gettext, so (if gdb
had translations), this text would remain untranslated.
Instead, I think using the ordinary _() macro is correct here.
Translators will have to know to preserve "%OPTIONS%" in the text --
but that seems both unavoidable and fine.
Tested by rebuilding as there's not much else to do.
gdb/ChangeLog
2019-08-05 Tom Tromey <tromey@adacore.com>
* compile/compile.c (_initialize_compile): Use _(), not N_().
* thread.c (_initialize_thread): Use _(), not N_().
* stack.c (_initialize_stack): Use _(), not N_().
* printcmd.c (_initialize_printcmd): Use _(), not N_().
New settings allow to better control what frame information is printed.
'set print frame-info' allows to override the default frame information
printed when a GDB command prints a frame.
The backtrace command has a new option -frame-info to override
this global setting.
It is now possible to have very short frame information by using the
new 'set print frame-arguments presence' and
'set print frame-info short-location'.
Combined with 'set print address off', a backtrace will only show
the essential information to see the function call chain, e.g.:
(gdb) set print address off
(gdb) set print frame-arguments presence
(gdb) set print frame-info short-location
(gdb) bt
#0 break_me ()
#1 call_me (...)
#2 main ()
(gdb)
This is handy in particular for big backtraces with functions having
many arguments.
Python frame filter printing logic has been updated to respect the new
setting in non MI mode.
Also, the default frame information printed was inconsistent when
backtrace was printing the frame information itself, or when the python
frame filtering code was printing the frame information.
This patch changes the default of python frame filtering to have a
consistent behaviour regarding printed frame-information, whatever
the presence/activity/matches of python filters.
2019-07-29 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* frame.h (enum print_what): New value 'SHORT_LOCATION', update
comments.
(print_frame_info_auto, print_frame_info_source_line,
print_frame_info_location, print_frame_info_source_and_location,
print_frame_info_location_and_address, print_frame_info_short_location):
New declarations.
(struct frame_print_options): New member print_frame_info.
* extension.h (enum ext_lang_frame_args): New value CLI_PRESENCE.
* stack.h (get_user_print_what_frame_info): New declaration.
(frame_show_address): New declaration.
* stack.c (print_frame_arguments_choices): New value 'presence'.
(print_frame_info_auto, print_frame_info_source_line,
print_frame_info_location, print_frame_info_source_and_location,
print_frame_info_location_and_address, print_frame_info_short_location,
print_frame_info_choices, print_frame_info_print_what): New definitions.
(print_frame_args): Only print dots for args if print frame-arguments
is 'presence'.
(frame_print_option_defs): New element for "frame-info".
(get_user_print_what_frame_info): New function.
(frame_show_address): Make non static. Move comment to stack.h.
(print_frame_info_to_print_what): New function.
(print_frame_info): Update comment. Use fp_opts.print_frame_info
to decide what to print.
(backtrace_command_1): Handle the new print_frame_arguments_presence
value.
(_initialize_stack): Call add_setshow_enum_cmd for frame-info.
* python/py-framefilter.c (py_print_args): Handle CLI_PRESENCE.
(py_print_frame): In non-mi mode, use LOCATION as default for
print_what, similarly to frame information printed directly by
backtrace command. Handle frame-info user option in non MI mode.
The discussion on gdb-patches which led to this patch may be found
here:
https://www.sourceware.org/ml/gdb-patches/2019-05/msg00018.html
Here's a brief synopsis/analysis:
Eli Zaretskii, while debugging a Windows emacs executable, found
that functions comprised of more than one (non-contiguous)
address range were not being displayed correctly in a backtrace. This
is the example that Eli provided:
(gdb) bt
#0 0x76a63227 in KERNELBASE!DebugBreak ()
from C:\Windows\syswow64\KernelBase.dll
#1 0x012e7b89 in emacs_abort () at w32fns.c:10768
#2 0x012e1f3b in print_vectorlike.cold () at print.c:1824
#3 0x011d2dec in print_object (obj=<optimized out>, printcharfun=XIL(0),
escapeflag=true) at print.c:2150
The function print_vectorlike consists of two address ranges, one of
which contains "cold" code which is expected to not execute very often.
There is a minimal symbol, print_vectorlike.cold.65, which is the address
of the "cold" range.
GDB is prefering this minsym over the the name provided by the
DWARF info due to some really old code in GDB which handles
"certain pathological cases". This comment reads as follows:
/* In certain pathological cases, the symtabs give the wrong
function (when we are in the first function in a file which
is compiled without debugging symbols, the previous function
is compiled with debugging symbols, and the "foo.o" symbol
that is supposed to tell us where the file with debugging
symbols ends has been truncated by ar because it is longer
than 15 characters). This also occurs if the user uses asm()
to create a function but not stabs for it (in a file compiled
with -g).
So look in the minimal symbol tables as well, and if it comes
up with a larger address for the function use that instead.
I don't think this can ever cause any problems; there
shouldn't be any minimal symbols in the middle of a function;
if this is ever changed many parts of GDB will need to be
changed (and we'll create a find_pc_minimal_function or some
such). */
In an earlier version of this patch, I had left the code for the
pathological case intact, but those who reviwed that patch recommended
removing it. So that's what I've done - I've removed it.
gdb/ChangeLog:
* stack.c (find_frame_funname): Remove code which preferred
minsym over symtab sym in "certain pathological cases".
Simon Marchi