| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Currently "maint time" will print the amount of time a command took.
Sometimes, though, it's useful to have a timestamp as well -- for
example if one is correlating a gdb log with some other log.
This patch adds a timestamp to the start and end of each command when
this setting is in effect.
This also removes a "//" comment and changes scoped_command_stats to
use DISABLE_COPY_AND_ASSIGN; two minor things I noticed while working
on the patch.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-06-06 Tom Tromey <tromey@adacore.com>
* maint.h (class scoped_command_stats): Use
DISABLE_COPY_AND_ASSIGN.
<print_time>: New method.
* maint.c (scoped_command_stats, ~scoped_command_stats): Call
print_time.
(scoped_command_stats::print_time): New method.
gdb/testsuite/ChangeLog
2019-06-06 Tom Tromey <tromey@adacore.com>
* gdb.base/maint.exp: Expect command started/finished output.
|
|
Factorizes the testing of the help output, by having a single place
that defines the common help trailer and/or prefix messages.
|
|
gdb/testsuite/ChangeLog
2019-05-31 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/shell.exp: Test pipe command, $_shell_exitcode,
$_shell_exitsignal.
* gdb.base/default.exp: Update for new convenience variables.
|
|
A user wanted to be able to disable the display of the value when
using "finish" -- but still have the value entered into the value
history in case it was useful later on. Part of the rationale here is
that sometimes the value might be quite large, or expensive to display
(in their case this was compounded by a rogue pretty-printer).
This patch implements this idea.
gdb/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
* NEWS: Add entry.
* infcmd.c (print_return_value_1): Handle finish_print
option.
(show_print_finish): New function.
(_initialize_infcmd): Add "set/show print finish" commands.
* valprint.c (user_print_options): Initialize new member.
* valprint.h (struct value_print_options) <finish_print>: New
member.
gdb/doc/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Continuing and Stepping): Document new
commands.
gdb/testsuite/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
* gdb.base/finish.exp (finish_no_print): New proc.
(finish_tests): Call it.
|
|
This adds a "style" helper proc to the test suite, and updates
existing style tests to use it. Thanks to Sergio for the idea.
Tested on x86-64 Fedora 29.
gdb/testsuite/ChangeLog
2019-05-22 Tom Tromey <tromey@adacore.com>
* gdb.base/info-shared.exp (check_info_shared): Use "style".
* gdb.base/style.exp: Use "style".
* lib/gdb-utils.exp (style): New proc.
|
|
When building gdb on ubuntu 16.04 with gcc 5.4.0, and running the gdb
testsuite we run into a failure due align.exp requiring at least c++11.
Fix this by adding -std=c++11.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-22 Tom de Vries <tdevries@suse.de>
* gdb.base/align.exp: Require c++11.
|
|
When building gdb on ubuntu 16.04 with gcc 5.4.0, and running the gdb
testsuite we run into failures due test-cases requiring at least c++1.
Fix this by adding -std=c++11 to those test-cases.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-21 Tom de Vries <tdevries@suse.de>
* gdb.arch/amd64-eval.exp: Require c++11.
* gdb.base/max-depth.exp: Same.
* gdb.compile/compile-cplus-array-decay.exp: Same.
* gdb.cp/meth-typedefs.exp: Same.
* gdb.cp/subtypes.exp: Same.
* gdb.cp/temargs.exp: Same.
|
|
Fix up all failures encountered when running the testsuite with
GDB_DEBUG="infrun".
Some tests rely on enabling debugging for various components. With
debugging on, this will be lost to the debug file.
Disable separate tty for mi tests when debugging. This currently
does not work.
disasm.c should send errors to the stderr instead of the logfile.
Note that enabling debug for other components might still cause
additional errors above what has been fixed here.
gdb/ChangeLog:
* disasm.c (set_disassembler_options): Send errors to stderr.
gdb/testsuite/ChangeLog:
* gdb.base/breakpoint-in-ro-region.exp: Disable when debugging.
* gdb.base/debug-expr.exp: Likewise.
* gdb.base/foll-fork.exp: Likewise.
* gdb.base/foll-vfork.exp: Likewise.
* gdb.base/fork-print-inferior-events.exp: Likewise.
* gdb.base/gdb-sigterm.exp: Likewise.
* gdb.base/gdbinit-history.exp: Likewise.
* gdb.base/osabi.exp: Likewise.
* gdb.base/sss-bp-on-user-bp-2.exp: Likewise.
* gdb.base/ui-redirect.exp: Likewise.
* gdb.gdb/unittest.exp: Likewise.
* gdb.mi/mi-break.exp: Disable separate-mi-tty when debugging.
* gdb.mi/mi-watch.exp: Likewise.
* gdb.mi/new-ui-mi-sync.exp: Likewise.
* gdb.mi/user-selected-context-sync.exp: Likewise.
* gdb.python/python.exp: Disable debug test when debugging.
* gdb.threads/check-libthread-db.exp: Disable when debugging.
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
Likewise.
* gdb.threads/stepi-random-signal.exp: Likewise.
|
|
Currently, when logging is enabled, output will be sent to both a
logfile and standard terminal output. The redirect option sends output
only to the logfile. This includes all debug output.
Add the option to redirect debug output seperately to normal
output, using the cli command:
set logging debugredirect on
By setting this and enabling logging, all output and debug will
be sent to the logfile. The user will still see all output but
no debug output.
This causes a change in behaviour for anyone currently using
logging redirect, as now only output will be redirected. Users
will have to issue the additional command above to also redirect
debug.
Expand ui-redirect.exp cover the changes.
gdb/ChangeLog:
* cli/cli-interp.c (struct saved_output_files): Add saved entry.
(cli_interp_base::set_logging): Check debug_redirect.
* cli/cli-interp.h (set_logging): Add debug_redirect parameter.
* cli/cli-logging.c (debug_redirect): Add static variable.
(pop_output_files): Add default param.
(handle_redirections): Print debug setting.
(show_logging_command): Likewise.
(_initialize_cli_logging): Add debugredirect command.
* interps.c (current_interp_set_logging): Add debug_redirect
parameter.
* interps.h (set_logging): Add debug_redirect parameter.
(current_interp_set_logging): Likewise.
* mi/mi-common.h: Likewise.
* mi/mi-interp.c (mi_interp::set_logging): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/ui-redirect.exp: Add debug redirect tests.
|
|
Instead of using two bools to decide if the files should close when tee_file
is closed, make file one stay open and file two close. This simplifies the
use cases for it.
Inline the make_logging_output into the calling functions (the logic here
looks ugly in order to simplify a later change).
Expand ui-redirect.exp to cover the changes, similar to mi-logging.exp.
gdb/ChangeLog:
* cli/cli-interp.c (cli_interp_base::set_logging): Create tee_file
directly.
* cli/cli-interp.h (make_logging_output): Remove declaration.
* cli/cli-logging.c (make_logging_output): Remove function.
* mi/mi-interp.c (mi_interp::set_logging): Create tee_file
directly.
* ui-file.c (tee_file::tee_file): Remove bools.
(tee_file::~tee_file): Remove deletes.
* ui-file.h (tee_file): Remove bools.
gdb/testsuite/ChangeLog:
* gdb.base/ui-redirect.exp: Test redirection.
|
|
This changes "info sharedlibrary" to add styling to the file name.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-14 Tom Tromey <tromey@adacore.com>
* solib.c (info_sharedlibrary_command): Style the file name.
gdb/testsuite/ChangeLog
2019-05-14 Tom Tromey <tromey@adacore.com>
* gdb.base/info-shared.exp (check_info_shared): Add "info shared"
styling test.
|
|
Consider this short C example:
struct inner
{
unsigned x;
unsigned y : 3;
unsigned z : 3;
};
struct outer
{
unsigned char o : 3;
struct inner i __attribute__ ((packed));
};
When I use "ptype/o" on this, I get:
(gdb) ptype/o struct outer
/* offset | size */ type = struct outer {
/* 0: 5 | 1 */ unsigned char o : 3;
/* XXX 5-bit hole */
/* 1 | 8 */ struct inner {
/* 1 | 4 */ unsigned int x;
/* 5:29 | 4 */ unsigned int y : 3;
/* 5:26 | 4 */ unsigned int z : 3;
/* XXX 2-bit padding */
/* XXX 3-byte padding */
/* total size (bytes): 8 */
} i;
/* total size (bytes): 9 */
}
In the location of "o" ("0: 5"), the "5" means "there are 5 bits left
relative to the size of the underlying type.
I find this very difficult to follow. On irc, Sergio said that this
choice came because it is what pahole does. However, I think it's not
very useful, and maybe is just an artifact of the way that
DW_AT_bit_offset was defined in DWARF 3.
This patch changes ptype/o to print the offset of a bitfield in a more
natural way, that is, using the bit number according to the platform's
bit numbering.
With this patch, the output is now:
(gdb) ptype/o struct outer
/* offset | size */ type = struct outer {
/* 0: 0 | 1 */ unsigned char o : 3;
/* XXX 5-bit hole */
/* 1 | 8 */ struct inner {
/* 1 | 4 */ unsigned int x;
/* 5: 0 | 4 */ unsigned int y : 3;
/* 5: 3 | 4 */ unsigned int z : 3;
/* XXX 2-bit padding */
/* XXX 3-byte padding */
/* total size (bytes): 8 */
} i;
/* total size (bytes): 9 */
}
This is better, IMO, because now the "offset" of a bitfield is
consistent with the offset of an ordinary member, referring to its
offset from the start of the structure.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* typeprint.c (print_offset_data::update): Print the bit offset,
not the number of bits remaining.
gdb/doc/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Symbols): Document change to ptype/o.
gdb/testsuite/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* gdb.base/ptype-offsets.exp: Update tests.
|
|
I noticed that ptype/o will print:
/* 3: 3 | 1 */ signed char a4 : 2;
/* XXX 3-bit hole */
That is, "*/" at the end of the "hole" message does not line up with
the other comment ends. I thought it would be a bit nicer if this did
line up, so I fixed it. Then, to my surprise, I found that I could
not make ptype-offsets.exp fail.
I still am not sure why it doesn't fail, but changing the tests to use
string_to_regexp and changing the quoting helped. This in turn showed
that some of the existing test cases were wrong, so I've also updated
them here.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* typeprint.c (print_offset_data::maybe_print_hole): Add extra
padding at end of comment.
gdb/testsuite/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* gdb.base/ptype-offsets.exp: Use string_to_regexp. Fix test
cases.
* gdb.base/ptype-offsets.cc (struct abc) <my_int_type>: Now
"short".
|
|
When adding a debug print here in index-cache.exp:
...
proc_with_prefix test_cache_disabled { cache_dir } {
lassign [ls_host $cache_dir] ret files_before
+ puts "before: '$files_before'"
+ exit
...
we have:
...
files_before: ''
...
When further adding:
...
proc_with_prefix test_cache_disabled { cache_dir } {
+ exec touch $cache_dir/foo.1 $cache_dir/foo.2 $cache_dir/foo.3
...
we have:
...
files_before: 'foo.1'
...
while we're expecting file_before to contain foo.[123].
Fix this by making the return statement in ls_host return a list rather than a
string (in accordance with the ls_host documentation), after which we have:
...
files_before: 'foo.1 foo.2 foo.3'
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-07 Tom de Vries <tdevries@suse.de>
* gdb.base/index-cache.exp (ls_host): Fix return statement.
|
|
In gdb.base/index-cache.exp, handle the case that binfile contains either a
.gdb_index or .debug_names index section.
Tested on x86_64-linux with native, cc-with-gdb-index and cc-with-debug-names.
gdb/testsuite/ChangeLog:
2019-05-06 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (exec_has_index_section): New proc.
* gdb.base/index-cache.exp: Handle case that binfile contains an index
section.
|
|
Introduce a new print setting max-depth which can be set with 'set
print max-depth DEPTH'. The default value of DEPTH is 20, but this
can also be set to unlimited.
When GDB is printing a value containing nested structures GDB will
stop descending at depth DEPTH. Here is a small example:
typedef struct s1 { int a; } s1;
typedef struct s2 { s1 b; } s2;
typedef struct s3 { s2 c; } s3;
typedef struct s4 { s3 d; } s4;
s4 var = { { { { 3 } } } };
The following table shows how various depth settings affect printing
of 'var':
| Depth Setting | Result of 'p var' |
|---------------+--------------------------------|
| Unlimited | $1 = {d = {c = {b = {a = 3}}}} |
| 4 | $1 = {d = {c = {b = {a = 3}}}} |
| 3 | $1 = {d = {c = {b = {...}}}} |
| 2 | $1 = {d = {c = {...}}} |
| 1 | $1 = {d = {...}} |
| 0 | $1 = {...} |
Only structures, unions, and arrays are replaced in this way, scalars
and strings are not replaced.
The replacement is counted from the level at which you print, not from
the top level of the structure. So, consider the above example and
this GDB session:
(gdb) set print max-depth 2
(gdb) p var
$1 = {d = {c = {...}}}
(gdb) p var.d
$2 = {c = {b = {...}}}
(gdb) p var.d.c
$3 = {b = {a = 3}}
Setting the max-depth to 2 doesn't prevent the user from exploring
deeper into 'var' by asking for specific sub-fields to be printed.
The motivation behind this feature is to try and give the user more
control over how much is printed when examining large, complex data
structures.
The default max-depth of 20 means that there is a change in GDB's
default behaviour. Someone printing a data structure with 20 levels
of nesting will now see '{...}' instead of their data, they would need
to adjust the max depth, or call print again naming a specific field
in order to dig deeper into their data structure. If this is
considered a problem then we could increase the default, or even make
the default unlimited.
This commit relies on the previous commit, which added a new field to
the language structure, this new field was a string that contained the
pattern that should be used when a structure/union/array is replaced
in the output, this allows languages to use a syntax that is more
appropriate, mostly this will be selecting the correct types of
bracket '(...)' or '{...}', both of which are currently in use.
This commit should have no impact on MI output, expressions are
printed through the MI using -var-create and then -var-list-children.
As each use of -var-list-children only ever displays a single level of
an expression then the max-depth setting will have no impact.
This commit also adds the max-depth mechanism to the scripting
language pretty printers following basically the same rules as for the
built in value printing.
One quirk is that when printing a value using the display hint 'map',
if the keys of the map are structs then GDB will hide the keys one
depth level after it hides the values, this ensures that GDB produces
output like this:
$1 = map_object = {[{key1}] = {...}, [{key2}] = {...}}
Instead of this less helpful output:
$1 = map_object = {[{...}] = {...}, [{...}] = {...}}
This is covered by the new tests in gdb.python/py-nested-maps.exp.
gdb/ChangeLog:
* cp-valprint.c (cp_print_value_fields): Allow an additional level
of depth when printing anonymous structs or unions.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer):
Don't print either the top-level value, or the children if the
max-depth is exceeded.
(ppscm_print_children): When printing the key of a map, allow one
extra level of depth.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Don't
print either the top-level value, or the children if the max-depth
is exceeded.
(print_children): When printing the key of a map, allow one extra
level of depth.
* python/py-value.c (valpy_format_string): Add max_depth keyword.
* valprint.c: (PRINT_MAX_DEPTH_DEFAULT): Define.
(user_print_options): Initialise max_depth field.
(val_print_scalar_or_string_type_p): New function.
(val_print): Check to see if the max depth has been reached.
(val_print_check_max_depth): Define new function.
(show_print_max_depth): New function.
(_initialize_valprint): Add 'print max-depth' option.
* valprint.h (struct value_print_options) <max_depth>: New field.
(val_print_check_max_depth): Declare new function.
* NEWS: Document new feature.
gdb/doc/ChangeLog:
* gdb.texinfo (Print Settings): Document 'print max-depth'.
* guile.texi (Guile Pretty Printing API): Document that 'print
max-depth' can effect the display of a values children.
* python.texi (Pretty Printing API): Likewise.
(Values From Inferior): Document max_depth keyword.
gdb/testsuite/ChangeLog:
* gdb.base/max-depth.c: New file.
* gdb.base/max-depth.exp: New file.
* gdb.python/py-nested-maps.c: New file.
* gdb.python/py-nested-maps.exp: New file.
* gdb.python/py-nested-maps.py: New file.
* gdb.python/py-format-string.exp (test_max_depth): New proc.
(test_all_common): Call test_max_depth.
* gdb.fortran/max-depth.exp: New file.
* gdb.fortran/max-depth.f90: New file.
* gdb.go/max-depth.exp: New file.
* gdb.go/max-depth.go: New file.
* gdb.modula2/max-depth.exp: New file.
* gdb.modula2/max-depth.c: New file.
* lib/gdb.exp (get_print_expr_at_depths): New proc.
|
|
Inferior function calls are powerful but might lead to undesired
results such as crashes when calling nested functions (frequently
used in particular in Ada).
This implements a GDB setting to disable calling inferior functions.
Note: the idea is that if/when the 'slash command' patch is pushed,
that this setting can be changed e.g. by using the shortcut /c.
This is version 2 of the patch. It handles all the received comments,
mostly replace 'can-call' by 'may-call', and avoid using
'inferior function call' in factor of 'calling function in the program'.
2019-04-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
gdb/ChangeLog
* NEWS: Mention the new set|show may-call-functions.
* infcall.c (may_call_functions_p): New variable.
(show_may_call_functions_p): New function.
(call_function_by_hand_dummy): Throws an error if not
may-call-functions.
(_initialize_infcall): Call add_setshow_boolean_cmd for
may-call-functions.
gdb/testsuite/ChangeLog
* gdb.base/callexit.exp: Test may-call-functions off.
gdb/doc/ChangeLog
* gdb.texinfo (Calling): Document the new
set|show may-call-functions.
|
|
This patch has a long story, but it all started back in 2015, with
commit df8411da087dc05481926f4c4a82deabc5bc3859 ("Implement support
for checking /proc/PID/coredump_filter"). The purpose of that commit
was to bring GDB's corefile generation closer to what the Linux kernel
does. However, back then, I did not implement the full support for
the dumping of memory mappings containing ELF headers (like mappings
of DSOs or executables). These mappings were being dumped most of
time, though, because the default value of /proc/PID/coredump_filter
is 0x33, which would cause anonymous private mappings (DSOs/executable
code mappings have this type) to be dumped. Well, until something
happened on binutils...
A while ago, I noticed something strange was happening with one of our
local testcases on Fedora GDB: it was failing due to some strange
build-id problem. On Fedora GDB, we (unfortunately) carry a bunch of
"local" patches, and some of these patches actually extend upstream's
build-id support in order to generate more useful information for the
user of a Fedora system (for example, when the user loads a corefile
into GDB, we detect whether the executable that generated that
corefile is present, and if it's not we issue a warning suggesting
that it should be installed, while also providing the build-id of the
executable). A while ago, Fedora GDB stopped printing those warnings.
I wanted to investigate this right away, and spent some time trying to
determine what was going on, but other things happened and I got
sidetracked. Meanwhile, the bug started to be noticed by some of our
users, and its priority started changing. Then, someone on IRC also
mentioned the problem, and when I tried helping him, I noticed he
wasn't running Fedora. Hm... So maybe the bug was *also* present
upstream.
After "some" time investigating, and with a lot of help from Keith and
others, I was finally able to determine that yes, the bug is also
present upstream, and that even though it started with a change in ld,
it is indeed a GDB issue.
So, as I said, the problem started with binutils, more specifically
after the following commit was pushed:
commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Tue Feb 27 11:34:20 2018 -0800
ld: Add --enable-separate-code
This commit makes ld use "-z separate-code" by default on x86-64
machines. What this means is that code pages and data pages are now
separated in the binary, which is confusing GDB when it tries to decide
what to dump.
BTW, Fedora 28 binutils doesn't have this code, which means that
Fedora 28 GDB doesn't have the problem. From Fedora 29 on, binutils
was rebased and incorporated the commit above, which started causing
Fedora GDB to fail.
Anyway, the first thing I tried was to pass "-z max-page-size" and
specify a bigger page size (I saw a patch that did this and was
proposed to Linux, so I thought it might help). Obviously, this
didn't work, because the real "problem" is that ld will always use
separate pages for code and data. So I decided to look into how GDB
dumped the pages, and that's where I found the real issue.
What happens is that, because of "-z separate-code", the first two pages
of the ELF binary are (from /proc/PID/smaps):
00400000-00401000 r--p 00000000 fc:01 799548 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 4 kB
Private_Dirty: 0 kB
Referenced: 4 kB
Anonymous: 0 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd mr mw me dw sd
00401000-00402000 r-xp 00001000 fc:01 799548 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 4 kB
Referenced: 4 kB
Anonymous: 4 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd ex mr mw me dw sd
Whereas before, we had only one:
00400000-00401000 r-xp 00000000 fc:01 798593 /file
Size: 4 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Rss: 4 kB
Pss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 4 kB
Referenced: 4 kB
Anonymous: 4 kB
LazyFree: 0 kB
AnonHugePages: 0 kB
ShmemPmdMapped: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
Locked: 0 kB
THPeligible: 0
VmFlags: rd ex mr mw me dw sd
Notice how we have "Anonymous" data mapped into the page. This will be
important.
So, the way GDB decides which pages it should dump has been revamped
by my patch in 2015, and now it takes the contents of
/proc/PID/coredump_filter into account. The default value for Linux
is 0x33, which means:
Dump anonymous private, anonymous shared, ELF headers and HugeTLB
private pages.
Or:
filter_flags filterflags = (COREFILTER_ANON_PRIVATE
| COREFILTER_ANON_SHARED
| COREFILTER_ELF_HEADERS
| COREFILTER_HUGETLB_PRIVATE);
Now, it is important to keep in mind that GDB doesn't always have *all*
of the necessary information to exactly determine the type of a page, so
the whole algorithm is based on heuristics (you can take a look at
linux-tdep.c:dump_mapping_p and
linux-tdep.c:linux_find_memory_regions_full for more info).
Before the patch to make ld use "-z separate-code", the (single) page
containing data and code was being flagged as an anonymous (due to the
non-zero "Anonymous:" field) private (due to the "r-xp" permission),
which means that it was being dumped into the corefile. That's why it
was working fine.
Now, as you can imagine, when "-z separate-code" is used, the *data*
page (which is where the ELF notes are, including the build-id one) now
doesn't have any "Anonymous:" mapping, so the heuristic is flagging it
as file-backed private, which is *not* dumped by default.
The next question I had to answer was: how come a corefile generated by
the Linux kernel was correct? Well, the answer is that GDB, unlike
Linux, doesn't actually implement the COREFILTER_ELF_HEADERS support.
On Linux, even though the data page is also treated as a file-backed
private mapping, it is also checked to see if there are any ELF headers
in the page, and then, because we *do* have ELF headers there, it is
dumped.
So, after more time trying to think of ways to fix this, I was able to
implement an algorithm that reads the first few bytes of the memory
mapping being processed, and checks to see if the ELF magic code is
present. This is basically what Linux does as well, except that, if
it finds the ELF magic code, it just dumps one page to the corefile,
whereas GDB will dump the whole mapping. But I don't think that's a
big issue, to be honest.
It's also important to explain that we *only* perform the ELF magic
code check if:
- The algorithm has decided *not* to dump the mapping so far, and;
- The mapping is private, and;
- The mapping's offset is zero, and;
- The user has requested us to dump mappings with ELF headers.
IOW, we're not going to blindly check every mapping.
As for the testcase, I struggled even more trying to write it. Since
our build-id support on upstream GDB is not very extensive, it's not
really possible to determine whether a corefile contains build-id
information or not just by using GDB. So, after thinking a lot about
the problem, I decided to rely on an external tool, eu-unstrip, in
order to verify whether the dump was successful. I verified the test
here on my machine, and everything seems to work as expected (i.e., it
fails without the patch, and works with the patch applied). We are
working hard to upstream our "local" Fedora GDB patches, and we intend
to submit our build-id extension patches "soon", so hopefully we'll be
able to use GDB itself to perform this verification.
I built and regtested this on the BuildBot, and no problems were
found.
gdb/ChangeLog:
2019-04-25 Sergio Durigan Junior <sergiodj@redhat.com>
PR corefiles/11608
PR corefiles/18187
* linux-tdep.c (dump_mapping_p): Add new parameters ADDR and
OFFSET. Verify if current mapping contains an ELF header.
(linux_find_memory_regions_full): Adjust call to
dump_mapping_p.
gdb/testsuite/ChangeLog:
2019-04-25 Sergio Durigan Junior <sergiodj@redhat.com>
PR corefiles/11608
PR corefiles/18187
* gdb.base/coredump-filter-build-id.exp: New file.
|
|
On systems that use the probes-based solib interface, GDB misbehaves
if you run the "nosharelibrary" command, continue execution, and then
the program hits the shared library event breakpoint. On my system it
aborts like this:
(gdb) nosharedlibrary
(gdb) c
Continuing.
pure virtual method called
terminate called without an active exception
Aborted (core dumped)
Though it's really undefined behavior territory, caused by deferencing
a dangling solib event probe pointer.
I've observed this by running "nosharedlibrary" when stopped at the
entry point, but it should happen at any other point, if the program
does a dlopen/dlclose after.
The fix is to discard an objfile's probes from the svr4 probes table
when an objfile is about to be released.
New test included, works with both native and gdbserver testing.
Valgrind log:
(gdb) starti
(gdb) nosharedlibrary
(gdb) c
Continuing.
==24895== Invalid read of size 8
==24895== at 0x89E5FB: solib_event_probe_action(probe_and_action*) (solib-svr4.c:1735)
==24895== by 0x89E95A: svr4_handle_solib_event() (solib-svr4.c:1872)
==24895== by 0x8A7198: handle_solib_event() (solib.c:1274)
==24895== by 0x4E3407: bpstat_stop_status(address_space const*, unsigned long, thread_info*, target_waitstatus const*, bpstats*) (breakpoint.c:5407)
==24895== by 0x721F41: handle_signal_stop(execution_control_state*) (infrun.c:5685)
==24895== by 0x720B11: handle_inferior_event(execution_control_state*) (infrun.c:5129)
==24895== by 0x71DD93: fetch_inferior_event(void*) (infrun.c:3748)
==24895== by 0x7059C3: inferior_event_handler(inferior_event_type, void*) (inf-loop.c:43)
==24895== by 0x874DF0: remote_async_serial_handler(serial*, void*) (remote.c:14039)
==24895== by 0x894101: run_async_handler_and_reschedule(serial*) (ser-base.c:137)
==24895== by 0x8941E6: fd_event(int, void*) (ser-base.c:188)
==24895== by 0x67AFEF: handle_file_event(file_handler*, int) (event-loop.c:732)
==24895== Address 0x18b63860 is 0 bytes inside a block of size 136 free'd
==24895== at 0x4C2E616: operator delete(void*, unsigned long) (vg_replace_malloc.c:585)
==24895== by 0x8C6A12: stap_probe::~stap_probe() (stap-probe.c:124)
==24895== by 0x66F7DB: probe_key_free(bfd*, void*) (elfread.c:1382)
==24895== by 0x69B705: bfdregistry_callback_adaptor(void (*)(registry_container*, void*), registry_container*, void*) (gdb_bfd.c:131)
==24895== by 0x855A57: registry_clear_data(registry_data_registry*, void (*)(void (*)(registry_container*, void*), registry_container*, void*), registry_container*, registry_fields*) (registry.c:79)
==24895== by 0x855B01: registry_container_free_data(registry_data_registry*, void (*)(void (*)(registry_container*, void*), registry_container*, void*), registry_container*, registry_fields*) (registry.c:92)
==24895== by 0x69B783: bfd_free_data(bfd*) (gdb_bfd.c:131)
==24895== by 0x69C4BA: gdb_bfd_unref(bfd*) (gdb_bfd.c:609)
==24895== by 0x7CC33F: objfile::~objfile() (objfiles.c:651)
==24895== by 0x7CD559: objfile_purge_solibs() (objfiles.c:1021)
==24895== by 0x8A7132: no_shared_libraries(char const*, int) (solib.c:1252)
==24895== by 0x548E3D: do_const_cfunc(cmd_list_element*, char const*, int) (cli-decode.c:106)
==24895== Block was alloc'd at
==24895== at 0x4C2D42A: operator new(unsigned long) (vg_replace_malloc.c:334)
==24895== by 0x8C527C: handle_stap_probe(objfile*, sdt_note*, std::vector<probe*, std::allocator<probe*> >*, unsigned long) (stap-probe.c:1561)
==24895== by 0x8C5535: stap_static_probe_ops::get_probes(std::vector<probe*, std::allocator<probe*> >*, objfile*) const (stap-probe.c:1656)
==24895== by 0x66F71B: elf_get_probes(objfile*) (elfread.c:1365)
==24895== by 0x7EDD85: find_probes_in_objfile(objfile*, char const*, char const*) (probe.c:227)
==24895== by 0x4DF382: create_longjmp_master_breakpoint() (breakpoint.c:3275)
==24895== by 0x4F6562: breakpoint_re_set() (breakpoint.c:13828)
==24895== by 0x8A66AA: solib_add(char const*, int, int) (solib.c:1010)
==24895== by 0x89F7C6: enable_break(svr4_info*, int) (solib-svr4.c:2360)
==24895== by 0x8A104C: svr4_solib_create_inferior_hook(int) (solib-svr4.c:2992)
==24895== by 0x8A70B9: solib_create_inferior_hook(int) (solib.c:1215)
==24895== by 0x70C073: post_create_inferior(target_ops*, int) (infcmd.c:467)
==24895==
pure virtual method called
terminate called without an active exception
==24895==
==24895== Process terminating with default action of signal 6 (SIGABRT): dumping core
==24895== at 0x7CF3750: raise (raise.c:51)
==24895== by 0x7CF4D30: abort (abort.c:79)
==24895== by 0xB008F4: __gnu_cxx::__verbose_terminate_handler() (in build/gdb/gdb)
==24895== by 0xAFF845: __cxxabiv1::__terminate(void (*)()) (in build/gdb/gdb)
==24895== by 0xAFF890: std::terminate() (in build/gdb/gdb)
==24895== by 0xAFF95E: __cxa_pure_virtual (in build/gdb/gdb)
==24895== by 0x89E610: solib_event_probe_action(probe_and_action*) (solib-svr4.c:1735)
==24895== by 0x89E95A: svr4_handle_solib_event() (solib-svr4.c:1872)
==24895== by 0x8A7198: handle_solib_event() (solib.c:1274)
==24895== by 0x4E3407: bpstat_stop_status(address_space const*, unsigned long, thread_info*, target_waitstatus const*, bpstats*) (breakpoint.c:5407)
==24895== by 0x721F41: handle_signal_stop(execution_control_state*) (infrun.c:5685)
==24895== by 0x720B11: handle_inferior_event(execution_control_state*) (infrun.c:5129)
==24895==
Note, this little bit in the patch is just a cleanup that I noticed:
- lookup.prob = prob;
lookup.address = address;
That line isn't necessary because hashing/comparison only looks at the
address.
gdb/ChangeLog:
2019-04-22 Pedro Alves <palves@redhat.com>
* solib-svr4.c (svr4_free_objfile_observer): New.
(probe_and_action::objfile): New field.
(probes_table_htab_remove_objfile_probes)
(probes_table_remove_objfile_probes): New functions.
(register_solib_event_probe): Add 'objfile' parameter. Store it
in the new probe_and_action. Don't store the probe in 'lookup'.
(svr4_create_probe_breakpoints): Pass objfile to
register_solib_event_probe.
(_initialize_svr4_solib): Register a free_objfile observer.
gdb/testsuite/ChangeLog:
2019-04-22 Pedro Alves <palves@redhat.com>
* gdb.base/solib-probes-nosharedlibrary.c,
gdb.base/solib-probes-nosharedlibrary.exp: New files.
|
|
PR symtab/24423 points out that control characters in a source file
cause a hang in the "list" command, a regression introduced by the
styling changes.
This patch, from the PR, fixes the bug. I've included a minimal
change to the "list" test that exercises this code.
I recall that this bug was discussed on gdb-patches, and I thought
there was a patch there as well, but I was unable to find it.
gdb/ChangeLog
2019-04-19 Ilya Yu. Malakhov <malakhov@mcst.ru>
PR symtab/24423:
* source.c (print_source_lines_base): Advance "iter" when a
control character is seen.
gdb/testsuite/ChangeLog
2019-04-19 Tom Tromey <tromey@adacore.com>
PR symtab/24423:
* gdb.base/list0.h (foo): Add a control-l character.
|
|
The current code in gdbtypes.c:type_align incorrectly returns 0 as the
alignment for a structure containing only static fields. After this
patch the correct value of 1 is returned. The gdb.base/align.exp test
is extended to cover this case.
gdb/ChangeLog:
* gdbtypes.c (type_align): A struct with no non-static fields also
has alignment of 1.
gdb/testsuite/ChangeLog:
* gdb.base/align.exp: Extend test to cover structures containing
only static fields.
|
|
When using the "start" command, GDB puts a temporary breakpoint on the
"main" symbol (we literally invoke the tbreak command). However, since
it does wild matching by default, it also puts a breakpoint on any C++
method or "main" function in a namespace. For example, when debugging
GDB, it creates a total of 24 locations:
(gdb) start
Temporary breakpoint 1 at 0x198c1e9: main. (24 locations)
as there are a bunch of methods called main in the selftests, such as
selftests::string_view::capacity_1::main()
If such method was called in the constructor of a global object, or a
function marked with the attribute "constructor", then we would stop at
the wrong place. Also, this causes a few extra symtabs (those that
contain the "wrong" mains) to be expanded for nothing.
The dummiest, most straightforward solution is to add -qualified when
invoking tbreak. With this patch, "start" creates a single-location
breakpoint, as expected.
I copied the start.exp test to start-cpp.exp and made it use a C++ test
file, which contains two main functions. The new test verifies that the
output of "start" is the output we get when we set a single-location
breakpoint.
gdb/ChangeLog:
* infcmd.c (run_command_1): Pass -qualified to tbreak when usind
the "start" command.
gdb/testsuite/ChangeLog:
* gdb.base/start-cpp.exp: New file.
* gdb.base/start-cpp.cc: New file.
|
|
Add two new internal functions $_cimag and $_creal that extract the
imaginary and real parts of a complex value.
These internal functions can take a complex value of any type 'float
complex', 'double complex', or 'long double complex' and return a
suitable floating point value 'float', 'double', or 'long double'.
So we can now do this:
(gdb) p z1
$1 = 1.5 + 4.5 * I
(gdb) p $_cimag (z1)
$4 = 4.5
(gdb) p $_creal (z1)
$4 = 1.5
The components of a complex value are not strictly named types in
DWARF, as the complex type is itself the base type. However, once we
are able to extract the components it makes sense to be able to ask
what the type of these components is and get a sensible answer back,
rather than the error we would currently get. Currently GDB says:
(gdb) ptype z1
type = complex double
(gdb) p $_cimag (z1)
$4 = 4.5
(gdb) ptype $
type = <invalid type code 9>
With the changes in dwarf2read.c, GDB now says:
(gdb) ptype z1
type = complex double
(gdb) p $_cimag (z1)
$4 = 4.5
(gdb) ptype $
type = double
Which seems to make more sense.
gdb/ChangeLog:
* NEWS: Mention new internal functions.
* dwarf2read.c (dwarf2_init_complex_target_type): New function.
(read_base_type): Use dwarf2_init_complex_target_type.
* value.c (creal_internal_fn): New function.
(cimag_internal_fn): New function.
(_initialize_values): Register new internal functions.
gdb/doc/ChangeLog:
* gdb.texinfo (Convenience Funs): Document '$_creal' and
'$_cimag'.
gdb/testsuite/ChangeLog:
* gdb.base/complex-parts.c: New file.
* gdb.base/complex-parts.exp: New file.
|
|
gdb/ChangeLog:
2019-03-30 Eli Zaretskii <eliz@gnu.org>
* NEWS: Announce $_gdb_major and $_gdb_minor.
* top.c (init_gdb_version_vars): New function.
(gdb_init): Call init_gdb_version_vars.
gdb/testsuite/ChangeLog:
2019-03-30 Simon Marchi <simark@simark.ca>
* gdb.base/default.exp: Add values for $_gdb_major and
$_gdb_minor.
gdb/doc/ChangeLog:
2019-03-30 Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Convenience Vars): Document $_gdb_major and
$_gdb_minor.
|
|
I noticed that the help for "info addr" did not include a "usage"
line; and when adding it I went through and fixed a few minor issues
in printcmd.c:
* Added usage lines to all commands
* Updated the help text for some commands
* Changed some help to use upper case metasyntactic variables
* Removed some dead code
Regression tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-03-29 Tom Tromey <tromey@adacore.com>
* printcmd.c (_initialize_printcmd): Add usage lines. Update some
help text. Remove dead code.
gdb/testsuite/ChangeLog
2019-03-29 Tom Tromey <tromey@adacore.com>
* gdb.base/help.exp: Tighten apropos regexp.
|
|
Looking at the AArch64 buildbot, I noticed about two dozen old instances of
interrupt-daemon-attach taking up a full 100% cpu each.
If the test fails then the test binary relies on an alarm to ensure it dies
after 60 seconds.
As per the Linux man page for alarm:
Alarms created by alarm() ... are not inherited by children created via fork.
Update the test to add an alarm in the child and also put a sleep in the
child loop so it does not constantly consume cpu.
Note I haven't managed to re-create why the test failed. This fix will just
stop it hanging and consuming cpu when it does.
gdb/testsuite/ChangeLog:
* gdb.base/interrupt-daemon-attach.c (main): Add alarm and sleep
in child.
|
|
While writing a new test for 'set print pretty on' I spotted that GDB
will sometimes add a trailing whitespace character when pretty
printing. This commit removes the trailing whitespace and updates the
expected results in one tests where this was an issue.
I've added an extra test for 'set print pretty on' as it doesn't seem
to have much testing.
gdb/ChangeLog:
* cp-valprint.c (cp_print_value_fields): Don't print trailing
whitespace when pretty printing is on.
gdb/testsuite/ChangeLog:
* gdb.base/finish-pretty.exp: Update expected results.
* gdb.base/pretty-print.c: New file.
* gdb.base/pretty-print.exp: New file.
|
|
Recent versions of Ubuntu and Debian default GCC to enable pie.
In dump.exp, pie will causes addresses to be out of range for IHEX.
In break-interp.exp, pie is explicitly set for some tests and assumed
to be disabled for the remainder.
Ensure pie is disabled for these tests when required.
In addition, add a pie option to gdb_compile to match the nopie option
and simplify use.
gdb/testsuite/ChangeLog:
* README: Add pie options.
* gdb.base/break-interp.exp: Ensure pie is disabled.
* gdb.base/dump.exp: Likewise.
* lib/gdb.exp (gdb_compile): Add pie option.
|
|
This adds "set style source" (and "show style source") commands. This
gives the user control over whether source code is highlighted.
gdb/ChangeLog
2019-03-14 Tom Tromey <tromey@adacore.com>
* NEWS: Add item for "style sources" commands.
* source-cache.c (source_cache::get_source_lines): Check
source_styling.
* cli/cli-style.c (source_styling): New global.
(_initialize_cli_style): Add "style sources" commands.
(show_style_sources): New function.
* cli/cli-style.h (source_styling): Declare.
gdb/doc/ChangeLog
2019-03-14 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Output Styling): Document "set style source" and
"show style source".
gdb/testsuite/ChangeLog
2019-03-14 Tom Tromey <tromey@adacore.com>
* gdb.base/style.exp: Add "set style sources" test.
|
|
Changes in DejaGnu 1.6.2 mean that our testsuite will no longer run.
This is because of some confusion over how the gdb.exp file is
handled.
The gdb.exp file is really the tool init file, which is loaded from
within the DejaGnu core, and it should not be loaded directly from any
other file in the testsuite.
DejaGnu tries to prevent the same library being loaded twice by
remembering the names of library files as they are loaded. Until
recently loading the tool init file in DejaGnu was very similar to
loading a library file, as a result, loading the gdb.exp tool init
file simply recorded 'gdb.exp' as having been loaded, future attempts
to load 'gdb.exp' as a library would then be ignored (as the file was
marked as already loaded).
DejaGnu has now changed so that it supports having both a tool init
file and a library with the same name, something that was not possible
before. What this means however is that when the core loads the
'gdb.exp' tool init file it no longer marks the library 'gdb.exp' as
having been loaded. When we then execute 'load_lib gdb.exp' we then
try to reload the 'gdb.exp' file.
Unfortunately our gdb.exp file can only be loaded once. It use of
'rename cd builtin_cd' means that a second attempt to load this file
will fail.
This was discussed on the DejaGnu list here:
http://lists.gnu.org/archive/html/dejagnu/2019-03/msg00000.html
and the suggested advice is that, unless we have some real requirement
to load the tool init file twice, we should remove calls to 'load_lib
gdb.exp' and rely on DejaGnu to load the file for us, which is what
this patch does.
I've tested with native X86-64/GNU Linux and see no regressions.
gdb/testsuite/ChangeLog:
* config/default.exp: Remove 'load_lib gdb.exp'.
* config/monitor.exp: Likewise.
* config/sid.exp: Likewise.
* config/sim.exp: Likewise.
* config/slite.exp: Likewise.
* config/unix.exp: Likewise.
* gdb.base/default.exp: Remove unhelpful comment.
|
|
If gdb attaches to a process that either has no controlling terminal,
or the controlling terminal differs from the one gdb is running under,
break/^C doesn't interrupt the debugged process on Solaris.
Fixed as follows, analogous to what all all other targets do. Patch from
the PR, recently re-submitted by Brian Vandenberg.
Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11, and
x86_64-pc-linux-gnu.
2019-02-28 Brian Vandenberg <phantall@gmail.com>
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gdb:
PR gdb/8527
* procfs.c (proc_wait_for_stop): Wrap write of PCWSTOP in
set_sigint_trap, clear_sigint_trap.
gdb/testsuite:
PR gdb/8527
* gdb.base/interrupt-daemon-attach.c,
gdb.base/interrupt-daemon-attach.exp: New test.
|
|
As a follow up to the previous commit, add a test for "set
width/height -1", to make sure we don't overflow in readline with
negative values either.
gdb/testsuite/ChangeLog:
2019-02-27 Pedro Alves <palves@redhat.com>
* gdb.base/page.exp: Add tests for "set width/height -1".
|
|
When we cap the height/width sizes before passing to readline, tweak
the corresponding command variable to show "unlimited":
(gdb) set height 0x8000
(gdb) show height
Number of lines gdb thinks are in a page is unlimited.
Instead of the current output:
(gdb) set height 0x8000
(gdb) show height
Number of lines gdb thinks are in a page is 32768.
gdb/ChangeLog:
2019-02-27 Pedro Alves <palves@redhat.com>
* utils.c (set_screen_size): When we cap the height/width sizes,
tweak the corresponding command variable to show "unlimited":
gdb/testsuite/ChangeLog:
2019-02-27 Pedro Alves <palves@redhat.com>
* gdb.base/page.exp: Add tests for "set/show width/height" with
"infinite" values.
|
|
In 'type_align' when computing the alignment of a structure we should
not consider the alignment of static structure members, these are
usually stored outside of the structure and therefore don't have any
impact on the structures alignment requirements.
I've extended the existing alignment calculating test to compile in
both C and C++ now so that we can create structures with static
members.
gdb/ChangeLog:
* gdbtypes.c (type_align): Don't consider static members when
computing structure alignment.
gdb/testsuite/ChangeLog:
* gdb.base/align.exp: Extend to compile in both C and C++, and add
tests for structs with static members.
|
|
This patch attempts to fix a bug dealing with setting breakpoints
in default symtabs that are symlinks. For example:
(gdb) list
11 GNU General Public License for more details.
12
13 You should have received a copy of the GNU General Public License
14 along with this program. If not, see <http://www.gnu.org/licenses/>. */
15
16 static int
17 foo (void)
18 {
19 return 0; /* break here */
20 }
(gdb)
21
22 int
23 main (void)
24 {
25 return foo ();
26 }
(gdb) b 19
No line 19 in the current file.
Make breakpoint pending on future shared library load? (y or [n])
The problem here is that when create_sals_line_offset sets the default
symtab, it immediately calls symtab_to_fullname, passing that fullname
to collect_symtabs_from_filename to find all matching symtabs. This
fails because we end up looking for a symtab with the name of the
actual file on disk (which is different in this case because of the
symlink) instead of the one stored in the debug info.
Since we already have the lookup name of the default symtab, use it
instead of the fullname. [This fullname thing was originally added
in 2007 in a series dealing with *displaying* absolute file names.
Clearly, this instance has nothing to do with the display of file names.]
gdb/ChangeLog
PR symtab/23853
* linespec.c (create_sals_line_offset): Search for the default
symtab's filename instead of its fullname.
gdb/testsuite/ChangeLog
PR symtab/23853
* gdb.base/symlink-sourcefile.c: New file.
* gdb.base/symlink-sourcefile.exp: New file.
|
|
symtab_symbol_info has a couple of messages that say "regulation
expression". I think "regular expression" was meant, so this patch
changes it.
gdb/ChangeLog
2019-02-20 Tom Tromey <tom@tromey.com>
* symtab.c (symtab_symbol_info): Fix typos.
gdb/testsuite/ChangeLog
2019-02-20 Tom Tromey <tom@tromey.com>
* gdb.base/info_qt.exp: Update.
|
|
Errors that happen in nested sourced files (when a sourced file sources
another file) lead to a wrong error message, or use-after-free.
For example, if I put this in "a.gdb":
command_that_doesnt_exist
and this in "b.gdb":
source a.gdb
and try to "source b.gdb" in GDB, the result may look like this:
(gdb) source b.gdb
b.gdb:1: Error in sourced command file:
_that_doesnt_exist:1: Error in sourced command file:
Undefined command: "command_that_doesnt_exist". Try "help".
Notice the wrong file name where "a.gdb" should be. The exact result
may differ, depending on the feelings of the memory allocator.
What happens is:
- The "source a.gdb" command is saved by command_line_append_input_line
in command_line_input's static buffer.
- Since we are sourcing a file, the script_from_file function stores the
script name (a.gdb) in the source_file_name global. However, it doesn't
do a copy, it just saves a pointer to command_line_input's static buffer.
- The "command_that_doesnt_exist" command is saved by
command_line_append_input_line in command_line_input's static buffer.
Depending on what xrealloc does, source_file_name may now point to
freed memory, or at the minimum the data it was pointing to was
overwritten.
- When the error is handled in script_from_file, we dererence
source_file_name to print the name of the file in which the error
occured.
To fix it, I made source_file_name an std::string, so that keeps a copy of
the file name instead of pointing to a buffer with a too small
lifetime.
With this patch, the expected filename is printed, and no use-after-free
occurs:
(gdb) source b.gdb
b.gdb:1: Error in sourced command file:
a.gdb:1: Error in sourced command file:
Undefined command: "command_that_doesnt_exist". Try "help".
I passed explicit template parameters to make_scoped_restore
(<std::string, const std::string &>), so that the second parameter is
passed by reference and avoid a copy.
It was not as obvious as I first thought to change gdb.base/source.exp
to test this, because source commands inside sourced files are
interpreted relative to GDB's current working directory, not the
directory of the currently sourced file. As a workaround, I moved the
snippet that tests errors after the snippet that adds the source
directory to the search path. This way, the "source source-error-1.gdb"
line in source-error.exp manages to find the file.
For reference, here is what ASAN reports when use-after-free occurs:
(gdb) source b.gdb
=================================================================
==18498==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000019847 at pc 0x7f1d3645de8e bp 0x7ffdcb892e50 sp 0x7ffdcb8925c8
READ of size 6 at 0x60c000019847 thread T0
#0 0x7f1d3645de8d in printf_common /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:546
#1 0x7f1d36477175 in __interceptor_vasprintf /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1525
#2 0x5632eaffa277 in xstrvprintf(char const*, __va_list_tag*) /home/simark/src/binutils-gdb/gdb/common/common-utils.c:122
#3 0x5632eaff96d1 in throw_it /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:351
#4 0x5632eaff98df in throw_verror(errors, char const*, __va_list_tag*) /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:379
#5 0x5632eaff9a2a in throw_error(errors, char const*, ...) /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:394
#6 0x5632eafca21a in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1553
#7 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
#8 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
#9 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
#10 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
#11 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
#12 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
#13 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
#14 0x5632ebf3cf09 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:425
#15 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
#16 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
#17 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
#18 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
#19 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
#20 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
#21 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
#22 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
#23 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770
#24 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213
#25 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220
#26 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175
#27 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192
#28 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511
#29 0x5632eb3aa6a9 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
#30 0x5632eb3aaf41 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
#31 0x5632eb3a88ea in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:347
#32 0x5632eb3a89bf in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
#33 0x5632eb76fbfc in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:330
#34 0x5632eb772ea8 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1176
#35 0x5632eb773071 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1192
#36 0x5632eabfe7f9 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
#37 0x7f1d3554f222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
#38 0x5632eabfe5dd in _start (/home/simark/build/binutils-gdb/gdb/gdb+0x195d5dd)
0x60c000019847 is located 7 bytes inside of 128-byte region [0x60c000019840,0x60c0000198c0)
freed by thread T0 here:
#0 0x7f1d36502491 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:105
#1 0x5632eaff9f47 in xrealloc /home/simark/src/binutils-gdb/gdb/common/common-utils.c:62
#2 0x5632eaff6b44 in buffer_grow(buffer*, char const*, unsigned long) /home/simark/src/binutils-gdb/gdb/common/buffer.c:40
#3 0x5632eb3b271d in command_line_append_input_line /home/simark/src/binutils-gdb/gdb/event-top.c:614
#4 0x5632eb3b28c6 in handle_line_of_input(buffer*, char const*, int, char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:654
#5 0x5632ebf402a6 in command_line_input(char const*, char const*) /home/simark/src/binutils-gdb/gdb/top.c:1252
#6 0x5632ebf3cee9 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:422
#7 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
#8 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
#9 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
#10 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
#11 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
#12 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
#13 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
#14 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
#15 0x5632ebf3cf09 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:425
#16 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
#17 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
#18 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
#19 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
#20 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
#21 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
#22 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
#23 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
#24 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770
#25 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213
#26 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220
#27 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175
#28 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192
#29 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511
previously allocated by thread T0 here:
#0 0x7f1d36502491 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:105
#1 0x5632eaff9f47 in xrealloc /home/simark/src/binutils-gdb/gdb/common/common-utils.c:62
#2 0x5632eaff6b44 in buffer_grow(buffer*, char const*, unsigned long) /home/simark/src/binutils-gdb/gdb/common/buffer.c:40
#3 0x5632eb3b271d in command_line_append_input_line /home/simark/src/binutils-gdb/gdb/event-top.c:614
#4 0x5632eb3b28c6 in handle_line_of_input(buffer*, char const*, int, char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:654
#5 0x5632ebf402a6 in command_line_input(char const*, char const*) /home/simark/src/binutils-gdb/gdb/top.c:1252
#6 0x5632ebf3cee9 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:422
#7 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
#8 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
#9 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
#10 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
#11 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
#12 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
#13 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
#14 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
#15 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770
#16 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213
#17 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220
#18 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175
#19 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192
#20 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511
#21 0x5632eb3aa6a9 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
#22 0x5632eb3aaf41 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
#23 0x5632eb3a88ea in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:347
#24 0x5632eb3a89bf in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
#25 0x5632eb76fbfc in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:330
#26 0x5632eb772ea8 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1176
#27 0x5632eb773071 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1192
#28 0x5632eabfe7f9 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
#29 0x7f1d3554f222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
SUMMARY: AddressSanitizer: heap-use-after-free /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:546 in printf_common
gdb/ChangeLog:
* top.h (source_file_name): Change to std::string.
* top.c (source_file_name): Likewise.
(command_line_input): Adjust.
* cli/cli-script.c (script_from_file): Adjust.
gdb/testsuite/ChangeLog:
* gdb.base/source.exp: Move "error in sourced script" code to
the end.
* gdb.base/source-error.gdb: Move contents to
source-error-1.gdb. Add new code to source source-error-1.gdb.
* gdb.base/source-error-1.gdb: New file, from previous
source-error.gdb.
|
|
This adds filename styling to "info macro".
gdb/ChangeLog
2019-02-17 Tom Tromey <tom@tromey.com>
* macrocmd.c (show_pp_source_pos): Style the file names.
gdb/testsuite/ChangeLog
2019-02-17 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Use -g3 to compile when possible. Add test
for macro styling.
* gdb.base/style.c (SOME_MACRO): New macro.
|
|
I believe this fixes all the pager output problems with styling that
Philippe pointed out, plus at least one more. The patch is somewhat
hard to reason about, so you may wish to give it a try. Even writing
the tests was hard.
This removes the style caching, because it was difficult to keep the
style cache correct in all cases. Since this would cause more style
escapes to be emitted, instead it changes fputs_styled to try to avoid
unnecessary changes.
Another bug was that the wrap buffer was not flushed in the case where
wrap_column==0. In the old (pre-patch series) code, characters were
directly emitted in this case; so flushing the wrap buffer here
restores this behavior.
On error the wrap buffer must be emptied. Otherwise, interrupting
output can leave characters in the buffer that will be emitted later.
As discussed on gdb-patches, this fixes the ada-lang.c problem where
filtered and unfiltered printing were mixed. Now user_select_syms
uses filtered printing, which is what its callees were already doing.
Finally, it was possible for source line highlighting to be garbled
(and invalid escape sequences emitted) if the pager was invoked at the
wrong spot. To fix this, the patch arranges for source line escapes
to always be emitted as a unit.
gdb/ChangeLog
2019-02-17 Tom Tromey <tom@tromey.com>
* ada-lang.c (user_select_syms): Use filtered printing.
* utils.c (wrap_style): New global.
(desired_style): Remove.
(emit_style_escape): Add stream parameter.
(set_output_style, reset_terminal_style, prompt_for_continue):
Update.
(flush_wrap_buffer): Only flush gdb_stdout.
(wrap_here): Set wrap_style.
(fputs_maybe_filtered): Clear the wrap buffer on exception. Don't
treat escape sequences as a character. Change when wrap buffer is
flushed.
(fputs_styled): Do not set the output style when the default is
requested.
* ui-style.h (struct ui_file_style) <is_default>: New method.
* source.c (print_source_lines_base): Emit escape sequences in one
piece.
gdb/testsuite/ChangeLog
2019-02-17 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Add line-wrapping tests.
* gdb.base/page.exp: Add test for quitting during pagination.
|
|
The recent BP/WP changes for AArch64 swapping the order in add_lwp()
so that the process was added before the lwp. This was due to the lwp
creation requiring the process data.
This also needs changing in linux_attach().
Also add additional checks to make sure cannot attach to the same
process twice. Add test case for this - do this by splitting
attach.exp into distinct pass and error case sections.
Fixes gdb.server/ext-attach.exp on Aarch64.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_attach): Add process before lwp.
* server.c (attach_inferior): Check if already attached.
gdb/testsuite/ChangeLog:
* gdb.base/attach.exp: Add double attach test.
|
|
Static members in C++ structs are global data and therefore not part of the
list of struct members considered for passing in registers.
Note the corresponding code in GCC (from which the GDB AAPCS code is based)
does not have any static member checks due to the static members not being
part of the struct type at that point.
Extend gdb.base/infcall-nested-structs.exp to test structs with static
members when compiled for C++. XFAIL more cases for x86_64 (see gdb/24104).
For completeness, ensure some test cases have both empty structures and
static members.
Also fixes gdb.dwarf2/dw2-cp-infcall-ref-static.exp.
gdb/ChangeLog:
* aarch64-tdep.c (aapcs_is_vfp_call_or_return_candidate_1): Check
for static members.
(pass_in_v_vfp_candidate): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/infcall-nested-structs.c (struct struct_static_02_01):
New structure.
(struct struct_static_02_02): Likewise.
(struct struct_static_02_03): Likewise.
(struct struct_static_02_04): Likewise.
(struct struct_static_04_01): Likewise.
(struct struct_static_04_02): Likewise.
(struct struct_static_04_03): Likewise.
(struct struct_static_04_04): Likewise.
(struct struct_static_06_01): Likewise.
(struct struct_static_06_02): Likewise.
(struct struct_static_06_03): Likewise.
(struct struct_static_06_04): Likewise.
(cmp_struct_static_02_01): Likewise.
(cmp_struct_static_02_02): Likewise.
(cmp_struct_static_02_03): Likewise.
(cmp_struct_static_02_04): Likewise.
(cmp_struct_static_04_01): Likewise.
(cmp_struct_static_04_02): Likewise.
(cmp_struct_static_04_03): Likewise.
(cmp_struct_static_04_04): Likewise.
(cmp_struct_static_06_01): Likewise.
(cmp_struct_static_06_02): Likewise.
(cmp_struct_static_06_03): Likewise.
(cmp_struct_static_06_04): Likewise.
(call_all): Test new structs.
* gdb.base/infcall-nested-structs.exp: Likewise.
|
|
When gdb.base/infcall-nested-structs.c is complied as C++, the compiler
will not pass structs containing empty structs via float arguments.
This is because structs in C++ have a minimum size of 1, causing padding
in the struct once compiled. The AAPCS does not allow structs with
padding to be passed in float arguments.
Add padding checks to AArch64 and add C++ compile variant to the test.
Some of the tests fail on X86_64. This has been raised as bug gdb/24104.
gdb/ChangeLog:
* aarch64-tdep.c (aapcs_is_vfp_call_or_return_candidate_1): Check
for padding.
gdb/testsuite/ChangeLog:
* gdb.base/infcall-nested-structs.exp: Test C++ in addition to C.
|
|
Using -fstack-protector-strong will cause GDB to break on the wrong line
when placing a breakpoint on a function. This is due to inadequate dwarf
line numbering, and is being tracked by the GCC bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
GCC (and Clang) provided by Debian/Ubuntu default to stack protector
being enabled.
Ensure that when running the GDB testsuite, stack protector is always
turned off for GCC 4.1.0 (when stack protector was added) and above.
Ensure that this does not cause infinite recursion due to
test_compiler_info having to compile a file itself.
Add a test to explicitly test breakpoints with various levels of stack
protection on both GCC and Clang, with xfail for the known errors.
Restore change in ovldbreak.exp which worked around the issue.
gdb/testsuite/ChangeLog:
2019-01-18 Alan Hayward <alan.hayward@arm.com>
* gdb.base/stack-protector.c: New test.
* gdb.base/stack-protector.exp: New file.
* gdb.cp/ovldbreak.exp: Only allow a single break line.
* lib/gdb.exp (get_compiler_info): Use getting_compiler_info
option.
(gdb_compile): Remove stack protector for GCC and prevent
recursion.
|
|
Having paths in the test names makes it harder to compare results
between two runs in different directories. Give the test a name so
that the path doesn't appear.
gdb/ChangeLog:
* gdb.base/style.exp: Don't include path in testname.
|
|
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
A user at Mozilla pointed out a crash in jit.c. In his situation, an
inferior using the JIT API exec'd an executable that did not use it.
This caused an assertion failure when jit.c:free_objfile_data called
delete_breakpoint with NULL.
This patch fixes the problem in the obvious way. New test case
included.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* jit.c (free_objfile_data): Only delete breakpoint if non-null.
gdb/testsuite/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
Simon Marchi <simark@simark.ca>
* gdb.base/jit-exec.exp: New file.
* gdb.base/jit-exec.c: New file.
* gdb.base/jit-execd.c: New file.
|
|
This changes gdb to style addresses.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* ui-out.h (enum class ui_out_style_kind) <ADDRESS>: New
constant.
* ui-out.c (ui_out::field_core_addr): Add styling.
* stack.c (print_frame): Add styling.
* printcmd.c (print_address): Add styling.
(print_address_demangle, info_address_command): Likewise.
* cli/cli-style.h (address_style): Declare.
* cli/cli-style.c (address_style): New global.
(_initialize_cli_style): Register new commands.
* cli-out.c (cli_ui_out::do_field_string): Update.
gdb/testsuite/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Update test to check for address styling.
|
|
The "Reading symbols" message does not use ui-out (perhaps it
should?), so this styles it using the low-level API.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* symfile.c (symbol_file_add_with_addrs): Style file name.
gdb/testsuite/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Add test for styling of "Reading symbols"
message.
|
|
This changes gdb to style the welcome message that is shown by
default. The styling is only done interactively.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* top.c (print_gdb_version): Style gdb version number.
gdb/testsuite/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Add test for version number styling.
|
|
print_address_symbolic does not use ui-out, so it did not style
function names. This patch changes it to use the low-level style code
directly.
gdb/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* printcmd.c (print_address_symbolic): Style function name.
gdb/testsuite/ChangeLog
2018-12-28 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Add test for print_address_symbolic.
|
