With global system gcc-5.0 if one also installs ccache (needing a different
patch
https://bugzilla.samba.org/show_bug.cgi?id=11060
for -fplugin=libcc1plugin) it breaks as GDB will read from inferior
DW_AT_producer containing -fpreprocessed (due to ccache used to compile the
inferior).
<c> DW_AT_producer : (indirect string, offset: 0x52): GNU C11 5.0.0 20150114 (Red Hat 5.0.0-0.1) -fpreprocessed -mtune=generic -
march=x86-64 -g
It is wrong that gcc puts -fpreprocessed into DW_AT_producer - fixed it in
trunk GCCs:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01495.html
But even with that fix there are already built inferiors out there which GDB
could be compatible (for the 'compile' mode) with.
gdb/ChangeLog
2015-02-03 Jan Kratochvil <jan.kratochvil@redhat.com>
Filter out inferior gcc option -fpreprocessed.
* compile/compile.c (filter_args): New function.
(get_args): Use it.
Even with the previous patch installed, we'll still see
sigall-reverse.exp occasionally fail. The problem is that the event
loop's event handling processing is done in two steps:
#1 - poll all event sources, and push new event objects to the event
queue, until all event sources are drained.
#2 - go through the event queue, processing each event object at a
time. For each event, call the associated callback, and deletes the
event object from the queue.
and then bad things happen if between #1 and #2 something decides that
events from an event source that has already queued events shouldn't
be processed yet. To do that, we either remove the event source from
the list of event sources, or clear its "have events" flag. However,
if an event for that source has meanwhile already been pushed in the
event queue, #2 will still process it and call the associated
callback...
One way to fix it that I considered was to do something to the event
objects already in the event queue when an event source is no longer
interesting. But then I couldn't find any good reason for the
two-step process in the first place. It's much simpler (and less
code) to call the event source callbacks as we poll the sources and
find events.
Tested on x86-64 Fedora 20, native and gdbserver.
gdb/
2015-02-03 Pedro Alves <palves@redhat.com>
* event-loop.c: Don't declare nor define a queue type for
gdb_event_p.
(event_queue): Delete.
(create_event, create_file_event, gdb_event_xfree)
(initialize_event_loop, process_event): Delete.
(gdb_do_one_event): Return as soon as one event is handled.
(handle_file_event): Change prototype. Used the passed in
file_handler pointer and ready_mask instead of looping over all
file handlers.
(gdb_wait_for_event): Update the poll/select timeouts before
blocking. Run event handlers directly instead of queueing events.
Return as soon as one event is handled.
(struct async_event_handler_data): Delete.
(invoke_async_event_handler): Delete.
(check_async_event_handlers): Change return type to int. Run
event handlers directly instead of queueing events. Return as
soon as one event is handled.
(handle_timer_event): Delete.
(update_wait_timeout): New function, factored out from
poll_timers.
(poll_timers): Reimplement.
* event-loop.h (initialize_event_loop): Delete declaration.
* top.c (gdb_init): Don't call initialize_event_loop.
The sigall-reverse.exp test occasionally fails with something like this:
(gdb) PASS: gdb.reverse/sigall-reverse.exp: send signal TERM
continue
Continuing.
The next instruction is syscall exit_group. It will make the program exit. Do you want to stop the program?([y] or n) FAIL: gdb.reverse/sigall-reverse.exp: continue to signal exit (timeout)
FAIL: gdb.reverse/sigall-reverse.exp: reverse to handler of TERM (timeout)
FAIL: gdb.reverse/sigall-reverse.exp: reverse to gen_TERM (timeout)
This is another event-loop/async related problem exposed by the patch
that made 'query' use gdb_readline_wrapper (588dcc3edb).
The problem is that even though gdb_readline_wrapper disables
target-async while the secondary prompt is in progress, the record
target's async event source is left marked. So when
gdb_readline_wrapper nests an event loop to process input, it may
happen that that event loop ends up processing a target event while
GDB is not really ready for it. Here's the relevant part of the
backtrace showing the root issue in action:
...
#14 0x000000000061cb48 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:4158
#15 0x0000000000642917 in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:57
#16 0x000000000077ca5c in record_full_async_inferior_event_handler (data=0x0) at src/gdb/record-full.c:791
#17 0x0000000000640fdf in invoke_async_event_handler (data=...) at src/gdb/event-loop.c:1067
#18 0x000000000063fb01 in process_event () at src/gdb/event-loop.c:339
#19 0x000000000063fb2a in gdb_do_one_event () at src/gdb/event-loop.c:360
#20 0x000000000074d607 in gdb_readline_wrapper (prompt=0x3588f40 "The next instruction is syscall exit_group. It will make the program exit. Do you want to stop the program?([y] or n) ") at src/gdb/top.c:842
#21 0x0000000000750bd9 in defaulted_query (ctlstr=0x8c6588 "The next instruction is syscall exit_group. It will make the program exit. Do you want to stop the program?", defchar=121 'y', args=0x7fff70524410) at src/gdb/utils.c:1279
#22 0x0000000000750e4c in yquery (ctlstr=0x8c6588 "The next instruction is syscall exit_group. It will make the program exit. Do you want to stop the program?") at src/gdb/utils.c:1358
#23 0x00000000004b020e in record_linux_system_call (syscall=gdb_sys_exit_group, regcache=0x3529450, tdep=0xd6c840 <amd64_linux_record_tdep>) at src/gdb/linux-record.c:1933
With my all-stop-on-top-of-non-stop series, I'm also seeing
gdb.server/ext-attach.exp fail occasionally due to the same issue.
The first part of the fix is for target_async implementations to make
sure to remove/unmark all target-related event sources from the event
loop.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2015-02-03 Pedro Alves <palves@redhat.com>
* event-loop.c (clear_async_event_handler): New function.
* event-loop.h (clear_async_event_handler): New declaration.
* record-btrace.c (record_btrace_async): New function.
(init_record_btrace_ops): Install record_btrace_async.
* record-full.c (record_full_async): New function.
(record_full_resume): Don't mark the async event source here.
(init_record_full_ops): Install record_full_async.
(record_full_core_resume): Don't mark the async event source here.
(init_record_full_core_ops): Install record_full_async.
* remote.c (remote_async): Mark and clear the async stop reply
queue event-loop token as appropriate.
In all these cases we're interested in whether the target is currently
async, with its event sources installed in the event loop, not whether
it can async if needed. Also, I'm not seeing the point of the
target_async call from within linux_nat_wait. That's normally done on
resume instead, which this target already does.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2015-02-03 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_child_follow_fork, linux_nat_wait_1): Use
target_is_async_p instead of target_can_async.
(linux_nat_wait): Use target_is_async_p instead of
target_can_async. Don't enable async here.
* remote.c (interrupt_query, remote_wait, putpkt_binary): Use
target_is_async_p instead of target_can_async.
This is the result of a little bit of investigation of the C and Ada
languages, as well as some common sense.
gdb/ChangeLog:
* varobj.h (lang_varobj_ops): Mention which return values need
to be freed.
When ada-lang.c:ada_lookup_symbol_list_worker finds a match in
the symbol cache, it caches the result again, which is unecessary.
This patch fixes the code to avoid that.
gdb/ChangeLog:
PR gdb/17856:
* ada-lang.c (ada_lookup_symbol_list_worker): Do not re-cache
results found in the cache.
Tested on x86_64-linux, no regression.
The Ada symbol cache has been designed to have one instance of that
of that cache per program space, and for each instance to be created
on-demand. ada_get_symbol_cache is the function responsible for both
lookup and creation on demand.
Unfortunately, ada_get_symbol_cache forgot to store the reference
to newly created caches, thus causing it to:
- Leak old caches;
- Allocate a new cache each time the cache is being searched or
a new entry is to be inserted.
This patch fixes the issue by avoiding the use of the local variable,
which indirectly allowed the bug to happen. We manipulate the reference
in the program-space data instead.
gdb/ChangeLog:
PR gdb/17854:
* ada-lang.c (ada_get_symbol_cache): Set pspace_data->sym_cache
when allocating a new one.
Every type has to pay the price in memory usage for their presence.
The proper place for them is in the type_specific field which exists
for this purpose.
gdb/ChangeLog:
* dwarf2read.c (process_structure_scope): Update setting of
TYPE_VPTR_BASETYPE, TYPE_VPTR_FIELDNO.
* gdbtypes.c (internal_type_vptr_fieldno): New function.
(set_type_vptr_fieldno): New function.
(internal_type_vptr_basetype): New function.
(set_type_vptr_basetype): New function.
(get_vptr_fieldno): Update setting of TYPE_VPTR_FIELDNO,
TYPE_VPTR_BASETYPE.
(allocate_cplus_struct_type): Initialize vptr_fieldno.
(recursive_dump_type): Printing of vptr_fieldno, vptr_basetype ...
(print_cplus_stuff): ... moved here.
(copy_type_recursive): Don't copy TYPE_VPTR_BASETYPE.
* gdbtypes.h (struct main_type): Members vptr_fieldno, vptr_basetype
moved to ...
(struct cplus_struct_type): ... here. All uses updated.
(TYPE_VPTR_FIELDNO, TYPE_VPTR_BASETYPE): Rewrite.
(internal_type_vptr_fieldno, set_type_vptr_fieldno): Declare.
(internal_type_vptr_basetype, set_type_vptr_basetype): Declare.
* stabsread.c (read_tilde_fields): Update setting of
TYPE_VPTR_FIELDNO, TYPE_VPTR_BASETYPE.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp <maint print type argc>: Update expected output.
This patch moves TYPE_SELF_TYPE into new field type_specific.self_type
for MEMBERPTR,METHODPTR types, and into type_specific.func_stuff
for METHODs, and then updates everything to use that.
TYPE_CODE_METHOD could share some things with TYPE_CODE_FUNC
(e.g. TYPE_NO_RETURN) and it seemed simplest to keep them together.
Moving TYPE_SELF_TYPE into type_specific.func_stuff for TYPE_CODE_METHOD
is also nice because when we allocate space for function types we assume
they're TYPE_CODE_FUNCs. If TYPE_CODE_METHODs don't need or use that
space then that space would be wasted, and cleaning that up would involve
more invasive changes.
In order to catch errant uses I've added accessor functions
that do some checking.
One can no longer assign to TYPE_SELF_TYPE like this:
TYPE_SELF_TYPE (foo) = bar;
One instead has to do:
set_type_self_type (foo, bar);
But I've left reading of the type to the macro:
bar = TYPE_SELF_TYPE (foo);
In order to discourage bypassing the TYPE_SELF_TYPE macro
I've named the underlying function that implements it
internal_type_self_type.
While testing this I found the stabs reader leaving methods
as TYPE_CODE_FUNCs, hitting my newly added asserts.
Since the dwarf reader smashes functions to methods (via
smash_to_method) I've done a similar thing for stabs.
gdb/ChangeLog:
* cp-valprint.c (cp_find_class_member): Rename parameter domain_p
to self_p.
(cp_print_class_member): Rename local domain to self_type.
* dwarf2read.c (quirk_gcc_member_function_pointer): Rename local
domain_type to self_type.
(set_die_type) <need_gnat_info>: Handle
TYPE_CODE_METHODPTR, TYPE_CODE_MEMBERPTR, TYPE_CODE_METHOD.
* gdb-gdb.py (StructMainTypePrettyPrinter): Handle
TYPE_SPECIFIC_SELF_TYPE.
* gdbtypes.c (internal_type_self_type): New function.
(set_type_self_type): New function.
(smash_to_memberptr_type): Rename parameter domain to self_type.
Update setting of TYPE_SELF_TYPE.
(smash_to_methodptr_type): Update setting of TYPE_SELF_TYPE.
(smash_to_method_type): Rename parameter domain to self_type.
Update setting of TYPE_SELF_TYPE.
(check_stub_method): Call smash_to_method_type.
(recursive_dump_type): Handle TYPE_SPECIFIC_SELF_TYPE.
(copy_type_recursive): Ditto.
* gdbtypes.h (enum type_specific_kind): New value
TYPE_SPECIFIC_SELF_TYPE.
(struct main_type) <type_specific>: New member self_type.
(struct cplus_struct_type) <fn_field.type>: Update comment.
(TYPE_SELF_TYPE): Rewrite.
(internal_type_self_type, set_type_self_type): Declare.
* gnu-v3-abi.c (gnuv3_print_method_ptr): Rename local domain to
self_type.
(gnuv3_method_ptr_to_value): Rename local domain_type to self_type.
* m2-typeprint.c (m2_range): Replace TYPE_SELF_TYPE with
TYPE_TARGET_TYPE.
* stabsread.c (read_member_functions): Mark methods with
TYPE_CODE_METHOD, not TYPE_CODE_FUNC. Update setting of
TYPE_SELF_TYPE.
gdb/ChangeLog:
* gnu-v3-abi.c (gnuv3_dynamic_class): Assert only passed structs
or unions. Return zero if union.
(gnuv3_get_vtable): Call check_typedef. Assert only passed structs.
(gnuv3_rtti_type): Pass already-check_typedef'd value to
gnuv3_get_vtable.
(compute_vtable_size): Assert only passed structs.
(gnuv3_print_vtable): Don't call gnuv3_get_vtable for non-structs.
This commit adds a new exception, MAX_COMPLETIONS_REACHED_ERROR, to be
thrown whenever the completer has generated too many candidates to
be useful. A new user-settable variable, "max_completions", is added
to control this behaviour. A top-level completion limit is added to
complete_line_internal, as the final check to ensure the user never
sees too many completions. An additional limit is added to
default_make_symbol_completion_list_break_on, to halt time-consuming
symbol table expansions.
gdb/ChangeLog:
PR cli/9007
PR cli/11920
PR cli/15548
* cli/cli-cmds.c (complete_command): Notify user if max-completions
reached.
* common/common-exceptions.h (enum errors)
<MAX_COMPLETIONS_REACHED_ERROR>: New value.
* completer.h (get_max_completions_reached_message): New declaration.
(max_completions): Likewise.
(completion_tracker_t): New typedef.
(new_completion_tracker): New declaration.
(make_cleanup_free_completion_tracker): Likewise.
(maybe_add_completion_enum): New enum.
(maybe_add_completion): New declaration.
(throw_max_completions_reached_error): Likewise.
* completer.c (max_completions): New global variable.
(new_completion_tracker): New function.
(free_completion_tracker): Likewise.
(make_cleanup_free_completion_tracker): Likewise.
(maybe_add_completions): Likewise.
(throw_max_completions_reached_error): Likewise.
(complete_line): Remove duplicates and limit result to max_completions
entries.
(get_max_completions_reached_message): New function.
(gdb_display_match_list): Handle max_completions.
(_initialize_completer): New declaration and function.
* symtab.c: Include completer.h.
(completion_tracker): New static variable.
(completion_list_add_name): Call maybe_add_completion.
(default_make_symbol_completion_list_break_on_1): Renamed from
default_make_symbol_completion_list_break_on. Maintain
completion_tracker across calls to completion_list_add_name.
(default_make_symbol_completion_list_break_on): New function.
* top.c (init_main): Set rl_completion_display_matches_hook.
* tui/tui-io.c: Include completer.h.
(tui_old_rl_display_matches_hook): New static global.
(tui_rl_display_match_list): Notify user if max-completions reached.
(tui_setup_io): Save/restore rl_completion_display_matches_hook.
* NEWS (New Options): Mention set/show max-completions.
gdb/doc/ChangeLog:
* gdb.texinfo (Command Completion): Document new
"set/show max-completions" option.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Disable completion limiting for
existing tests. Add new tests to check completion limiting.
* gdb.linespec/ls-errs.exp: Disable completion limiting.
This commit makes default_make_symbol_completion_list_break_on build
the list of completions as it expands the necessary symbol tables,
rather than expanding all necessary symbol tables first and then
building the completion lists second. This allows for the early
termination of symbol table expansion if required.
gdb/ChangeLog:
* symtab.c (struct add_name_data) <code>: New field.
Updated comments.
(add_symtab_completions): New function.
(symtab_expansion_callback): Likewise.
(default_make_symbol_completion_list_break_on): Set datum.code.
Move minimal symbol scan before calling expand_symtabs_matching.
Scan known primary symtabs for externs and statics before calling
expand_symtabs_matching. Pass symtab_expansion_callback as
expansion_notify argument to expand_symtabs_matching. Do not scan
primary symtabs for externs and statics after calling
expand_symtabs_matching.
This commit adds a new callback parameter, "expansion_notify", to the
top-level expand_symtabs_matching function and to all the vectorized
functions it defers to. If expansion_notify is non-NULL, it will be
called every time a symbol table is expanded.
gdb/ChangeLog:
* symfile.h (expand_symtabs_exp_notify_ftype): New typedef.
(struct quick_symbol_functions) <expand_symtabs_matching>:
New argument expansion_notify. All uses updated.
(expand_symtabs_matching): New argument expansion_notify.
All uses updated.
* symfile-debug.c (debug_qf_expand_symtabs_matching):
Also print expansion notify.
* symtab.c (expand_symtabs_matching_via_partial): Call
expansion_notify whenever a partial symbol table is expanded.
* dwarf2read.c (dw2_expand_symtabs_matching): Call
expansion_notify whenever a symbol table is instantiated.
This copies a lot of code from readline, but this is temporary.
Readline currently doesn't export what we need.
The plan is to have something that has been working for awhile,
and then we'll have a complete story to present to the readline
maintainers.
gdb/ChangeLog:
* cli-out.c: #include completer.h, readline/readline.h.
(cli_mld_crlf, cli_mld_putch, cli_mld_puts): New functions.
(cli_mld_flush, cld_mld_erase_entire_line): Ditto.
(cli_mld_beep, cli_mld_read_key, cli_display_match_list): Ditto.
* cli-out.h (cli_display_match_list): Declare.
* completer.c (MB_INVALIDCH, MB_NULLWCH): New macros.
(ELLIPSIS_LEN): Ditto.
(gdb_get_y_or_n, gdb_display_match_list_pager): New functions.
(gdb_path_isdir, gdb_printable_part, gdb_fnwidth): Ditto.
(gdb_fnprint, gdb_print_filename): Ditto.
(gdb_complete_get_screenwidth, gdb_display_match_list_1): Ditto.
(gdb_display_match_list): Ditto.
* completer.h (mld_crlf_ftype, mld_putch_ftype): New typedefs.
(mld_puts_ftype, mld_flush_ftype, mld_erase_entire_line_ftype): Ditto.
(mld_beep_ftype, mld_read_key_ftype): Ditto.
(match_list_displayer): New struct.
(gdb_display_match_list): Declare.
* top.c (init_main): Set rl_completion_display_matches_hook.
* tui/tui-io.c: #include completer.h.
(printable_part, PUTX, print_filename, get_y_or_n): Delete.
(tui_mld_crlf, tui_mld_putch, tui_mld_puts): New functions.
(tui_mld_flush, tui_mld_erase_entire_line, tui_mld_beep): Ditto.
(tui_mld_getc, tui_mld_read_key): Ditto.
(tui_rl_display_match_list): Rewrite.
(tui_handle_resize_during_io): New arg for_completion. All callers
updated.
gdb/ChangeLog:
Add symbol lookup cache.
* NEWS: Document new options and commands.
* symtab.c (symbol_cache_key): New static global.
(DEFAULT_SYMBOL_CACHE_SIZE, MAX_SYMBOL_CACHE_SIZE): New macros.
(SYMBOL_LOOKUP_FAILED): New macro.
(symbol_cache_slot_state): New enum.
(block_symbol_cache): New struct.
(symbol_cache): New struct.
(new_symbol_cache_size, symbol_cache_size): New static globals.
(hash_symbol_entry, eq_symbol_entry): New functions.
(symbol_cache_byte_size, resize_symbol_cache): New functions.
(make_symbol_cache, free_symbol_cache): New functions.
(get_symbol_cache, symbol_cache_cleanup): New function.
(set_symbol_cache_size, set_symbol_cache_size_handler): New functions.
(symbol_cache_lookup, symbol_cache_clear_slot): New function.
(symbol_cache_mark_found, symbol_cache_mark_not_found): New functions.
(symbol_cache_flush, symbol_cache_dump): New functions.
(maintenance_print_symbol_cache): New function.
(maintenance_flush_symbol_cache): New function.
(symbol_cache_stats): New function.
(maintenance_print_symbol_cache_statistics): New function.
(symtab_new_objfile_observer): New function.
(symtab_free_objfile_observer): New function.
(lookup_static_symbol, lookup_global_symbol): Use symbol cache.
(_initialize_symtab): Init symbol_cache_key. New parameter
maint symbol-cache-size. New maint commands print symbol-cache,
print symbol-cache-statistics, flush-symbol-cache.
Install new_objfile, free_objfile observers.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document new commands
"maint print symbol-cache", "maint print symbol-cache-statistics",
"maint flush-symbol-cache". Document new option
"maint set symbol-cache-size".
gdb/
2015-01-31 Eli Zaretskii <eliz@gnu.org>
* tui/tui-io.c (tui_expand_tabs): New function.
(tui_puts, tui_redisplay_readline): Expand TABs into the
appropriate number of spaces.
* tui/tui-regs.c: Include tui-io.h.
(tui_register_format): Call tui_expand_tabs to expand TABs into
the appropriate number of spaces.
* tui/tui-io.h: Add prototype for tui_expand_tabs.
To make it clear that some functions should not modify the variable
object, this patch adds the const qualifier where it makes sense to some
struct varobj * parameters. Most getters should take a const pointer to
guarantee they don't modify the object.
Unfortunately, I couldn't add it to some callbacks (such as name_of_child).
In the C implementation, they call c_describe_child, which calls
varobj_get_path_expr. varobj_get_path_expr needs to modify the object in
order to cache the computed value. It therefore can't take a const
pointer, and it affects the whole call chain. I suppose that's where you
would use a "mutable" in C++.
I did that to make sure there was no other cases like the one fixed in
the previous patch. I don't think it can hurt.
gdb/ChangeLog:
* ada-varobj.c (ada_number_of_children): Constify struct varobj *
parameter.
(ada_name_of_variable): Same.
(ada_path_expr_of_child): Same.
(ada_value_of_variable): Same.
(ada_value_is_changeable_p): Same.
(ada_value_has_mutated): Same.
* c-varobj.c (varobj_is_anonymous_child): Same.
(c_is_path_expr_parent): Same.
(c_number_of_children): Same.
(c_name_of_variable): Same.
(c_path_expr_of_child): Same.
(get_type): Same.
(c_value_of_variable): Same.
(cplus_number_of_children): Same.
(cplus_name_of_variable): Same.
(cplus_path_expr_of_child): Same.
(cplus_value_of_variable): Same.
* jv-varobj.c (java_number_of_children): Same.
(java_name_of_variable): Same.
(java_path_expr_of_child): Same.
(java_value_of_variable): Same.
* varobj.c (number_of_children): Same.
(name_of_variable): Same.
(is_root_p): Same.
(varobj_ensure_python_env): Same.
(varobj_get_objname): Same.
(varobj_get_expression): Same.
(varobj_get_display_format): Same.
(varobj_get_display_hint): Same.
(varobj_has_more): Same.
(varobj_get_thread_id): Same.
(varobj_get_frozen): Same.
(dynamic_varobj_has_child_method): Same.
(varobj_get_gdb_type): Same.
(is_path_expr_parent): Same.
(varobj_default_is_path_expr_parent): Same.
(varobj_get_language): Same.
(varobj_get_attributes): Same.
(varobj_is_dynamic_p): Same.
(varobj_get_child_range): Same.
(varobj_value_has_mutated): Same.
(varobj_get_value_type): Same.
(number_of_children): Same.
(name_of_variable): Same.
(check_scope): Same.
(varobj_editable_p): Same.
(varobj_value_is_changeable_p): Same.
(varobj_floating_p): Same.
(varobj_default_value_is_changeable_p): Same.
* varobj.h (struct lang_varobj_ops): Consitfy some struct varobj *
parameters.
(varobj_get_objname): Constify struct varobj * parameter.
(varobj_get_expression): Same.
(varobj_get_thread_id): Same.
(varobj_get_frozen): Same.
(varobj_get_child_range): Same.
(varobj_get_display_hint): Same.
(varobj_get_gdb_type): Same.
(varobj_get_language): Same.
(varobj_get_attributes): Same.
(varobj_editable_p): Same.
(varobj_floating_p): Same.
(varobj_has_more): Same.
(varobj_is_dynamic_p): Same.
(varobj_ensure_python_env): Same.
(varobj_default_value_is_changeable_p): Same.
(varobj_value_is_changeable_p): Same.
(varobj_get_value_type): Same.
(varobj_is_anonymous_child): Same.
(varobj_value_get_print_value): Same.
(varobj_default_is_path_expr_parent): Same.
It seems like different languages are doing this differently (e.g.
C and Ada). For C, var->path_expr is set inside c_path_expr_of_child.
The next time the value is requested, is it therefore not recomputed.
Ada does not set this field, but just returns the value. Since the field
is never set, the value is recomputed every time it is requested.
This patch makes it so that path_expr_of_child's only job is to compute
the path expression, not save/cache the value. The field is set by the
varobj common code.
gdb/ChangeLog:
* varobj.c (varobj_get_path_expr): Set var->path_expr.
* c-varobj.c (c_path_expr_of_child): Set local var instead of
child->path_expr.
(cplus_path_expr_of_child): Same.
varobj_get_expression returns an allocated string, which must be freed
by the caller.
gdb/ChangeLog:
* mi-cmd-var.c (print_varobj): Free varobj_get_expression
result.
(mi_cmd_var_info_expression): Same.
* varobj.c (varobj_get_expression): Mention in the comment that
the result must by freed by the caller.
varobj_get_type and type_to_string return an allocated string, which is
not freed at a couple of places.
New in v2:
* Rename char * type to type_name.
* Free in all cases in update_type_if_necessary.
gdb/ChangeLog:
* mi/mi-cmd-var.c (mi_cmd_var_info_type): Free result of
varobj_get_type.
(varobj_update_one): Same.
* varobj.c (update_type_if_necessary): Free curr_type_str and
new_type_str.
(varobj_get_type): Specify in comment that the result needs to be
freed by the caller.
Both dwarf2read.c (checkproducer) and utils.c (producer_is_gcc_ge_4)
implemented a GCC producer parser that tried to extract the major and minor
version of GCC. Merge them into one GCC producer parser used by both. Also
allow digits in the identifier after "GNU " such as used by GCC5 like:
"GNU C11 5.0.0 20150123 (experimental) -mtune=generic -march=x86-64 -gdwarf-5"
gdb/ChangeLog:
* dwarf2read.c (checkproducer): Call producer_is_gcc.
* utils.c (producer_is_gcc_ge_4): Likewise.
(producer_is_gcc): New function.
* utils.h (producer_is_gcc): New declaration.
Consider the following declarations:
type Array_Type is array (Integer range <>) of Integer;
type Record_Type (N : Integer) is record
A : Array_Type (1 .. N);
end record;
R : Record_Type := Get (10);
It defines what Ada programers call a "discriminated record", where
"N" is a component of that record called a "discriminant", and where
"A" is a component defined as an array type whose upper bound is
equal to the value of the discriminant.
So far, we rely on a number of fairly complex GNAT-specific encodings
to handle this situation. This patch is to enhance GDB to be able to
print this record in the case where the compiler has been modified
to replace those encodings by pure DWARF constructs.
In particular, the debugging information generated for the record above
looks like the following. "R" is a record..
.uleb128 0x10 # (DIE (0x13e) DW_TAG_structure_type)
.long .LASF17 # DW_AT_name: "foo__record_type"
... whose is is of course dynamic (not our concern here)...
.uleb128 0xd # DW_AT_byte_size
.byte 0x97 # DW_OP_push_object_address
.byte 0x94 # DW_OP_deref_size
.byte 0x4
.byte 0x99 # DW_OP_call4
.long 0x19b
.byte 0x23 # DW_OP_plus_uconst
.uleb128 0x7
.byte 0x9 # DW_OP_const1s
.byte 0xfc
.byte 0x1a # DW_OP_and
.byte 0x1 # DW_AT_decl_file (foo.adb)
.byte 0x6 # DW_AT_decl_line
... and then has 2 members, fist "n" (our discriminant);
.uleb128 0x11 # (DIE (0x153) DW_TAG_member)
.ascii "n\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file (foo.adb)
.byte 0x6 # DW_AT_decl_line
.long 0x194 # DW_AT_type
.byte 0 # DW_AT_data_member_location
... and "A"...
.uleb128 0x11 # (DIE (0x181) DW_TAG_member)
.ascii "a\0" # DW_AT_name
.long 0x15d # DW_AT_type
.byte 0x4 # DW_AT_data_member_location
... which is an array ...
.uleb128 0x12 # (DIE (0x15d) DW_TAG_array_type)
.long .LASF18 # DW_AT_name: "foo__record_type__T4b"
.long 0x194 # DW_AT_type
... whose lower bound is implicitly 1, and the upper bound
a reference to DIE 0x153 = "N":
.uleb128 0x13 # (DIE (0x16a) DW_TAG_subrange_type)
.long 0x174 # DW_AT_type
.long 0x153 # DW_AT_upper_bound
This patch enhanced GDB to understand references to other DIEs
where the DIE's address is at an offset of its enclosing type.
The difficulty was that the address used to resolve the array's
type (R's address + 4 bytes) is different from the address used
as the base to compute N's address (an offset to R's address).
We're solving this issue by using a stack of addresses rather
than a single address when trying to resolve a type. Each address
in the stack corresponds to each containing level. For instance,
if resolving the field of a struct, the stack should contain
the address of the field at the top, and then the address of
the struct. That way, if the field makes a reference to an object
of the struct, we can retrieve the address of that struct, and
properly resolve the dynamic property references that struct.
gdb/ChangeLog:
* gdbtypes.h (struct dynamic_prop): New PROP_ADDR_OFFSET enum
kind.
* gdbtypes.c (resolve_dynamic_type_internal): Replace "addr"
parameter by "addr_stack" parameter.
(resolve_dynamic_range): Replace "addr" parameter by
"stack_addr" parameter. Update function documentation.
Update code accordingly.
(resolve_dynamic_array, resolve_dynamic_union)
(resolve_dynamic_struct, resolve_dynamic_type_internal): Likewise.
(resolve_dynamic_type): Update code, following the changes made
to resolve_dynamic_type_internal's interface.
* dwarf2loc.h (struct property_addr_info): New.
(dwarf2_evaluate_property): Replace "address" parameter
by "addr_stack" parameter. Adjust function documentation.
(struct dwarf2_offset_baton): New.
(struct dwarf2_property_baton): Update documentation of
field "referenced_type" to be more general. New field
"offset_info" in union data field.
* dwarf2loc.c (dwarf2_evaluate_property): Replace "address"
parameter by "addr_stack" parameter. Adjust code accordingly.
Add support for PROP_ADDR_OFFSET properties.
* dwarf2read.c (attr_to_dynamic_prop): Add support for
DW_AT_data_member_location attributes as well. Use case
statements instead of if/else condition.
gdb/testsuite/ChangeLog:
* gdb.ada/disc_arr_bound: New testcase.
Tested on x86_64-linux, no regression.
This is preparation work to avoid a regression in the Ada/varobj.
An upcoming patch is going to add support for types in DWARF
which have dynamic properties whose value is a reference to another
DIE.
Consider for instance the following declaration:
type Variant_Type (N : Int := 0) is record
F : String(1 .. N) := (others => 'x');
end record;
type Variant_Type_Access is access all Variant_Type;
VTA : Variant_Type_Access := null;
This declares a variable "VTA" which is an access (=pointer)
to a variant record Variant_Type. This record contains two
components, the first being "N" (the discriminant), and the
second being "F", an array whose lower bound is 1, and whose
upper bound depends on the value of "N" (the discriminant).
Of interest to us, here, is that second component ("F"), and
in particular its bounds. The debugging info, and in particular
the info for the array looks like the following...
.uleb128 0x9 # (DIE (0x91) DW_TAG_array_type)
.long .LASF16 # DW_AT_name: "bar__variant_type__T2b"
.long 0xac # DW_AT_GNAT_descriptive_type
.long 0x2cb # DW_AT_type
.long 0xac # DW_AT_sibling
.uleb128 0xa # (DIE (0xa2) DW_TAG_subrange_type)
.long 0xc4 # DW_AT_type
.long 0x87 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x91
... where the upper bound of the array's subrange type is a reference
to "n"'s DIE (0x87):
.uleb128 0x8 # (DIE (0x87) DW_TAG_member)
.ascii "n\0" # DW_AT_name
[...]
Once the patch to handle this dynamic property gets applied,
this is what happens when creating a varobj for variable "VTA"
(whose value is null), and then trying to list its children:
(gdb)
-var-create vta * vta
^done,name="vta",numchild="2",value="0x0",
type="bar.variant_type_access",has_more="0"
(gdb)
-var-list-children 1 vta
^done,numchild="2",
children=[child={name="vta.n",[...]},
child={name="vta.f",exp="f",
numchild="43877616", <<<<-----
value="[43877616]", <<<<-----
type="array (1 .. n) of character"}],
has_more="0"
It has an odd number of children.
In this case, we cannot really determine the number of children,
since that number depends on the value of a field in a record
for which we do not have a value. Up to now, the value we've been
displaying is zero - meaning we have an empty array.
What happens in this case, is that, because the VTA is a null pointer,
we're not able to resolve the pointer's target type, and therefore
end up asking ada_varobj_get_array_number_of_children to return
the number of elements in that array; for that, it relies blindly
on get_array_bounds, which assumes the type is no longer dynamic,
and therefore the reads the bound without seeing that it's value
is actually a reference rather than a resolved constant.
This patch prevents the issue by explicitly handling the case of
dynamic arrays, and returning zero child in that case.
gdb/ChangeLog:
* ada-varobj.c (ada_varobj_get_array_number_of_children):
Return zero if PARENT_VALUE is NULL and parent_type's
range type is dynamic.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_var_array: New testcase.
Tested on x86_64-linux.
Consider the following code:
type Record_Type (N : Integer) is record
A : Array_Type (1 .. N);
end record;
[...]
R : Record_Type := Get (10);
Trying to print the bounds of the array R.A yielded:
(gdb) p r.a'last
$4 = cannot find reference address for offset property
A slightly different example, but from the same cause:
(gdb) ptype r
type = <ref> record
n: integer;
a: array (cannot find reference address for offset property
Looking at the debugging info, "A" is described as...
.uleb128 0x11 # (DIE (0x181) DW_TAG_member)
.ascii "a\0" # DW_AT_name
.long 0x15d # DW_AT_type
[...]
... which is an array...
.uleb128 0x12 # (DIE (0x15d) DW_TAG_array_type)
.long .LASF18 # DW_AT_name: "foo__record_type__T4b"
.long 0x194 # DW_AT_type
.long 0x174 # DW_AT_sibling
... whose bounds are described as:
.uleb128 0x13 # (DIE (0x16a) DW_TAG_subrange_type)
.long 0x174 # DW_AT_type
.long 0x153 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x15d
We can see above that the range has an implict lower value of
1, and an upper value which is a reference 0x153="n". All Good.
But looking at the array's subrange subtype, we see...
.uleb128 0x14 # (DIE (0x174) DW_TAG_subrange_type)
.long 0x153 # DW_AT_upper_bound
.long .LASF19 # DW_AT_name: "foo__record_type__T3b"
.long 0x18d # DW_AT_type
... another subrange type whose bounds are exactly described
the same way. So we have a subrange of a subrange, both with
one bound that's dynamic.
What happens in the case above is that GDB's resolution of "R.A"
yields a array whose index type has static bounds. However, the
subtype of the array's index type was left untouched, so, when
taking the subtype of the array's subrange type, we were left
with the unresolved subrange type, triggering the error above.
gdb/ChangeLog:
* gdbtypes.c (is_dynamic_type_internal) <TYPE_CODE_RANGE>: Return
nonzero if the type's subtype is dynamic.
(resolve_dynamic_range): Also resolve the range's subtype.
Tested on x86_64-linux, no regression.
Compilation of (GDB) 7.9.50.20150127-cvs with (GCC) 5.0.0 20150127
fails with
In file included from symfile.c:32:0:
symfile.c: In function 'unmap_overlay_command':
objfiles.h:628:3: error: 'sec' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
for (osect = objfile->sections; osect < objfile->sections_end; osect++) \
^
symfile.c:3442:23: note: 'sec' was declared here
struct obj_section *sec;
^
cc1: all warnings being treated as errors
make[2]: *** [symfile.o] Error 1
make[2]: Leaving directory `gdb/gdb'
While the bug was reported to GCC as
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64823>,
the attached patch simply initializes sec with NULL.
gdb/ChangeLog:
* symfile.c (unmap_overlay_command): Initialize sec to NULL.
Tested on x86_64-linux.
gdb/ChangeLog:
* NEWS: Mention gdb.Objfile.username.
* python/py-objfile.c (objfpy_get_username): New function.
(objfile_getset): Add "username".
gdb/doc/ChangeLog:
* python.texi (Objfiles In Python): Document Objfile.username.
gdb/testsuite/ChangeLog:
* gdb.python/py-objfile.exp: Add tests for objfile.username.
Add test for objfile.filename, objfile.username after objfile
has been unloaded.
This further improves this testcase to check the output of
our calls to gdb.lookup_type.
gdb/ChangeLog:
* gdb.python/py-lookup-type.exp (test_lookup_type): Change
the second test to print the name attribute of value
returned by the call to gdb.lookup_type, and adjust
the expected output accordingly.
GCC5 defaults to the GNU11 standard for C and warns by default for
implicit function declarations and implicit return types.
https://gcc.gnu.org/gcc-5/porting_to.html
Fixing these issues in the testsuite turns 9 untested and 17 unsupported
testcases into 417 new passes when compiling with GCC5.
gdb/testsuite/ChangeLog:
* gdb.arch/i386-bp_permanent.c (standard): New declaration.
* gdb.base/disp-step-fork.c: Include unistd.h.
* gdb.base/siginfo-obj.c: Include stdio.h.
* gdb.base/siginfo-thread.c: Likewise.
* gdb.mi/non-stop.c: Include unistd.h.
* gdb.mi/nsthrexec.c: Include stdio.h.
* gdb.mi/pthreads.c: Include unistd.h.
* gdb.modula2/unbounded1.c (main): Declare returns int.
* gdb.reverse/consecutive-reverse.c: Likewise.
* gdb.threads/create-fail.c: Include unistd.h.
* gdb.threads/killed.c: Likewise.
* gdb.threads/linux-dp.c: Likewise.
* gdb.threads/non-ldr-exc-1.c: Include stdio.h and string.h.
* gdb.threads/non-ldr-exc-2.c: Likewise.
* gdb.threads/non-ldr-exc-3.c: Likewise.
* gdb.threads/non-ldr-exc-4.c: Likewise.
* gdb.threads/pthreads.c: Include unistd.h.
(main): Declare returns int.
* gdb.threads/tls-main.c (foo): New declaration.
* gdb.threads/watchpoint-fork-mt.c: Define _GNU_SOURCE.
Since Fedora started to use DWZ DWARF compressor:
http://fedoraproject.org/wiki/Features/DwarfCompressor
GDB has slowed down a lot. To make it clear - DWZ is DWARF structure
rearrangement, "compressor" does not mean any zlib style data compression.
This patch reduces LibreOffice backtrace from 5 minutes to 3 seconds (100x)
and it also reduces memory consumption 20x.
[ benchmark is at the bottom of this mail ]
Example of DWZ output:
------------------------------------------------------------------------------
Compilation Unit @ offset 0xc4:
<0><cf>: Abbrev Number: 17 (DW_TAG_partial_unit)
<d0> DW_AT_stmt_list : 0x0
<d4> DW_AT_comp_dir : (indirect string, offset: 0x6f): /usr/src/debug/gdb-7.7.1/build-x86_64-redhat-linux-gnu/gdb
<1><d8>: Abbrev Number: 9 (DW_TAG_typedef)
<d9> DW_AT_name : (indirect string, offset: 0x827dc): size_t
<dd> DW_AT_decl_file : 4
<de> DW_AT_decl_line : 212
<df> DW_AT_type : <0xae>
Compilation Unit @ offset 0xe4:
<0><ef>: Abbrev Number: 13 (DW_TAG_partial_unit)
<f0> DW_AT_stmt_list : 0x0
<f4> DW_AT_comp_dir : (indirect string, offset: 0x6f): /usr/src/debug/gdb-7.7.1/build-x86_64-redhat-linux-gnu/gdb
<1><f8>: Abbrev Number: 45 (DW_TAG_typedef)
<f9> DW_AT_name : (indirect string, offset: 0x251): __off_t
<fd> DW_AT_decl_file : 3
<fe> DW_AT_decl_line : 131
<ff> DW_AT_type : <0x68>
Compilation Unit @ offset 0x62d9f9:
<0><62da04>: Abbrev Number: 20 (DW_TAG_compile_unit)
[...]
<62da12> DW_AT_low_pc : 0x807e10
<62da1a> DW_AT_high_pc : 134
<62da1c> DW_AT_stmt_list : 0xf557e
<1><62da20>: Abbrev Number: 7 (DW_TAG_imported_unit)
<62da21> DW_AT_import : <0xcf> [Abbrev Number: 17]
------------------------------------------------------------------------------
One can see all DW_TAG_partial_unit have DW_AT_stmt_list 0x0 which causes
repeated decoding of that .debug_line unit on each DW_TAG_imported_unit.
This was OK before as each DW_TAG_compile_unit has its own .debug_line unit.
But since the introduction of DW_TAG_partial_unit by DWZ one should cache
read-in DW_AT_stmt_list .debug_line units.
Fortunately one does not need to cache whole
struct linetable *symtab->linetable
and other data from .debug_line mapping PC<->lines
------------------------------------------------------------------------------
Line Number Statements:
Extended opcode 2: set Address to 0x45c880
Advance Line by 25 to 26
Copy
------------------------------------------------------------------------------
as the only part of .debug_line which GDB needs for DW_TAG_partial_unit is:
------------------------------------------------------------------------------
The Directory Table:
../../gdb
/usr/include/bits
[...]
The File Name Table:
Entry Dir Time Size Name
1 1 0 0 gdb.c
2 2 0 0 string3.h
[...]
------------------------------------------------------------------------------
specifically referenced in GDB for DW_AT_decl_file at a single place:
------------------------------------------------------------------------------
fe = &cu->line_header->file_names[file_index - 1];
SYMBOL_SYMTAB (sym) = fe->symtab;
------------------------------------------------------------------------------
This is because for some reason DW_TAG_partial_unit never contains PC-related
DWARF information. I do not know exactly why, the compression ratio is a bit
lower due to it but thanksfully currently it is that way:
dwz.c:
------------------------------------------------------------------------------
/* These attributes reference code, prevent moving
DIEs with them. */
case DW_AT_low_pc:
case DW_AT_high_pc:
case DW_AT_entry_pc:
case DW_AT_ranges:
die->die_ck_state = CK_BAD;
+
/* State of checksum computation. Not computed yet, computed and
suitable for moving into partial units, currently being computed
and finally determined unsuitable for moving into partial units. */
enum { CK_UNKNOWN, CK_KNOWN, CK_BEING_COMPUTED, CK_BAD } die_ck_state : 2;
------------------------------------------------------------------------------
I have also verified also real-world Fedora debuginfo files really comply with
that assumption with dwgrep
https://github.com/pmachata/dwgrep
using:
------------------------------------------------------------------------------
dwgrep -e 'entry ?DW_TAG_partial_unit child* ( ?DW_AT_low_pc , ?DW_AT_high_pc , ?DW_AT_ranges )' /usr/lib/debug/**
------------------------------------------------------------------------------
BTW I think GDB already does not support the whole DW_TAG_imported_unit and
DW_TAG_partial_unit usage possibilities as specified by the DWARF standard.
I think GDB would not work if DW_TAG_imported_unit was used in some inner
level and not at the CU level (readelf -wi level <1>) - this is how DWZ is
using DW_TAG_imported_unit. Therefore I do not think further assumptions
about DW_TAG_imported_unit and DW_TAG_partial_unit usage by DWZ are a problem
for GDB.
One could save the whole .debug_line decoded PC<->lines mapping (and not just
the DW_AT_decl_file table) but:
* there are some problematic corner cases so one could do it incorrectly
* there are no real world data to really test such patch extension
* such extension could be done perfectly incrementally on top of this patch
------------------------------------------------------------------------------
benchmark - on Fedora 20 x86_64 and FSF GDB HEAD:
echo -e 'thread apply all bt\nset confirm no\nq'|./gdb -p `pidof soffice.bin` -ex 'set pagination off' -ex 'maintenance set per-command
space' -ex 'maintenance set per-command symtab' -ex 'maintenance set per-command time'
FSF GDB HEAD ("thread apply all bt"):
Command execution time: 333.693000 (cpu), 335.587539 (wall)
---sec
Space used: 1736404992 (+1477189632 for this command)
----MB
vs.
THIS PATCH ("thread apply all bt"):
Command execution time: 2.595000 (cpu), 2.607573 (wall)
-sec
Space used: 340058112 (+85917696 for this command)
--MB
FSF GDB HEAD ("thread apply all bt full"):
Command execution time: 466.751000 (cpu), 468.345837 (wall)
---sec
Space used: 2330132480 (+2070974464 for this command)
----MB
vs.
THIS PATCH ("thread apply all bt full"):
Command execution time: 18.907000 (cpu), 18.964125 (wall)
--sec
Space used: 364462080 (+110325760 for this command)
---MB
------------------------------------------------------------------------------
gdb/ChangeLog
2015-01-24 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix 100x slowdown regression on DWZ files.
* dwarf2read.c (struct dwarf2_per_objfile): Add line_header_hash.
(struct line_header): Add offset and offset_in_dwz.
(dwarf_decode_lines): Add parameter decode_mapping to the declaration.
(free_line_header_voidp): New declaration.
(line_header_hash, line_header_hash_voidp, line_header_eq_voidp): New
functions.
(dwarf2_build_include_psymtabs): Update dwarf_decode_lines caller.
(handle_DW_AT_stmt_list): Use line_header_hash.
(free_line_header_voidp): New function.
(dwarf_decode_line_header): Initialize offset and offset_in_dwz.
(dwarf_decode_lines): New parameter decode_mapping, use it.
(dwarf2_free_objfile): Free line_header_hash.
In the situation described in bug 17416 [1]:
* "set print object" is on;
* The variable object is a pointer to a struct, and it contains an
invalid value (e.g. NULL, or random uninitialized value);
* The variable object (struct) has a child which is also a pointer to a
struct;
* We try to use "-var-list-children".
... an exception thrown in value_ind can propagate too far and leave an
half-built variable object, leading to a wrong state. This patch adds a
TRY_CATCH to catch it and makes value_rtti_indirect_type return NULL in
that case, meaning that the type of the pointed object could not be
found.
A test for the fix is also added.
New in v2:
* Added test.
* Restructured "catch" code.
* Added details about the bug in commit log.
gdb/Changelog:
* valops.c (value_rtti_indirect_type): Catch exception thrown by
value_ind.
gdb/testsuite/ChangeLog
* gdb.mi/mi-var-list-children-invalid-grandchild.c: New file.
* gdb.mi/mi-var-list-children-invalid-grandchild.exp: New file.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=17416
Add a flag field is_noreturn to struct func_type. Make calling_convention
a small bit field to not increase the size of the struct. Set is_noreturn
if the new GCC5/DWARF5 DW_AT_noreturn is set on a DW_TAG_subprogram.
Use this information to warn the user before doing a finish or return from
a function that does not return normally to its caller.
(gdb) finish
warning: Function endless does not return normally.
Try to finish anyway? (y or n)
(gdb) return
warning: Function does not return normally to caller.
Make endless return now? (y or n)
gdb/ChangeLog
* dwarf2read.c (read_subroutine_type): Set TYPE_NO_RETURN from
DW_AT_noreturn.
* gdbtypes.h (struct func_type): Add is_noreturn field flag. Make
calling_convention an 8 bit bit field.
(TYPE_NO_RETURN): New macro.
* infcmd.c (finish_command): Query if function does not return
normally.
* stack.c (return_command): Likewise.
gdb/testsuite/ChangeLog
* gdb.base/noreturn-return.c: New file.
* gdb.base/noreturn-return.exp: New file.
* gdb.base/noreturn-finish.c: New file.
* gdb.base/noreturn-finish.exp: New file.
include/ChangeLog
* dwarf2.def (DW_AT_noreturn): New DWARF5 attribute.
The dwarf2.h addition and the code to emit the new attribute is already in
the gcc tree.
linux_nat_is_async_p currently always returns true, even when the
target is _not_ async. That confuses
gdb_readline_wrapper/gdb_readline_wrapper_cleanup, which
force-disables target-async while the secondary prompt is active. As
a result, when gdb_readline_wrapper returns, the target is left async,
even through it was sync to begin with.
That can result in weird bugs, like the one the test added by this
commit exposes.
Ref: https://sourceware.org/ml/gdb-patches/2015-01/msg00592.html
gdb/ChangeLog:
2015-01-23 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_is_async_p): New macro.
(linux_nat_is_async_p):
(linux_nat_terminal_inferior): Check whether the target can async
instead of whether it is already async.
(linux_nat_terminal_ours): Don't check whether the target is
async.
(linux_async_pipe): Use linux_is_async_p.
gdb/testsuite/ChangeLog:
2015-01-23 Pedro Alves <palves@redhat.com>
* gdb.threads/continue-pending-after-query.c: New file.
* gdb.threads/continue-pending-after-query.exp: New file.
gdb_interact is a small utility that we have found quite useful to debug
test cases.
Putting gdb_interact in a test suspends it and allows to interact with
gdb to inspect whatever you want. You can then type ">>>" to resume the
test execution. Of course, this is only for gdb devs. It wouldn't make
sense to leave a gdb_interact permanently in a test case.
When starting the interaction with the user, the script prints this
banner:
+------------------------------------------+
| Script interrupted, you can now interact |
| with by gdb. Type >>> to continue. |
+------------------------------------------+
Notes:
* When gdb is launched, the gdb_spawn_id variable (lib/gdb.exp) is
assigned -1. Given the name, I would expect it to contain the gdb
expect spawn id, which is needed for interact. I changed all places
that set gdb_spawn_id to -1 to set it to the actual gdb spawn id
instead.
* When entering the "interact" mode, the last (gdb) prompt is already
eaten by expect, so it doesn't show up on the terminal. Subsequent
prompts do appear though. We tried to print "(gdb)" just before the
interact to replace it. However, it could be misleading if you are
debugging an MI test case, it makes you think that you are typing in a
CLI prompt, when in reality it's MI. In the end I decided that since
the feature is for developers who know what they're doing and that one
is normally consciously using gdb_interact, the script doesn't need
to babysit the user.
* There are probably some quirks depending on where in the script
gdb_interact appears (e.g. it could interfere with following
commands and make them fail), but it works for most cases. Quirks can
always be fixed later.
The idea and original implementation was contributed by Anders
Granlund, a colleague of mine. Thanks to him.
gdb/testsuite/ChangeLog:
* gdb.base/statistics.exp: Assign spawn id to gdb_spawn_id.
* gdb.base/valgrind-db-attach.exp: Same.
* gdb.base/valgrind-infcall.exp: Same.
* lib/mi-support.exp (default_mi_gdb_start): Same.
* lib/prompt.exp (default_prompt_gdb_start): Same.
* lib/gdb.exp (default_gdb_spawn): Same.
(gdb_interact): New.
downstream Fedora request:
Please make it easier to find the backtrace of the crashing thread
https://bugzilla.redhat.com/show_bug.cgi?id=1024504
Currently after loading a core file GDB prints:
Core was generated by `./threadcrash1'.
Program terminated with signal SIGSEGV, Segmentation fault.
8 *(volatile int *)0=0;
(gdb) _
there is nowhere seen which of the threads had crashed. In reality GDB always
numbers that thread as #1 and it is the current thread that time. But after
dumping all the info into a file for later analysis it is no longer obvious.
'thread apply all bt' even puts the thread #1 to the _end_ of the output!!!
I find maybe as good enough and with no risk of UI change flamewar to just
sort the threads by their number. Currently they are printed as they happen
in the internal GDB list which has no advantage. Printing thread #1 as the
first one with assumed 'thread apply all bt' (after the core file is loaded)
should make the complaint resolved I guess.
On Thu, 15 Jan 2015 20:29:07 +0100, Doug Evans wrote:
No objection to sorting the list, but if thread #1 is the important one,
then a concern could be it'll have scrolled off the screen (such a
concern has been voiced in another thread in another context),
and if not lost (say it's in an emacs buffer) one would still have
to scroll back to see it.
So one *could* still want #1 to be last.
Do we want an option to choose the sort direction?
gdb/ChangeLog
2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* NEWS (Changes since GDB 7.9): Add 'thread apply all' option
'-ascending'.
* thread.c (tp_array_compar_ascending, tp_array_compar): New.
(thread_apply_all_command): Parse CMD for tp_array_compar_ascending.
Sort tp_array using tp_array_compar.
(_initialize_thread): Extend thread_apply_all_command help.
gdb/doc/ChangeLog
2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.texinfo (Threads): Describe -ascending for thread apply all.
downstream Fedora request:
Please make it easier to find the backtrace of the crashing thread
https://bugzilla.redhat.com/show_bug.cgi?id=1024504
Currently after loading a core file GDB prints:
Core was generated by `./threadcrash1'.
Program terminated with signal SIGSEGV, Segmentation fault.
8 *(volatile int *)0=0;
(gdb) _
there is nowhere seen which of the threads had crashed. In reality GDB always
numbers that thread as #1 and it is the current thread that time. But after
dumping all the info into a file for later analysis it is no longer obvious.
'thread apply all bt' even puts the thread #1 to the _end_ of the output!!!
Should GDB always print after loading a core file what "thread" command would
print?
[Current thread is 1 (Thread 0x7fcbe28fe700 (LWP 15453))]
BTW I think it will print the thread even when loading single/non-threaded
core file when other inferior(s) exist. But that currently crashes
[Bug threads/12074] multi-inferior internal error
https://sourceware.org/bugzilla/show_bug.cgi?id=12074
plus I think that would be a correct behavior anyway.
gdb/ChangeLog
2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* corelow.c (core_open): Call also thread_command.
* gdbthread.h (thread_command): New prototype moved from ...
* thread.c (thread_command): ... here.
(thread_command): Make it global.
When GDB is configured with "--without-tui --with-curses" or "--with-tui",
$prefer_curses is set to yes. But, that still doesn't mean that curses
will be used. configure will still search for the curses library, and
continue building without it. That's done here:
curses_found=no
if test x"$prefer_curses" = xyes; then
...
AC_SEARCH_LIBS(waddstr, [ncurses cursesX curses])
if test "$ac_cv_search_waddstr" != no; then
curses_found=yes
fi
fi
So if waddstr is not found, meaning curses is not really
available, even though it'd be preferred, $prefer_curses is
'yes', but $curses_found is 'no'.
So the right fix to tell whether we're linking with curses is
$curses_found=yes.
gdb/ChangeLog:
2015-01-22 Pedro Alves <palves@redhat.com>
* configure.ac [*mingw32*]: Check $curses_found instead of
$prefer_curses.
* configure: Regenerate.
* windows-termcap.c: Remove HAVE_CURSES_H, HAVE_NCURSES_H and
HAVE_NCURSES_NCURSES_H checks.
gdb/
2015-01-22 Eli Zaretskii <eliz@gnu.org>
* gdb/tui/tui.c (tui_enable) [__MINGW32__]: If the call to 'newterm'
fails with the 1st arg NULL, try again with "unknown". Don't test
the "cup" capability: it isn't supported by the Windows port of
ncurses, but the Windows console driver is still capable of
supporting TUI.
TBH while I always comment reasons for each of the compilation options in
reality I tried them all and chose that combination that needs the most simple
compile/compile-object-load.c (ld.so emulation) implementation.
gdb/ChangeLog
2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* compile/compile.c (_initialize_compile): Use -fPIE for compile_args.
gdb/testsuite/ChangeLog
2015-01-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.compile/compile.exp (pointer to jit function): New test.
gdb/
2015-01-22 Eli Zaretskii <eliz@gnu.org>
* Makefile.in (HFILES_NO_SRCDIR): Remove ada-varobj.h.
(ALLDEPFILES): Remove irix5-nat.c. These two are part of the
reason that "make TAGS" is broken.
Original working flow has several issues:
- typo issue: "(inst >> 26) == 0x1f && ..." for checking 'stw(m)'.
- "(inst >> 6) == 0xa" needs to be "((inst >> 6) & 0xf) == 0xa".
And also need check additional store instructions:
- For absolute memory: 'stby', 'stdby'.
- For unaligned: 'stwa', 'stda'.
The original code also can be improved:
- Remove redundant double check "(inst >> 26) == 0x1b" for 'stwm'.
- Use 2 'switch' statements instead of all 'if' statements.
* hppa-tdep.c (inst_saves_gr): Fix logical working flow issues
and check additional store instructions.
gdb/
2015-01-17 Eli Zaretskii <eliz@gnu.org>
* configure.ac [*mingw32*]: Only add windows-termcap.o to
CONFIG_OBS if not building with a curses library.
* configure: Regenerate.
* windows-termcap.c: Include defs.h. Make the whole body empty if
either one of HAVE_CURSES_H or HAVE_NCURSES_H or
HAVE_NCURSES_NCURSES_H is defined.
This commit fixes the regression on RHEL-5 systems introduced by
nat/linux-personality.c's check of HAVE_DECL_ADDR_NO_RANDOMIZE.
RHEL-5 systems define HAVE_DECL_ADDR_NO_RANDOMIZE as zero, so we
cannot use #ifndef; instead this patch uses the "#if !" construction.
The regression was reported by Ulrich Weigand here:
<https://sourceware.org/ml/gdb-patches/2015-01/msg00458.html>
gdb/ChangeLog
2015-01-16 Sergio Durigan Junior <sergiodj@redhat.com>
* nat/linux-personality.c: Replace "#ifndef
HAVE_DECL_ADDR_NO_RANDOMIZE" by "#if
!HAVE_DECL_ADDR_NO_RANDOMIZE", fixing a regression in RHEL-5
systems.
gdb/
2015-01-16 Eli Zaretskii <eliz@gnu.org>
* tui/tui-win.c (tui_rehighlight_all, tui_set_var_cmd): New
functions.
(_initialize_tui_win) <border-kind, border-mode>:
<active-border-mode>: Use tui_set_var_cmd as the "set" function.
* tui/tui-win.h: Add prototype for tui_rehighlight_all.
gdb/ChangeLog:
2015-01-16 Eli Zaretskii <eliz@gnu.org>
* tui/tui-win.c (tui_set_tab_width_command): Delete and
recreate the source and the disassembly windows, to show the
effect of the changed tab size immediately.
tui/tui-win.c (tui_scroll_left_command, tui_scroll_right_command):
Doc fix.
doc/gdb.texinfo (TUI Commands): Document the possible
values of NAME argument to 'winheight' command. Explain the
effect of 'tabset' setting better.
gdb/tui/tui-data.h (LINE_PREFIX): Make shorter
(MAX_PID_WIDTH): Enlarge from 14 to 19, to leave enough space for
"Thread NNNNN.XXXX" thread ID notation on Windows.
With gcc-5.0 pre-release one gets:
hppa-tdep.c: In function ‘inst_saves_gr’:
hppa-tdep.c:1406:30: error: comparison of constant ‘9’ with boolean expression is always false [-Werror=bool-compare]
I find the misplaced parentheses obvious.
gdb/ChangeLog
2015-01-16 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix gcc-5 compilation.
* hppa-tdep.c (inst_saves_gr): Fix parentheses typo.
This patch moves the shared code present on
gdb/linux-nat.c:linux_nat_create_inferior and
gdb/gdbserver/linux-low.c:linux_create_inferior to
nat/linux-personality.c. This code is responsible for disabling
address space randomization based on user setting, and using
<sys/personality.h> to do that. I decided to put the prototype of the
maybe_disable_address_space_randomization on nat/linux-osdata.h
because it seemed the best place to put it.
I regression-tested this patch on Fedora 20 x86_64, and found no
regressions.
gdb/ChangeLog
2015-01-15 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (HFILES_NO_SRCDIR): Add nat/linux-personality.h.
(linux-personality.o): New rule.
* common/common-defs.h: Include <stdint.h>.
* config/aarch64/linux.mh (NATDEPFILES): Include
linux-personality.o.
* config/alpha/alpha-linux.mh (NATDEPFILES): Likewise.
* config/arm/linux.mh (NATDEPFILES): Likewise.
* config/i386/linux64.mh (NATDEPFILES): Likewise.
* config/i386/linux.mh (NATDEPFILES): Likewise.
* config/ia64/linux.mh (NATDEPFILES): Likewise.
* config/m32r/linux.mh (NATDEPFILES): Likewise.
* config/m68k/linux.mh (NATDEPFILES): Likewise.
* config/mips/linux.mh (NATDEPFILES): Likewise.
* config/pa/linux.mh (NATDEPFILES): Likewise.
* config/powerpc/linux.mh (NATDEPFILES): Likewise.
* config/powerpc/ppc64-linux.mh (NATDEPFILES): Likewise.
* config/powerpc/spu-linux.mh (NATDEPFILES): Likewise.
* config/s390/linux.mh (NATDEPFILES): Likewise.
* config/sparc/linux64.mh (NATDEPFILES): Likewise.
* config/sparc/linux.mh (NATDEPFILES): Likewise.
* config/tilegx/linux.mh (NATDEPFILES): Likewise.
* config/xtensa/linux.mh (NATDEPFILES): Likewise.
* defs.h: Remove #include <stdint.h> (moved to
common/common-defs.h).
* linux-nat.c: Include nat/linux-personality.h. Remove #include
<sys/personality.h>; do not define ADDR_NO_RANDOMIZE (moved to
nat/linux-personality.c).
(linux_nat_create_inferior): Remove code to disable address space
randomization (moved to nat/linux-personality.c). Create cleanup
to disable address space randomization.
* nat/linux-personality.c: New file.
* nat/linux-personality.h: Likewise.
gdb/gdbserver/ChangeLog
2015-01-15 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (SFILES): Add linux-personality.c.
(linux-personality.o): New rule.
* configure.srv (srv_linux_obj): Add linux-personality.o to the
list of objects to be built.
* linux-low.c: Include nat/linux-personality.h.
(linux_create_inferior): Remove code to disable address space
randomization (moved to ../nat/linux-personality.c). Create
cleanup to disable address space randomization.
This patch moves safe_strerror from the gdb/{posix,mingw}-hdep.c files
to the respective common/{posix,mingw}-strerror.c files. This is a
preparation for the next patch, which shares a common code (to disable
address space randomization when creating a new inferior).
The patch has been regtested on Fedora 20 x86_64, and no regressions
were found.
gdb/ChangeLog
2015-01-15 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (ALLDEPFILES): Including common/mingw-strerror.c and
common/posix-strerror.c.
(posix-strerror.o): New rule.
(mingw-strerror.o): Likewise.
* common/common-utils.h (safe_strerror): Move prototype to here,
from utils.h.
* common/common.host: New file.
* common/mingw-strerror.c: Likewise.
* common/posix-strerror.c: Likewise.
* configure: Regenerated.
* configure.ac: Source common/common.host. Add variable
common_host_obs to gdb_host_obs.
* contrib/ari/gdb_ari.sh: Mention gdb/common/mingw-strerror.c and
gdb/common/posix-strerror.c when warning about the use of
strerror.
* mingw-hdep.c (safe_strerror): Remove definition; move it to
common/mingw-strerror.c.
* posix-hdep.c (safe_strerror): Remove definition; move it to
common/posix-hdep.c.
* utils.h (safe_strerror): Remove prototype; move to
common/common-utils.h.
gdb/gdbserver/ChangeLog
2015-01-15 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (posix-strerror.o): New rule.
(mingw-strerror.o): Likewise.
* configure: Regenerated.
* configure.ac: Source file ../common/common.host. Initialize new
variable srv_host_obs. Add srv_host_obs to GDBSERVER_DEPFILES.
This patch updates two attach tests to use utility procs for checking if
the attach test should run and for launching the program to be attached, as
follows:
1) Use can_spawn_for_attach instead of is_remote target
2) Use spawn_wait_for_attach instead of exec/sleep
Tested (1) with i686-mingw32 host and i686-pc-linux-gnu build/target and
both with x86_64 Ubuntu.
gdb/testsuite/ChangeLog:
* gdb.base/attach-pie-noexec.exp: Use can_spawn_for_attach
instead of checking whether the target board is remote and
use spawn_wait_for_attach instead of exec/sleep.
* gdb.base/attach-twice.exp: Likewise.
Consider the following code:
type Table is array (Positive range <>) of Integer;
type Object (N : Integer) is record
Data : Table (1 .. N);
end record;
My_Object : Object := (N => 3, Data => (3, 5, 8));
Trying to print the range and length of the My_Object.Data array yields:
(gdb) print my_object.data'first
$1 = 1
(gdb) print my_object.data'last
$2 = 0
(gdb) print my_object.data'length
$3 = 0
The first one is correct, and that is thanks to the fact that
the lower bound is statically known. However, for the upper
bound, and consequently the array's length, the values are incorrect.
It should be:
(gdb) print my_object.data'last
$2 = 3
(gdb) print my_object.data'length
$3 = 3
What happens here is that ada_array_bound_from_type sees that
our array has a parallel "___XA" type, and therefore tries to
use it. In particular, it described our array's index type as:
[...]___XDLU_1__n, which means lower bound = 1, and upper bound
is value of "n". Unfortunately, ada_array_bound_from_type does
not have access to the discriminant, and is therefore unable to
compute the bound correctly.
Fortunately, at this stage, the bound has already been computed
a while ago, and therefore doesn't need to be re-computed here.
This patch fixes the issue by ignoring that ___XA type if the array
is marked as already fixed.
This also fixes the same issue with packed arrays.
gdb/ChangeLog:
* ada-lang.c (ada_array_bound_from_type): Ignore array's parallel
___XA type if the array has already been fixed.
gdb/testsuite/ChangeLog:
* gdb.ada/var_arr_attrs: New testcase.
This patch is to teach both GDB and GDBServer to detect 64-bit inferior
correctly. We find a problem that GDBServer is unable to detect on a
e5500 core processor. Current GDBServer assumes that MSR is a 64-bit
register, but MSR is a 32-bit register in Book III-E. This patch is
to fix this problem by checking the right bit in MSR, in order to handle
both Book III-S and Book III-E. In order to detect Book III-S and
Book III-E, we check the PPC_FEATURE_BOOKE from the host's HWCAP (by
getauxval on glibc >= 2.16. If getauxval doesn't exist, we implement
the fallback by parsing /proc/self/auxv), because it should an invariant
on the same machine cross different processes.
In order to share code, I add nat/ppc-linux.c for both GDB and
GDBserver side.
gdb:
2015-01-14 Yao Qi <yao@codesourcery.com>
* Makefile.in (ppc-linux.o): New rule.
* config/powerpc/ppc64-linux.mh (NATDEPFILES): Add ppc-linux.o.
* configure.ac: AC_CHECK_FUNCS(getauxval).
* config.in: Re-generated.
* configure: Re-generated.
* nat/ppc-linux.h [__powerpc64__] (ppc64_64bit_inferior_p):
Declare.
* nat/ppc-linux.c: New file.
* ppc-linux-nat.c (ppc_linux_target_wordsize) [__powerpc64__]:
Call ppc64_64bit_inferior_p.
gdb/gdbserver:
2015-01-14 Yao Qi <yao@codesourcery.com>
* Makefile.in (SFILES): Add nat/ppc-linux.c.
(ppc-linux.o): New rule.
* configure.srv (powerpc*-*-linux*): Add ppc-linux.o.
* configure.ac: AC_CHECK_FUNCS(getauxval).
* config.in: Re-generated.
* configure: Re-generated.
* linux-ppc-low.c (ppc_arch_setup) [__powerpc64__]: Call
ppc64_64bit_inferior_p
When I use PPC_FEATURE_BOOKE in GDBserver, I find it is defined in GDB
but not in GDBserver. After taking a further look, I find some macros
are duplicated between ppc-linux-nat.c and linux-ppc-low.c, so this
patch is to move them into nat/ppc-linux.h.
gdb/gdbserver:
2015-01-14 Yao Qi <yao@codesourcery.com>
* linux-ppc-low.c: Include "nat/ppc-linux.h".
(PPC_FEATURE_HAS_VSX): Move to nat/ppc-linux.h.
(PPC_FEATURE_HAS_ALTIVEC, PPC_FEATURE_HAS_SPE): Likewise.
(PT_ORIG_R3, PT_TRAP): Likewise.
(PTRACE_GETVSXREGS, PTRACE_SETVSXREGS): Likewise.
(PTRACE_GETVRREGS, PTRACE_SETVRREGS): Likewise.
(PTRACE_GETEVRREGS, PTRACE_SETEVRREGS): Likewise.
gdb:
2015-01-14 Yao Qi <yao@codesourcery.com>
* ppc-linux-nat.c (PT_ORIG_R3, PT_TRAP): Move to
nat/ppc-linux.h.
(PPC_FEATURE_CELL, PPC_FEATURE_BOOKE): Likewise.
(PPC_FEATURE_HAS_DFP): Likewise.
(PTRACE_GETVRREGS, PTRACE_SETVRREGS): Likewise.
(PTRACE_GETVSXREGS, PTRACE_SETVSXREGS): Likewise.
(PTRACE_GETEVRREGS, PTRACE_SETEVRREGS): Likewise.
Include "nat/ppc-linux.h".
* nat/ppc-linux.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add nat/ppc-linux.h.
Executing a gdb script that runs the inferior (from the command line
with -x), and has it hit breakpoints with breakpoint commands that
themselves run the target, is currently broken on async targets
(Linux, remote).
While we're executing a command list or a script, we force the
interpreter to be sync, which results in some functions nesting an
event loop and waiting for the target to stop, instead of returning
immediately and having the top level event loop handle the stop.
The issue with this bug is simply that bpstat_do_actions misses
checking whether the interpreter is sync. When we get here, in the
case of executing a script (or, when the interpreter is sync), the
program has already advanced to the next breakpoint, through
maybe_wait_sync_command_done. We need to process its breakpoints
immediately, just like with a sync target.
Tested on x86_64 Fedora 20.
gdb/
2015-01-14 Pedro Alves <palves@redhat.com>
PR gdb/17525
* breakpoint.c: Include "interps.h".
(bpstat_do_actions_1): Also check whether the interpreter is
async.
gdb/testsuite/
2015-01-14 Pedro Alves <palves@redhat.com>
Joel Brobecker <brobecker@adacore.com>
PR gdb/17525
* gdb.base/bp-cmds-execution-x-script.c: New file.
* gdb.base/bp-cmds-execution-x-script.exp: New file.
* gdb.base/bp-cmds-execution-x-script.gdb: New file.
Commit d3d4baed (PR python/17372 - Python hangs when displaying
help()) had the side effect of causing 'gdb -batch' to leave the
terminal in the wrong state if the program was run. E.g,.
$ echo 'main(){*(int*)0=0;}' | gcc -x c -; ./gdb/gdb -batch -ex r ./a.out
Program received signal SIGSEGV, Segmentation fault.
0x00000000004004ff in main ()
$
If you start typing the next command, seemingly nothing happens - GDB
left the terminal with echo disabled.
The issue is that that "r" ends up in fetch_inferior_event, which
calls reinstall_readline_callback_handler_cleanup, which causes
readline to prep the terminal (raw, echo disabled). But "-batch"
causes GDB to exit before the top level event loop is first started,
and then nothing de-preps the terminal.
The reinstall_readline_callback_handler_cleanup function's intro
comment mentions:
"Need to do this as we go back to the event loop, ready to process
further input."
but the implementation forgets the case of when the interpreter is
sync, which indicates we won't return to the event loop yet, or as in
the case of -batch, we have not started it yet.
The fix is to not install the readline callback in that case.
For the test, in this case, checking that command echo still works is
sufficient. Comparing stty output before/after running GDB is even
better. Because stty may not be available, the test tries both ways.
In any case, since expect's spawn (what we use to start gdb) creates a
new pseudo tty, another expect spawn or tcl exec after GDB exits would
not see the wrong terminal settings. So instead, the test spawns a
shell and runs stty and GDB in it.
Tested on x86_64 Fedora 20.
gdb/
2015-01-14 Pedro Alves <palves@redhat.com>
PR cli/17828
* infrun.c (reinstall_readline_callback_handler_cleanup): Don't
reinstall if the interpreter is sync.
gdb/testsuite/
2015-01-14 Pedro Alves <palves@redhat.com>
PR cli/17828
* gdb.base/batch-preserve-term-settings.c: New file.
* gdb.base/batch-preserve-term-settings.exp: New file.
gdb/Changelog:
* objfiles.c (objfile_filename): New function.
* objfiles.h (objfile_filename): Declare it.
(objfile_name): Add function comment.
* python/py-objfile.c (objfpy_lookup_objfile_by_name): Try both the
bfd file name (which may be realpath'd), and the original name.
gdb/testsuite/ChangeLog:
* gdb.python/py-objfile.exp: Test gdb.lookup_objfile on symlinked
binary.
A sanity-check in my release scripts caught something: After having
created the tarballs, I verify that no checked-in file disappeared
in the process, and lo and behod, it found that the following file
got wiped:
- gdb/testsuite/dg-extract-results.py:
And it's not part of the tarball either.
I don't understand while we delete all *.py files in gdb/testsuite,
since I don't see a rule that expected to create one. A run of the
testsuite also doesn't seem to be creating .py files there.
I traced this to the following commit, which unfortunately provided
no explanation. Perhaps we used to run some tests in the gdb/testsuite
directory and caused files to be left behind there. Perhaps we still
do today?
In the meantime, Executive Decision: In order to allow me to create
tarballs without losing files, I removed it. It's easy to put something
back if we find out why it might still be needed.
gdb/testsuite/ChangeLog:
* Makefile.in (clean mostlyclean): Do not delete *.py.
Tested on x86_64-linux by running the src-release.sh script again,
and this time, dg-extract-results.py no longer gets wiped.
Now that the GDB 7.9 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 7.9 branch created (92fc2e6978):
* version.in: Bump version to 7.9.50.DATE-cvs.
The following change...
commit 1994afbf19
Date: Tue Dec 23 07:55:39 2014 -0800
Subject: Look up primitive types as symbols.
... caused the following regression:
% gdb
(gdb) set lang ada
(gdb) python print gdb.lookup_type('character')
Traceback (most recent call last):
File "<string>", line 1, in <module>
gdb.error: No type named character.
Error while executing Python code.
This is because the language_lookup_primitive_type_as_symbol call
was moved to the la_lookup_symbol_nonlocal hook. A couple of
implementations have been upated accordingly, but the Ada version
has not. This patch fixes this omission.
gdb/ChangeLog:
* ada-lang.c (ada_lookup_symbol_nonlocal): If name not found
in static block, then try searching for primitive types.
gdb/testsuite/ChangeLog:
* gdb.python/py-lookup-type.exp: New file.
This patch makes readline append new history lines to the GDB history
file on exit instead of overwriting the entire history file on exit.
This change allows us to run multiple simultaneous GDB sessions without
having each session overwrite the added history of each other session on
exit.
Care must be taken to ensure that the history file doesn't get corrupted
when multiple GDB processes are trying to simultaneously append to and
then truncate it. Safety is achieved in such a situation by using an
intermediate local history file to mutually exclude multiple processes
from simultaneously performing write operations on the global history
file.
gdb/ChangeLog:
* top.h (gdb_add_history): Declare.
* top.c (command_count): New variable.
(gdb_add_history): New function.
(gdb_safe_append_history): New static function.
(quit_force): Call it.
(command_line_input): Use gdb_add_history instead of
add_history.
* event-top.c (command_line_handler): Likewise.
The `machine/setjmp.h' header is no longer present on OS X 10.10, and is
non-standard. Instead, `darwin-nat.c' should be using the standard
`setjmp.h' header.
gdb/ChangeLog:
2015-01-12 James Clarke <jrtc27@jrtc27.com> (tiny patch)
PR gdb/17046
* darwin-nat.c: Replace <machine/setjmp.h> #include by
<setjmp.h> #include.
The previous change to py-prompt.exp made it return without restoring
GDBFLAGS, resulting in breaking the following tests:
$ make check RUNTESTFLAGS="--target_board=native-gdbserver --directory=gdb.python"
...
Running src/gdb/testsuite/gdb.python/py-prompt.exp ...
Running src/gdb/testsuite/gdb.python/py-section-script.exp ...
ERROR: (timeout) GDB never initialized after 10 seconds.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print ('test') to GDB.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print (sys.version_info[0]) to GDB.
ERROR: no fileid for gdbuild
ERROR: Couldn't send python print (sys.version_info[1]) to GDB.
ERROR: no fileid for gdbuild
ERROR: no fileid for gdbuild
...
gdb/testsuite/
2015-01-12 Pedro Alves <palves@redhat.com>
* gdb.python/py-prompt.exp: When the board can't spawn for attach,
restore GDBFLAGS before returning.
for x86_64 -m32 run one gets:
+FAIL: gdb.python/py-frame.exp: test Frame.read_register(rip)
I do not have x32 OS here but the %rip test should PASS there I think.
On Sun, 11 Jan 2015 14:58:06 +0100, Yao Qi wrote:
With your patch applied, this test is skipped on 'x86_64 -m32'. I
prefer to increasing the test coverage, so how about extending the test
for 'x86_64 -m32'? I mean test Frame.read_register(eip)...
gdb/testsuite/ChangeLog
2015-01-12 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.python/py-frame.exp (test Frame.read_register(rip)): Use
is_amd64_regs_target and is_x86_like_target.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (Dwarf): Flag an error if a numeric attribute value
is given without an explicit form.
* gdb.dwarf2/arr-subrange.exp: Specify forms for all numeric
attributes.
* gdb.dwarf/corrupt.exp: Ditto.
* gdb.dwarf2/enum-type.exp: Ditto.
* gdb.trace/entry-values.exp: Ditto.
* gdb.trace/unavailable-dwarf-piece.exp: Ditto.
clear_symtab_users calls breakpoint_re_set before
observer_notify_new_objfile(NULL), and thus symbol lookup
done during breakpoint_re_set will see a stale cache.
Presumably we just need to move the call to observer_notify_new_objfile(NULL)
to before breakpoint_re_set, but need to check for other such issues,
and 7.9 is scheduled to branch tomorrow.
Reverts commits:
b2fb95e006400678a494d98b9ccbcc77087adf50
gdb/ChangeLog:
* symtab.c (eq_symbol_entry): Use SYMBOL_SEARCH_NAME and
symbol_matches_domain for symbol comparisons.
* symtab.c (symbol_cache_mark_found): Improve function comment.
Rename parameter objfile to objfile_context.
(symbol_cache_mark_not_found): Improve function comment.
Add symbol lookup cache.
* NEWS: Document new options and commands.
* symtab.c (symbol_cache_key): New static global.
(DEFAULT_SYMBOL_CACHE_SIZE, MAX_SYMBOL_CACHE_SIZE): New macros.
(SYMBOL_LOOKUP_FAILED): New macro.
(symbol_cache_slot_state): New enum.
(block_symbol_cache): New struct.
(symbol_cache): New struct.
(new_symbol_cache_size, symbol_cache_size): New static globals.
(hash_symbol_entry, eq_symbol_entry): New functions.
(symbol_cache_byte_size, resize_symbol_cache): New functions.
(make_symbol_cache, free_symbol_cache): New functions.
(get_symbol_cache, symbol_cache_cleanup): New function.
(set_symbol_cache_size, set_symbol_cache_size_handler): New functions.
(symbol_cache_lookup, symbol_cache_clear_slot): New function.
(symbol_cache_mark_found, symbol_cache_mark_not_found): New functions.
(symbol_cache_flush, symbol_cache_dump): New functions.
(maintenance_print_symbol_cache): New function.
(maintenance_flush_symbol_cache): New function.
(symbol_cache_stats): New function.
(maintenance_print_symbol_cache_statistics): New function.
(symtab_new_objfile_observer): New function.
(symtab_free_objfile_observer): New function.
(lookup_static_symbol, lookup_global_symbol): Use symbol cache.
(_initialize_symtab): Init symbol_cache_key. New parameter
maint symbol-cache-size. New maint commands print symbol-cache,
print symbol-cache-statistics, flush-symbol-cache.
Install new_objfile, free_objfile observers.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document new commands
"maint print symbol-cache", "maint print symbol-cache-statistics",
"maint flush-symbol-cache". Document new option
"maint set symbol-cache-size".
