| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
I noticed that an early return in a foreach_with_prefix block does not
cause the outer scope to return, like:
foreach_with_prefix var {"foo" "bar"} {
return
}
# Control continues here, but it should not.
The problem is that we're missing the usual "return -code" treatment.
This commit fixes it.
gdb/testsuite/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (foreach_with_prefix): Use "catch" and
"return -code".
|
|
This commit adds a completer for the "pipe" command. It can complete
"pipe"'s options, and the specified GDB command.
To make the completer aware of the "-d" option, this converts the
option processing to use gdb::option.
Tests included.
gdb/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
PR cli/24732
* cli/cli-cmds.c (struct pipe_cmd_opts): New.
(pipe_cmd_option_defs): New.
(make_pipe_cmd_options_def_group): New.
(pipe_command): Use gdb::option::process_options.
(pipe_command_completer): New function.
(_initialize_cli_cmds): Install completer for "pipe" command.
gdb/testsuite/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
PR cli/24732
* gdb.base/shell.exp: Load completion-support.exp.
Adjust expected error output. Add completion tests.
|
|
A following patch will add the following to a testcase:
test_gdb_completion_offers_commands "| "
And that tripped on a latent testsuite bug:
(gdb) | PASS: gdb.base/shell.exp: tab complete "| "
^CQuit
(gdb) complete |
| !
| +
PASS: gdb.base/shell.exp: cmd complete "| "
| *** List may be truncated, max-completions reached. ***
(gdb) FAIL: gdb.base/shell.exp: set max-completions 200
set max-completions 200
The issue is that "|" ends up as part of a regexp, and "|" in regexps
has a special meaning...
Fix this with string_to_regexp.
gdb/testsuite/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* lib/completion-support.exp (test_gdb_complete_cmd_multiple): Use
string_to_regexp.
|
|
A following patch will make the "pipe" command use the gdb::option
framework for option processing. However, "pipe"'s only option today
is a string option, "-d DELIM", and gdb::option does not support
string options yet.
This commit adds support for string options, mapped to var_string.
For now, a string is parsed up until the first whitespace. I imagine
that we'll need to add support for quoting so that we could do:
(gdb) cmd -option 'some -string'
without gdb confusing the "-string" for an option.
This doesn't seem important for pipe, so I'm leaving it for another
day.
One thing I'm not happy with, is that the string data is managed as a
raw malloc-allocated char *, which means that we need to xfree it
manually. This is because var_string settings work that way too.
Although with var_string settings we're leaking the strings at gdb
exit, that was never really a problem. For options though, leaking is
undesirable.
I think we should tackle that for both settings and options at the
same time, so for now I'm just managing the malloced data manually.
It's a bit ugly in option_def_and_value, but at least that's hidden
from view.
For testing, this adds a new "-string" option to "maint
test-settings", and then tweaks gdb.base/options.exp to exercise it.
gdb/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* cli/cli-option.c (union option_value) <string>: New field.
(struct option_def_and_value): Add ctor, move ctor, dtor and
use DISABLE_COPY_AND_ASSIGN.
(option_def_and_value::clear_value): New.
(parse_option, save_option_value_in_ctx, get_val_type_str)
(add_setshow_cmds_for_options): Handle var_string.
* cli-option.h (union option_def::var_address) <string>: New
field.
(struct string_option_def): New.
* maint-test-options.c (struct test_options_opts): Add default
ctor and use DISABLE_COPY_AND_ASSIGN.
<string_opt>: New field.
(test_options_opts::~test_options_opts): New.
(test_options_opts::dump): Also dump "-string".
(test_options_option_defs): Install "string.
gdb/testsuite/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* gdb.base/options.exp (expect_none, expect_flag, expect_bool)
(expect_integer): Adjust to expect "-string".
(expect_string): New.
(all_options): Expect "-string".
(test-flag, test-boolean): Adjust to expect "-string".
(test-string): New proc.
(top level): Call it.
|
|
Currently, gdb::option::complete_options just discards any processed
option argument, because no completer needs that data.
When completing "pipe -d XXX gdbcmd XXX" however, the completer needs
to know about -d's argument (XXX), in order to know where input is
already past the gdb command and the delimiter.
In this commit, the fix for that is the factoring out of the
save_option_value_in_ctx function and calling it in complete_options.
For testing, this makes "maint show test-options-completion-result"
show the processed options too, like what the "maint test-options"
subcommands output when run. Then, of course, gdb.base/options.exp is
adjusted.
Doing this exposed a couple latent bugs, which is what the other gdb
changes in the patch are for:
- in the var_enum case, without the change, we'd end up with a null
enum argument, and print:
"-enum (null)"
- The get_ulongest change is necessary to avoid advancing PP in a
case where we end up throwing an error, e.g., when parsing "11x".
Without the change the operand pointer shown by "maint show
test-options-completion-result" would be left pointing at "x"
instead of "11x".
gdb/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* cli/cli-option.c (parse_option) <var_enum>: Don't return an
option_value with a null enumeration.
(complete_options): Save the option values in the context.
(save_option_value_in_ctx): New, factored out from ...
(process_options): ... here.
* cli/cli-utils.c (get_ulongest): Don't advance PP until the end
of the function.
* maint-test-options.c (test_options_opts::dump): New, factored
out from ...
(maintenance_test_options_command_mode): ... here.
(maintenance_test_options_command_completion_result): Delete.
(maintenance_test_options_command_completion_text): Update
comment.
(maintenance_show_test_options_completion_result): Change
prototype. Just print
maintenance_test_options_command_completion_text.
(save_completion_result): New.
(maintenance_test_options_completer_mode): Pass options context to
complete_options, and then save a dump.
(_initialize_maint_test_options): Use add_cmd to install "maint
show test-options-completion-result".
gdb/testsuite/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* gdb.base/options.exp (test-misc, test-flag, test-boolean)
(test-uinteger, test-enum): Adjust res_test_gdb_... calls to pass
the expected output in the success.
|
|
Running 'make check-read1 TESTS="gdb.base/options.exp"' revealed a
race in test_gdb_complete_tab_multiple. There's a gdb_test_multiple
call that expects a prompt in the middle of the regexp. That's racy
because gdb_test_multiple includes a built-in FAIL pattern for the
prompt, which may match if gdb is slow enough to produce the rest of
the output after the prompt.
Fix this in the usual way of splitting the matching in two.
gdb/testsuite/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* lib/completion-support.exp (test_gdb_complete_tab_multiple):
Split one gdb_test_multiple call in two to avoid a race.
|
|
( See original discussion and prototype here:
https://sourceware.org/ml/gdb-patches/2019-05/msg00570.html )
(gdb) help with
Temporarily set SETTING to VALUE, run COMMAND, and restore SETTING.
Usage: with SETTING [VALUE] [-- COMMAND]
Usage: w SETTING [VALUE] [-- COMMAND]
With no COMMAND, repeats the last executed command.
SETTING is any setting you can change with the "set" subcommands.
E.g.:
with language pascal -- print obj
with print elements unlimited -- print obj
As can be seen above, the "with" command is just like "set", but
instead of setting the setting permanently, it sets the setting, runs
a command and then restores the setting.
(gdb) p g_s
$1 = {a = 1, b = 2, c = 3}
(gdb) with language ada -- print g_s
$2 = (a => 1, b => 2, c => 3)
Warning: the current language does not match this frame.
(gdb) show language
The current source language is "auto; currently c".
(gdb) with print elements 100 -- with print object on -- print 1
$3 = 1
You can shorten things a bit though, as long as unambiguous. So this:
(gdb) with print elements 100 -- with print object off -- print 1
is the same as:
(gdb) w p el 100 -- w p o 0 -- p 1
Note that the patch adds a "w" alias for "with", as "w" is not
currently taken:
(gdb) w
Ambiguous command "w": watch, wh, whatis, where, while, while-stepping, winheight, ws.
Let me know if you'd prefer to reserve "w" for one of the other
commands above. IMHO, this command will end up being used frequently
enough that it deserves the "w" shorthand.
A nice feature is that this is fully integrated with TAB-completion:
(gdb) with p[TAB]
pagination print prompt python
(gdb) with print [TAB]
address max-depth static-members
array max-symbolic-offset symbol
array-indexes null-stop symbol-filename
asm-demangle object symbol-loading
demangle pascal_static-members thread-events
elements pretty type
entry-values raw union
frame-arguments repeats vtbl
inferior-events sevenbit-strings
(gdb) with print [TAB]
(gdb) with print elements unlimited -- thread apply all -[TAB]
-ascending -c -q -s
(gdb) with print elements unlimited -- print -[TAB]
-address -max-depth -repeats -vtbl
-array -null-stop -static-members
-array-indexes -object -symbol
-elements -pretty -union
The main advantage of this new command compared to command options,
like the new "print -OPT", is that this command works with any
setting, and, it works nicely when you want to override a setting
while running a user-defined command, like:
(gdb) with print pretty -- usercmd
The disadvantage is that it isn't as compact or easy to type. I think
of command options and this command as complementary. I think that
even with this new command, it makes sense to continue developing the
command options in the direction of exposing most-oft-used settings as
command options.
Inspired by Philippe's "/" command proposal, if no command is
specified, then the last command is re-invoked, under the overridden
setting:
(gdb) p g_s
$1 = {a = 1, b = 2, c = 3}
(gdb) with language ada
$2 = (a => 1, b => 2, c => 3)
Warning: the current language does not match this frame.
Note: "with" requires "--" to separate the setting from the command.
It might be possible to do without that, but, I haven't tried it yet,
and I think that this can go in without it. We can always downgrade
to making "--" optional if we manage to make it work.
On to the patch itself, the implementation of the command is simpler
than one might expect. A few details:
- I factored out a bit from pipe_command into repeat_previous
directly, because otherwise I'd need to copy&paste the same code and
same error message in the with command.
- The parse_cli_var_uinteger / parse_cli_var_zuinteger_unlimited /
do_set_command changes are necessary since we can now pass an empty
string as argument.
- do_show_command was split in two, as a FIXME comment suggests, but
for a different reason: we need to get a string version of a "set"
command's value, and we already had code for that in
do_show_command. That code is now factored out to the new
get_setshow_command_value_string function.
- There's a new "maint with" command added too:
(gdb) help maint with
Like "with", but works with "maintenance set" variables.
Usage: maintenance with SETTING [VALUE] [-- COMMAND]
With no COMMAND, repeats the last executed command.
SETTING is any setting you can change with the "maintenance set"
subcommands.
"with" and "maint with" share 99% of the implementation.
This might be useful on its own, but it's also useful for testing,
since with this, we can use the "maint set/show test-settings"
settings for exercising the "with" machinery with all the command
type variants (all enum var_types). This is done in the new
gdb/base/with.exp testcase.
The documentation bits are originally based on Philippe's docs for the
"/" command, hence the attribution in the ChangeLog.
gdb/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* NEWS (New commands): Mention "with" and "maint with".
* cli/cli-cmds.c (with_command_1, with_command_completer_1)
(with_command, with_command_completer): New.
(pipe_command): Adjust to new repeat_previous
interface.
(_initialize_cli_cmds): Install the "with" command and its "w"
alias.
* cli/cli-cmds.h (with_command_1, with_command_completer_1): New
declarations.
* cli/cli-setshow.c (parse_cli_var_uinteger)
(parse_cli_var_zuinteger_unlimited, do_set_command): Handle empty
argument strings for all var_types.
(get_setshow_command_value_string): New, factored out from ...
(do_show_command): ... this.
* cli/cli-setshow.h: Include <string>.
(get_setshow_command_value_string): Declare.
* command.h (repeat_previous): Now returns const char *. Adjust
comment.
* maint.c: Include "cli/cli-cmds.h".
(maintenance_with_cmd, maintenance_with_cmd_completer): New.
(_initialize_maint_cmds): Register the "maintenance with" command.
* top.c (repeat_previous): Move bits from pipe_command here:
Return the saved command line, if any; error out if there's no
command to relaunch.
gdb/doc/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Command Settings): New node documenting the general
concept of settings, how to change them, and the new "with"
command.
(Maintenance Commands): Document "maint with".
gdb/testsuite/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* gdb.base/with.c: New file.
* gdb.base/with.exp: New file.
|
|
This commit renames "maint test-settings set/show" to "maint set/show
test-settings".
This helps the following patch, which introduce a "maint with" command
what works with all "maint set" settings.
gdb/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* NEWS (New commands): Mention "maint set/show test-settings"
instead of "maint test-settings".
* maint-test-settings.c (maintenance_test_settings_list): Delete.
(maintenance_test_settings_set_list): Rename to ...
(maintenance_set_test_settings_list): ... this.
(maintenance_test_settings_show_list): Rename to ...
(maintenance_show_test_settings_list): ... this.
(maintenance_test_settings_cmd): Delete.
(maintenance_test_settings_set_cmd): ...
(maintenance_set_test_settings_cmd): ... this.
(maintenance_test_settings_show_cmd): ...
(maintenance_show_test_settings_cmd): ... this.
(maintenance_test_settings_show_value_cmd):
(maintenance_show_test_settings_value_cmd): ... this.
(_initialize_maint_test_settings): No longer install the "maint
test-settings" prefix command. Rename "maint test-settings set"
to "maint set test-settings", and "maint test-settings show" to
"maint show test-settings". Adjust all subcommands.
gdb/doc/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Maintenance Commands): Document "maint set/show
test-settings" instead of "maint test-settings set/show".
gdb/testsuite/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* gdb.base/settings.exp: Replace all references to "maint
test-settings set" with references to "maint set test-settings",
and all references to "maint test-settings show" with references
to "maint show test-settings".
|
|
Fix the file's intro comment, and s/test-options/test-settings/.
gdb/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* maint-test-settings.c: Fix file's intro comment. Replace all
references to "test-options" with references to "test-settings",
in comments.
|
|
New tests added later for the incoming "with" command exposed a couple
invalid-default-value bugs in the "maint test-settings" commands:
- var_filename commands don't allow setting the filename to the empty
string (unlike var_optional_filename commands), yet, "maint
test-settings filename"'s control variable was not initialized, so
on startup, "maint test-settings show filename" shows an empty
string.
- "maint test-settings enum"'s control variable was not initialized,
so on startup, "maint test-settings show enum" shows an empty value
instead of a valid enum value.
Both issues are fixed by initializing the control variables.
gdb/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* maint-test-settings.c (maintenance_test_settings_xxx)
(maintenance_test_settings_yyy, maintenance_test_settings_zzz):
New.
(maintenance_test_settings_enums): Use them.
(maintenance_test_settings_enum): Default to
maintenance_test_settings_xxx.
(_initialize_maint_test_settings): Initialize
MAINTENANCE_TEST_SETTINGS_FILENAME.
gdb/testsuite/ChangeLog:
2019-07-03 Pedro Alves <palves@redhat.com>
* gdb.base/settings.exp (test-string): Adjust expected out when
testing "maint test-settings show filename"
|
|
... since nobody uses it.
gdb/ChangeLog:
* breakpoint.h (remove_breakpoints_inf): Change return type to
void, move function documentation here.
* breakpoint.c (remove_breakpoints_inf): Change return type to
void, move function documentation to header.
|
|
This makes "info threads" use the gdb::option framework to process
options. There's only one option today (-gid), and it isn't used much
frequently unless you're looking at matching MI output. Still, this
was in the neighborhood of "thread apply" so I had converted it.
The main advantage is that TAB completion now shows you the available
options, and gives you a hint to what the command accepts as operand
argument, including showing a metasyntactic variable:
(gdb) info threads [TAB]
-gid ID
(gdb) help info threads
Display currently known threads.
Usage: info threads [OPTION]... [ID]...
Options:
-gid
Show global thread IDs.
If ID is given, it is a space-separated list of IDs of threads to display.
Otherwise, all threads are displayed.
(gdb)
gdb/ChangeLog:
2019-07-02 Pedro Alves <palves@redhat.com>
* NEWS (Completion improvements): Mention "info threads".
* thread.c (struct info_threads_opts, info_threads_option_defs)
(make_info_threads_options_def_group): New.
(info_threads_command): Use gdb::option::process_options.
(info_threads_command_completer): New.
(_initialize_thread): Use gdb::option::build_help to build the
help text for "info threads".
gdb/testsuite/ChangeLog:
2019-07-02 Pedro Alves <palves@redhat.com>
* gdb.base/options.exp (test-info-threads): New procedure.
(top level): Call it.
|
|
... since the implementation is in symfile.c.
At the same time, add some documentation and make sure the first
parameter's name in the declaration matches the definition.
gdb/ChangeLog:
* defs.h (generic_load): Move from here...
* symfile.h (generic_load): ... to here. Rename name parameter
to args.
* symfile.c (generic_load): Add comment.
|
|
A static analyzer pointed out that find_vec_in_debug_names will use
the contents of a unique_ptr after it has been destroyed. This patch
fixes the bug by hoisting the declaration into the appropriate
enclosing block.
I'm checking this in as obvious.
gdb/ChangeLog
2019-07-01 Tom Tromey <tromey@adacore.com>
* dwarf2read.c
(dw2_debug_names_iterator::find_vec_in_debug_names): Hoist
declaration of without_params. Fix formatting.
|
|
All callers of ada_lookup_symbol pass NULL for the
"is_a_field_of_this" parameter, so remove it.
gdb/ChangeLog
2019-07-01 Tom Tromey <tromey@adacore.com>
* ada-exp.y (find_primitive_type): Update.
* ada-lang.h (ada_lookup_symbol): Update.
* ada-lang.c (ada_lookup_symbol): Remove "is_a_field_of_this"
parameter.
(ada_lookup_encoded_symbol, ada_lookup_symbol_nonlocal): Update.
|
|
This bug has been reported on PR breakpoints/24541, but it is possible
to reproduce it easily by running:
make check-gdb TESTS=gdb.base/stap-probe.exp RUNTESTFLAGS='--target_board unix/-m32'
The underlying cause is kind of complex, and involves decisions made
by GCC and the sys/sdt.h header file about how to represent a probe
argument that lives in a register in 32-bit programs. I'll use
Andrew's example on the bug to illustrate the problem.
libstdc++ has a probe named "throw" with two arguments. On i386, the
probe is:
stapsdt 0x00000028 NT_STAPSDT (SystemTap probe descriptors)
Provider: libstdcxx
Name: throw
Location: 0x00072c96, Base: 0x00133d64, Semaphore: 0x00000000
Arguments: 4@%si 4@%di
I.e., the first argument is an unsigned 32-bit value (represented by
the "4@") that lives on %si, and the second argument is an unsigned
32-bit value that lives on %di. Note the discrepancy between the
argument size reported by the probe (32-bit) and the register size
being used to store the value (16-bit).
However, if you take a look at the disassemble of a program that uses
this probe, you will see:
00072c80 <__cxa_throw@@CXXABI_1.3>:
72c80: 57 push %edi
72c81: 56 push %esi
72c82: 53 push %ebx
72c83: 8b 74 24 10 mov 0x10(%esp),%esi
72c87: e8 74 bf ff ff call 6ec00 <__cxa_finalize@plt+0x980>
72c8c: 81 c3 74 e3 10 00 add $0x10e374,%ebx
72c92: 8b 7c 24 14 mov 0x14(%esp),%edi
72c96: 90 nop <----------------- PROBE IS HERE
72c97: e8 d4 a2 ff ff call 6cf70 <__cxa_get_globals@plt>
72c9c: 83 40 04 01 addl $0x1,0x4(%eax)
72ca0: 83 ec 04 sub $0x4,%esp
72ca3: ff 74 24 1c pushl 0x1c(%esp)
72ca7: 57 push %edi
72ca8: 56 push %esi
72ca9: e8 62 a3 ff ff call 6d010 <__cxa_init_primary_exception@plt>
72cae: 8d 70 40 lea 0x40(%eax),%esi
72cb1: c7 00 01 00 00 00 movl $0x1,(%eax)
72cb7: 89 34 24 mov %esi,(%esp)
72cba: e8 61 96 ff ff call 6c320 <_Unwind_RaiseException@plt>
72cbf: 89 34 24 mov %esi,(%esp)
72cc2: e8 c9 84 ff ff call 6b190 <__cxa_begin_catch@plt>
72cc7: e8 d4 b3 ff ff call 6e0a0 <_ZSt9terminatev@plt>
72ccc: 66 90 xchg %ax,%ax
72cce: 66 90 xchg %ax,%ax
Note how the program is actually using %edi, and not %di, to store the
second argument. This is the problem here.
GDB will basically read the probe argument, then read the contents of
%di, and then cast this value to uint32_t, which causes the wrong
value to be obtained. In the gdb.base/stap-probe.exp case, this makes
GDB read the wrong memory location, and not be able to display a test
string. In Andrew's example, this causes GDB to actually stop at a
"catch throw" when it should actually have *not* stopped.
After some discussion with Frank Eigler and Jakub Jelinek, it was
decided that this bug should be fixed on the client side (i.e., the
program that actually reads the probes), and this is why I'm proposing
this patch.
The idea is simple: we will have a gdbarch method, which, for now, is
only used by i386. The generic code that deals with register operands
on gdb/stap-probe.c will call this method if it exists, passing the
current parse information, the register name and its number.
The i386 method will then verify if the register size is greater or
equal than the size reported by the stap probe (the "4@" part). If it
is, we're fine. Otherwise, it will check if we're dealing with any of
the "extendable" registers (like ax, bx, si, di, sp, etc.). If we
are, it will change the register name to include the "e" prefix.
I have tested the patch here in many scenarios, and it fixes Andrew's
bug and also the regressions I mentioned before, on
gdb.base/stap-probe.exp. No regressions where found on other tests.
Comments?
gdb/ChangeLog:
2019-06-27 Sergio Durigan Junior <sergiodj@redhat.com>
PR breakpoints/24541
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh: Add 'stap_adjust_register'.
* i386-tdep.c: Include '<unordered_set>'.
(i386_stap_adjust_register): New function.
(i386_elf_init_abi): Register 'i386_stap_adjust_register'.
* stap-probe.c (stap_parse_register_operand): Call
'gdbarch_stap_adjust_register'.
|
|
This bug was originally reported against Fedora GDB:
https://bugzilla.redhat.com/show_bug.cgi?id=1723564
The problem is that GDB will crash in the following scenario:
- PYTHONMALLOC=debug or PYTHONDEVMODE=1 is set.
- The Python debuginfo is installed.
- GDB is used to debug Python.
The crash looks like this:
$ PYTHONMALLOC=debug gdb -args python3 -c pass
GNU gdb (GDB) Fedora 8.3-3.fc30
Reading symbols from python3...
Reading symbols from /usr/lib/debug/usr/bin/python3.7m-3.7.3-3.fc30.x86_64.debug...
(gdb) run
Starting program: /usr/bin/python3 -c pass
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.29-9.fc30.x86_64
Debug memory block at address p=0x5603977bf330: API ''
8098648152243306496 bytes originally requested
The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfb):
at p-7: 0x03 *** OUCH
at p-6: 0x00 *** OUCH
at p-5: 0x00 *** OUCH
at p-4: 0x00 *** OUCH
at p-3: 0x00 *** OUCH
at p-2: 0x00 *** OUCH
at p-1: 0x00 *** OUCH
Because memory is corrupted at the start, the count of bytes requested
may be bogus, and checking the trailing pad bytes may segfault.
The 8 pad bytes at tail=0x706483999ad1f330 are Segmentation fault (core dumped)
It's hard to determine what happens, but after doing some
investigation and talking to Victor Stinner I found that GDB should
not use the Python memory allocation functions before the Python
interpreter is initialized (which makes sense). However, we do just
that on python/python.c:do_start_initialization:
...
progsize = strlen (progname.get ());
progname_copy = (wchar_t *) PyMem_Malloc ((progsize + 1) * sizeof (wchar_t));
...
/* Note that Py_SetProgramName expects the string it is passed to
remain alive for the duration of the program's execution, so
it is not freed after this call. */
Py_SetProgramName (progname_copy);
...
Py_Initialize ();
PyEval_InitThreads ();
Upon reading the Python 3 C API documentation, I
found (https://docs.python.org/3.5/c-api/memory.html):
To avoid memory corruption, extension writers should never try to
operate on Python objects with the functions exported by the C
library: malloc(), calloc(), realloc() and free(). This will result in
mixed calls between the C allocator and the Python memory manager with
fatal consequences, because they implement different algorithms and
operate on different heaps. However, one may safely allocate and
release memory blocks with the C library allocator for individual
purposes[...]
And Py_SetProgramName seems like a very simple call that doesn't need
a Python-allocated memory to work on. So I'm proposing this patch,
which simply replaces PyMem_Malloc by xmalloc.
Testing this is more complicated. First, the crash is completely
non-deterministic; I was able to reproduce it 10 times in a row, and
then I wasn't able to reproduce it anymore. I found that if you
completely remove your build directory and rebuild GDB from scratch,
you can reproduce it again confidently. And with my patch, I
confirmed that the bug doesn't manifest even in this situation.
No regressions found.
OK to apply?
gdb/ChangeLog:
2019-06-28 Sergio Durigan Junior <sergiodj@redhat.com>
PR python/24742
https://bugzilla.redhat.com/show_bug.cgi?id=1723564
* python/python.c (do_start_initialization): Use 'xmalloc'
instead of 'PyMem_Malloc'.
|
|
We discovered that the Ada support in gdb depends on the order of the
DW_AT_name and DW_AT_linkage_name attributes in the DWARF. In
particular, if they are emitted in the "wrong" order for some system
symbols, "catch exception" will not work.
This patch fixes this problem by arranging to always prefer the
linkage name if both exist. This seems to be what the full symbol
reader already does -- that is, this is another bug arising from
having two different DWARF readers.
Another possible issue here is that gdb still doesn't really preserve
mangled names properly. There's a PR open about this. However, this
seems to be somewhat involved to fix, which is why this patch
continues to work around the bigger issue.
gdb/ChangeLog
2019-06-28 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (partial_die_info::read): Prefer the linkage name
for Ada.
gdb/testsuite/ChangeLog
2019-06-28 Tom Tromey <tromey@adacore.com>
* gdb.dwarf2/ada-linkage-name.c: New file.
* gdb.dwarf2/ada-linkage-name.exp: New file.
|
|
After seeing Simon's patch to change arm_per_objfile to use new and
delete, I realized it is now simple to change arm_objfile_data_key to
use the type-safe registry.
gdb/ChangeLog
2019-06-27 Tom Tromey <tromey@adacore.com>
* arm-tdep.c (arm_objfile_data_key): Move lower. Change type to
objfile_key.
(arm_find_mapping_symbol, arm_record_special_symbol)
(_initialize_arm_tdep): Update.
(arm_objfile_data_free): Remove.
|
|
Pedro and Tom both pointed out issues in the cp_print_value_fields
patch, aka the fix for PR c++/20020.
This patch addresses both issues. Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-06-27 Tom Tromey <tromey@adacore.com>
* cp-valprint.c (cp_print_value_fields): Pass opts, not options,
to cp_print_static_field.
gdb/testsuite/ChangeLog
2019-06-27 Tom Tromey <tromey@adacore.com>
* gdb.cp/constexpr-field.exp: Use setup_xfail.
|
|
lookup_minimal_symbol_solib_trampoline is unused, so this patch
removes it. The last use was apparently removed in
commit 61a12cfa ("Remove HPUX").
gdb/ChangeLog
2019-06-26 Tom Tromey <tromey@adacore.com>
* minsyms.c (lookup_minimal_symbol_solib_trampoline): Remove.
* minsyms.h (lookup_minimal_symbol_solib_trampoline): Don't
declare.
|
|
Add all the CPSR flags for Armv8.1-A through to Armv8.4-A.
In addition, document all the existing flags, and remove
the superfluous empty spaces.
gdb/ChangeLog:
* features/aarch64-core.c (create_feature_aarch64_core):
Regenerate.
* features/aarch64-core.xml: Add cpsr flags.
|
|
On Arm, the OS may use the full version string for the arch name when
installing the compiler, for example armv7hl-redhat-linux-gnueabi-gcc.
Implement gdbarch_gnu_triplet_regexp for Arm to allow this to be detected.
Ensure that other Arm targets (eg iwmmxt) are not affected.
This fixes the compile/ set of tests on those systems.
gdb/ChangeLog:
2019-06-26 Alan Hayward <alan.hayward@arm.com>
* arm-tdep.c (arm_gnu_triplet_regexp): New function.
(arm_gdbarch_init): Add arm_gnu_triplet_regexp.
|
|
When we run gdb.dwarf2/varval.exp with board cc-with-dwz, we run into:
...
gdb compile failed, dwz: varval: Couldn't find DIE referenced by \
DW_OP_GNU_variable_value
cc-with-tweaks.sh: dwz did not modify varval.
UNTESTED: gdb.dwarf2/varval.exp: failed to prepare
...
The problem is that varval contains some bad DWARF, which has been added
intentionally to test GDB, but that bad DWARF causes dwz to error out, which
has the consequence that the test-case remains untested with cc-with-dwz,
while the test-case contains also correct DWARF that does not occur in any
other test, and which we would really like to test with board cc-with-dwz.
Fix this by compiling varval twice, once without and once with the bad DWARF,
such that we have at least:
...
PASS: gdb.dwarf2/varval.exp: print varval
PASS: gdb.dwarf2/varval.exp: print varval2
PASS: gdb.dwarf2/varval.exp: print constval
PASS: gdb.dwarf2/varval.exp: print mixedval
PASS: gdb.dwarf2/varval.exp: print pointerval
PASS: gdb.dwarf2/varval.exp: print *pointerval
PASS: gdb.dwarf2/varval.exp: print structval
PASS: gdb.dwarf2/varval.exp: print untypedval
gdb compile failed, dwz: varval: Couldn't find DIE referenced by \
DW_OP_GNU_variable_value
cc-with-tweaks.sh: dwz did not modify varval.
UNTESTED: gdb.dwarf2/varval.exp: failed to prepare
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-06-26 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/varval.exp: Compile twice, once without bad DWARF.
|
|
The proc prepare_for_testing has "debug" as default argument for the options
parameter.
In the commit c596f180a1 "[gdb/testsuite] Compile index-cache.c with
-Wl,--build-id", by setting the options argument we've effectively dropped
"debug". This causes index-cache.exp to not contain any debug info anymore on
most systems (though not on openSUSE), which causes index-cache.exp FAILs.
Fix this by adding back the missing "debug" option.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-06-26 Tom de Vries <tdevries@suse.de>
* gdb.base/index-cache.exp: Add back missing debug option.
|
|
Somebody on IRC reported a while ago that loading a big ARM program in
GDB was very slow. Their profiling pointed out that a big amount of
time was spent in
VEC_safe_insert (arm_mapping_symbol_s, *map_p, idx, &new_map_sym);
I was able to verify this as well.
ARM mapping symbols are special ELF symbols named $a, $d and $t
indicating that symbols starting at this address up to the next mapping
symbol (in terms of address) are of type "ARM code", "data" and "Thumb
code", respectively. GDB records these symbols in vectors (one for each
section) in arm-tdep.c. These vectors are sorted by symbol address, to
allow for quick lookup. The current approach is to insert new symbols
at the right position to keep the vectors sorted at all time. This is
done based on the assumption that mapping symbols come already almost
sorted from the binary, as explains this comment in
arm_record_special_symbol:
/* Assume that most mapping symbols appear in order of increasing
value. If they were randomly distributed, it would be faster to
always push here and then sort at first use. */
Well, it turns out this is not the case. The original reporter
mentioned that mapping symbols in their binaries are not nearly sorted,
and this is not my experience either (at least in the binary used in the
benchmark below). So if the values don't come nearly sorted, doing
insertions to keep the vectors sorted ends up being of the order of
number_of_mapping_symbols ^ 2.
This patch changes it just like the comment above says, to just append
to the vector in arm_record_special_symbol and sort the vector on first
use.
Benchmark
=========
I have done some benchmarks using an --enable-targets=all GDB, compiled
with -O2, running on x86-64 and parsing file
dce18d22e5c2ecb6a3a57372f4e6ef614130bc.debug from this package:
https://launchpad.net/ubuntu/+source/firefox/66.0.3+build1-0ubuntu1/+build/16608691/+files/firefox-dbg_66.0.3+build1-0ubuntu1_armhf.deb
This file is the separate debug info for libxul.so (part of firefox) for
ARM.
I have added some traces to measure the execution time of just
elf_symtab_read and ran GDB like this:
./gdb --data-directory=data-directory -nx -batch .../path/to/usr/lib/debug/.build-id/65/dce18d22e5c2ecb6a3a57372f4e6ef614130bc.debug
Since the new code sorts the vectors on first use, it would be difficult
to benchmark it as-is and be fair, since the "before" version does more
work in elf_symtab_read. So I have actually benchmarked a version of
the patch that did sort all the vectors at the end of elf_symtab_read,
so the sorting would be considered in the measured execution time.
Here's the measured execution time of elf_symtab_read, averaged on 3
runs:
insert sorted (before): 28.678s
sort after (after): 1.760s
And here's the total execution time of the command above (just one run).
The time is now mostly spent in reading DWARF.
insert sorted: 71.12s user 2.71s system 99% cpu 1:14.03 total
sort after: 46.42s user 2.60s system 99% cpu 49.147 total
I tried for fun on my Raspberry Pi 3, the run time of
elf_symtab_read goes from ~259s to ~9s, reading the same file.
gdb/ChangeLog:
* arm-tdep.c (struct arm_per_objfile) <section_maps_sorted>: New
field.
(arm_find_mapping_symbol): Sort mapping symbol vectors on first
use.
(arm_record_special_symbol): Don't insert new symbol in sorted
position, push it at the end.
|
|
This patch replaces VEC (arm_mapping_symbol) with an std::vector. No
functional changes intended.
gdb/ChangeLog:
* arm-tdep.c (struct arm_mapping_symbol) (operator <): New.
(arm_mapping_symbol_s): Remove.
(DEF_VEC_O(arm_mapping_symbol_s)): Remove.
(arm_mapping_symbol_vec): New typedef.
(struct arm_per_objfile): Add constructor.
<section_maps>: Change type to
std::unique_ptr<arm_mapping_symbol_vec[]>.
(arm_compare_mapping_symbols): Remove.
(arm_find_mapping_symbol): Adjust to section_maps type change.
(arm_objfile_data_free): Call delete on arm_per_objfile.
(arm_record_special_symbol): Adjust to section_maps type change.
Allocate arm_per_objfile with new.
|
|
alias_command does not detect that the prefixes of the alias command and the
aliased command are not matching: it is comparing the alias prefix
with itself, instead of comparing it with the aliased command prefix.
This causes either the alias command to silently do nothing,
or to have GDB asserting:
(gdb) alias assigne imprime limite-elements = set print elements
../../binutils-gdb/gdb/cli/cli-cmds.c:1552: internal-error: void alias_command(const char*, int): Assertion `c_command != NULL && c_command != (struct cmd_list_element *) -1' failed.
A problem internal to GDB has been detected,
Fix the logic, and update gdb.base/alias.exp to test these cases.
gdb/ChangeLog
2019-06-25 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-cmds.c (alias_command): Compare the alias prefix
with the command prefix.
gdb/testsuite/ChangeLog
2019-06-25 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/alias.exp: Test non matching/non existing prefixes.
|
|
When running gdb.dwarf2/dw2-restrict.exp with board cc-with-dwz, we run into:
...
dwz: dw2-restrict: DW_AT_stmt_list not DW_FORM_sec_offset or DW_FORM_data4
...
The problem is that the DW_AT_stmt_list is encoded using DW_FORM_addr, while
DW_FORM_sec_offset or DW_FORM_data4 would be appropriate. The test-case uses
a dw2-restrict.S which was generated using clang 2.9, which contained a bug
( https://bugs.llvm.org/show_bug.cgi?id=9995 ) causing this problem.
Fix this by regenerating using clang 5.0.1.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-06-25 Tom de Vries <tdevries@suse.de>
PR testsuite/24727
* gdb.dwarf2/dw2-restrict.S: Regenerate using clang 5.0.1.
|
|
tui_delete_win does its own NULL check, so ~tui_gen_win_info does not
need to do it. Also, tui_delete_win has an extraneous "return".
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.c (tui_delete_win): Remove "return".
* tui/tui-data.c (~tui_gen_win_info): Remove "if".
|
|
Now that all the window types have their own concrete classes, the
tui_gen_win_info constructor can be protected.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-layout.c (init_and_make_win): Assert on unrecognized
type.
* tui/tui-data.h (struct tui_gen_win_info): Make constructor
protected.
|
|
valgrind pointed out that the TUI was using uninitialized memory in
set_is_exec_point_at. The bug is a missing check against LOA_ADDRESS,
causing gdb to examine the uninitialized bits of the "addr" field.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.c
(tui_source_window_base::set_is_exec_point_at): Add check against
LOA_ADDRESS.
|
|
A couple of spots in the TUI did a NULL check before an xfree. This
isn't necessary, and most other cases were removed from gdb a while
ago.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-source.c (tui_set_source_content): Don't check before
xfree.
* tui/tui-disasm.c (tui_disassemble): Don't check before xfree.
|
|
This removes union tui_which_element, instead moving the content
directly into tui_source_window_base. This allows for the deletion of
a fair amount of code. Now the TUI window hierarchy is more
type-safe. In particular, there is never any confusion now about
which members are in use by which subtype.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.h (tui_update_source_window_as_is)
(tui_alloc_source_buffer, tui_line_is_displayed)
(tui_addr_is_displayed): Change type of win_info.
* tui/tui-winsource.c (tui_update_source_window_as_is)
(tui_clear_source_content, tui_show_source_line)
(tui_show_source_content, tui_source_window_base::refill)
(tui_source_window_base::set_is_exec_point_at)
(tui_source_window_base::set_is_exec_point_at)
(tui_update_breakpoint_info, tui_set_exec_info_content): Update.
(tui_alloc_source_buffer, tui_line_is_displayed)
(tui_addr_is_displayed): Change type of win_info. Update.
* tui/tui-win.c (tui_resize_all, tui_adjust_win_heights)
(tui_source_window_base::do_make_visible_with_new_height):
Update.
* tui/tui-source.c (tui_set_source_content)
(tui_set_source_content_nil)
(tui_source_window::do_scroll_vertical): Update.
* tui/tui-layout.c (show_layout): Update.
* tui/tui-disasm.c (tui_set_disassem_content)
(tui_disasm_window::do_scroll_vertical): Update.
* tui/tui-data.h (tui_win_content): Remove.
(struct tui_gen_win_info) <content, content_size>: Remove.
(struct tui_source_element): Add initializers and destructor.
(union tui_which_element, struct tui_win_element): Remove.
(struct tui_source_window_base) <content>: New field.
(struct tui_data_window): Remove destructor.
(tui_alloc_content, tui_free_win_content)
(tui_free_all_source_wins_content): Don't declare.
* tui/tui-data.c (tui_initialize_static_data): Update.
(init_content_element, tui_alloc_content): Remove.
(~tui_gen_win_info): Update.
(~tui_data_window, tui_free_all_source_wins_content)
(tui_free_win_content, free_content, free_content_elements):
Remove.
|
|
A few functions can only operate on a source or disassembly window.
This patch adds a bit more type safety to a few of these functions.
This simplifies a subsequent patch.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.h (tui_clear_source_content)
(tui_erase_source_content, tui_show_source_content): Change type
of win_info.
* tui/tui-winsource.c (tui_clear_source_content)
(tui_erase_source_content, tui_show_source_content): Change type
of win_info.
* tui/tui-win.c (tui_resize_all, tui_adjust_win_heights): Update.
* tui/tui-source.h (tui_set_source_content_nil): Change type of
win_info.
* tui/tui-source.c (tui_set_source_content_nil): Change type of
win_info.
* tui/tui-layout.c (show_source_or_disasm_and_command): Update.
|
|
This changes tui_source_element::is_exec_point to be a bool. I looked
at also changing "has_break", but it turns out that this field is used
inconsistently (sometimes as flags and sometimes as a bool), and so
needs more invesstigation before it can be changed.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.c (tui_clear_source_content)
(tui_source_window_base::set_is_exec_point_at): Update.
* tui/tui-source.c (tui_set_source_content_nil): Update.
* tui/tui-data.h (struct tui_source_element) <is_exec_point>: Now
a bool.
* tui/tui-data.c (init_content_element): Update.
|
|
The TUI has a function called tui_win_is_auxillary, but the word
should actually be spelled "auxiliary". This fixes the typo.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.c (tui_gen_win_info::make_visible): Update.
* tui/tui-win.c (make_invisible_and_set_new_height): Update.
* tui/tui-layout.c (init_and_make_win): Update.
* tui/tui.h (enum tui_win_type): Update.
* tui/tui-data.h (tui_win_is_auxiliary): Rename from
tui_win_is_auxillary.
* tui/tui-data.c (tui_win_is_auxiliary): Rename from
tui_win_is_auxillary.
|
|
This removes "data_window" from union tui_which_element and updates
the uses. It also changes how tui_data_window refers to the register
data, and changes it not to need the "content" field at all (though as
this is in a base class, it can't yet be removed).
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.c (tui_data_window::refresh_window): Update.
* tui/tui-windata.c (tui_data_window::first_data_item_displayed)
(tui_delete_data_content_windows, tui_display_all_data)
(tui_data_window::do_scroll_vertical, tui_display_data_from):
Update.
* tui/tui-win.c (tui_data_window::set_new_height): Simplify.
* tui/tui-regs.c (tui_last_regs_line_no)
(tui_line_from_reg_element_no, tui_first_reg_element_no_inline)
(tui_show_registers): Update.
(tui_show_register_group): Return void. Update.
(tui_display_registers_from, tui_display_reg_element_at_line)
(tui_display_registers_from_line, tui_check_register_values):
Update.
* tui/tui-data.h (union tui_which_element) <data_window>: Remove
member.
(struct tui_data_window) <regs_content>: Now a std::vector.
<regs_content_count>: Remove.
(tui_add_content_elements, tui_free_data_content): Don't declare.
* tui/tui-data.c (tui_data_window::clear_detail): Update.
(init_content_element): Remove DATA_WIN case. Add assert.
(tui_add_content_elements): Remove.
(tui_data_window): Update.
(tui_free_data_content): Remove.
(free_content_elements): Remove DATA_WIN case.
|
|
The TUI has some stub code for adding data other than registers to the
data window. However, it doesn't do anything, and apparently never
has. This removes the dead code.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-data.c (tui_data_item_window): Update.
* tui/tui-windata.h (tui_check_data_values): Don't declare.
* tui/tui-windata.c (tui_display_all_data)
(tui_display_data_from_line): Update.
(tui_check_data_values): Remove.
* tui/tui-regs.c (tui_show_register_group)
(tui_display_reg_element_at_line): Update.
* tui/tui-hooks.c (tui_register_changed)
(tui_refresh_frame_and_register_information): Call
tui_check_register_values.
* tui/tui-data.h (struct tui_data_window) <data_content,
data_content_count, data_type>: Remove.
(enum tui_data_type): Remove.
|
|
tui_first_data_item_displayed is only called from tui_data_window
methods, so turn it into a method as well.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-windata.h (tui_first_data_item_displayed): Don't
declare.
* tui/tui-windata.c (tui_data_window::first_data_item_displayed):
Rename from tui_first_data_item_displayed. Update.
(tui_data_window::refresh_all)
(tui_data_window::do_scroll_vertical): Update.
* tui/tui-data.h (struct tui_data_window)
<first_data_item_displayed>: Declare new method.
|
|
tui_init_generic_part has a single caller, so simply inline it there.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-data.h (tui_init_generic_part): Don't declare.
* tui/tui-data.c (tui_init_generic_part): Remove, moving
contents...
(tui_initialize_static_data): ...here.
|
|
This introduces a new subclass of tui_gen_win_info for the data item
windows, letting us remove another element from tui_which_element.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-regs.c (tui_show_registers, tui_show_register_group)
(tui_display_registers_from, tui_check_register_values): Update.
(tui_display_register): Remove win_info parameter; update.
(tui_get_register): Change type of parameters.
* tui/tui-data.h (struct tui_data_element): Remove.
(union tui_which_element) <data>: Remove.
<data_window>: Change type.
(struct tui_data_item_window): New.
* tui/tui-data.c (init_content_element): Remove DATA_ITEM_WIN
case. Add assert.
(~tui_data_item_window): New destructor.
(free_content_elements): Remove DATA_ITEM_WIN case.
|
|
This removes a couple of unused constants from enum tui_win_type.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui.h (enum tui_win_type) <MAX_WINDOWS, UNDEFINED_WIN>:
Remove.
|
|
union tui_which_element has a "command" member, but it is never used.
This removes it.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-data.h (struct tui_command_element): Remove.
(union tui_which_element) <command>: Remove.
* tui/tui-data.c (init_content_element): Remove CMD_WIN case. Add
assert.
(free_content_elements): Remove CMD_WIN case.
|
|
The "split" field in struct layout_def is never used, so this patch
removes it.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-layout.c (tui_set_layout): Update.
* tui/tui-data.h (struct tui_layout_def) <split>: Remove.
* tui/tui-data.c (layout_def): Update.
|
|
This introduces a new subclass of tui_gen_win_info for the locator,
letting us remove another element from union tui_which_element.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.c (tui_refresh_all): Update.
* tui/tui-win.c (tui_resize_all, tui_adjust_win_heights)
(tui_source_window_base::set_new_height): Update.
* tui/tui-stack.c (tui_make_status_line): Change parameter type.
Update.
(tui_set_locator_fullname, tui_set_locator_info)
(tui_show_frame_info): Update.
* tui/tui-source.c (tui_set_source_content)
(tui_source_is_displayed): Update.
* tui/tui-layout.c (show_source_disasm_command, show_data)
(show_source_or_disasm_and_command): Update.
* tui/tui-disasm.c (tui_set_disassem_content)
(tui_get_begin_asm_address): Update.
* tui/tui-data.h (struct tui_locator_element): Remove.
(union tui_which_element) <locator>: Remove.
(struct tui_locator_window): New.
(tui_locator_win_info_ptr): Change return type.
* tui/tui-data.c (_locator): Change type.
(tui_locator_win_info_ptr): Change return type.
(init_content_element): Remove LOCATOR_WIN case. Add assert.
(tui_alloc_content): Add assert.
|
|
This pulls the EXEC_INFO_WIN case out into its own subclass of
tui_gen_win_info. This lets us remove an element from
union tui_which_element.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.c
(tui_exec_info_window::maybe_allocate_content): New method.
(tui_set_exec_info_content, tui_show_exec_info_content): Update.
* tui/tui-layout.c (init_and_make_win): Add EXEC_INFO_WIN case.
(make_source_or_disasm_window): Add cast.
* tui/tui-data.h (union tui_which_element) <simple_string>:
Remove.
(struct tui_source_info): New.
(struct tui_source_window_base) <execution_info>: Change type.
* tui/tui-data.c (init_content_element): Remove EXEC_INFO_WIN
case, and add assert.
(tui_alloc_content): Add assert.
|
|
There is only a single caller of tui_alloc_win_info, and we're going
to add more "new" cases to that caller, so remove tui_alloc_win_info
and inline it into init_and_make_win.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-data.h (tui_alloc_win_info): Don't declare.
* tui/tui-layout.c (init_and_make_win): Use "new" directly.
* tui/tui-data.c (tui_alloc_win_info): Remove.
|
|
This changes tui_set_win_focus_to so that it no longer checks the
window type. Instead, now tui_unhighlight_win also checks whether the
window can be highlighted.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_set_win_focus_to): Don't check window type.
* tui/tui-wingeneral.c (tui_unhighlight_win): Check
can_highlight.
|
|
This changes make_visible_with_new_height to be a method on
tui_win_info, letting us remove a spot that checks the window type.
gdb/ChangeLog
2019-06-25 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_source_window_base::update_tab_width): Call
make_visible_with_new_height method.
(tui_win_info::make_visible_with_new_height): New method.
(tui_source_window_base::do_make_visible_with_new_height)
(tui_data_window::do_make_visible_with_new_height)
(tui_cmd_window::do_make_visible_with_new_height): New methods.
(make_visible_with_new_height): Remove.
(tui_resize_all, tui_adjust_win_heights): Use
make_visible_with_new_height method.
* tui/tui-data.h (struct tui_win_info)
<do_make_visible_with_new_height, make_visible_with_new_height>:
New methods.
(struct tui_source_window_base, struct tui_data_window)
(struct tui_cmd_window) <do_make_visible_with_new_height>: New
methods.
|
