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 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.
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.
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.
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.
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.
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.
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.
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.
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.
gdb/ChangeLog:
PR gdb/15830
* NEWS: The "maint demangle" command is renamed as "demangle".
* demangle.c: #include cli/cli-utils.h, language.h.
(demangle_command): New function.
(_initialize_demangle): Add new command "demangle".
* maint.c (maintenance_demangle): Stub out.
(_initialize_maint_cmds): Update help text for "maint demangle",
and mark as deprecated.
gdb/doc/ChangeLog:
* gdb.texinfo (Debugging C Plus Plus): Mention "demangle".
(Symbols): Ditto.
(Maintenance Commands): Delete docs for "maint demangle".
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: Remove references to "maint demangle".
* gdb.cp/demangle.exp: Update. "maint demangle" -> "demangle".
Add tests for explicitly specifying language to demangle.
* gdb.dlang/demangle.exp: Ditto.
This commit adds a non-stop mode test originally inspired by
signal-while-stepping-over-bp-other-thread.exp, that exposes the
thread starvation issues fixed by the previous patches. It sets a set
of threads stepping in parallel, and has one of them get a signal.
Without the previous fixes, this would fail with timeouts.
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.threads/non-stop-fair-events.c: New file.
* gdb.threads/non-stop-fair-events.exp: New file.
This patch fixes the watch_thread_num.exp test to work when the target
is better at making event handling be fair among threads.
I wrote patches that make GDB native and GDBserver event handling
fairer between threads. That is, if threads A and B both
simultaneously trigger some debug event, GDB will pick either A or B
at random, rather than always handling the event of A first. There's
code for that in the Linux backends (gdb and gdbserver) already, but
it can be improved, and only works in all-stop mode.
With those fixes in place, I found that the watch_thread_num.exp would
often time out. The problem is that the test only works _because_
event handling isn't as fair as intended. With the fairness fixes,
the test falls victim of PR10116 (gdb drops watchpoints on
multi-threaded apps) quite often.
To expand on the PR10116 reference, consider that stop events are
serialized to GDB core, through target_wait. Say a thread-specific
watchpoint as set on thread A. When the "right" thread and some other
"wrong" thread both trigger a watchpoint simultaneously, the target
may report the "wrong" thread's hit to GDB first (thread B). When
handling that event, GDB notices the watchpoint is for another thread,
and so shouldn't cause a user-visible stop. On resume, GDB saves the
now current value of the watched expression. Afterwards, the "right"
thread (thread A) reports its watchpoint trigger. But the watched
value hasn't changed since GDB last saved it, and so GDB doesn't
report the watchpoint hit to the user.
The way the test is written, the watchpoint is associated with the
first thread that happens to report an event. It happens that GDB is
processing events much more often for one of the threads, which
usually will be that same first thread.
Hacking the test with "set debug infrun 1", we see exactly that:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c | sort -nr
70 infrun: 8798 [Thread 8798],
37 infrun: 8798 [Thread 8802],
36 infrun: 8798 [Thread 8804],
36 infrun: 8798 [Thread 8803],
35 infrun: 8798 [Thread 8805],
34 infrun: 8798 [Thread 8806],
The first column shows the number of times the target reported an
event for that thread, from:
infrun: target_wait (-1, status) =
infrun: 8798 [Thread 8798],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
This masks out the PR10116 issue.
However, if the target is better at giving equal priority to all
threads, the PR10116 issue happens often, so it may take quite a while
for the right thread to be the first to report its watchpoint event
just after the memory being watched really changed, resulting in test
time outs.
Here's the number of events handled for each thread on a gdbserver run
with the event fairness patches:
$ grep "infrun.*\[Thread.*," gdb.log | sort | uniq -c
2961 infrun: 13591 [Thread 13591],
2956 infrun: 13591 [Thread 13595],
2941 infrun: 13591 [Thread 13596],
2932 infrun: 13591 [Thread 13597],
2905 infrun: 13591 [Thread 13598],
2891 infrun: 13591 [Thread 13599],
Note how the number of events is much higher. The test routinely
takes over 10 seconds to finish on my machine rather than under a
second as with unpatched gdbserver, when it succeeds, but often it'll
fail with timeouts too.
So to make the test robust, this patch switches the tests to using
"awatch" instead of "watch", as access watchpoints don't care about
the watchpoint's "old value". With this, the test always finishes
quickly, and we can even bump the number of threads concurrently
writting to the shared variable, to have better assurance we're really
testing the case of the "wrong" thread triggering a watchpoint.
Here's the number of events I see for each thread on a run on my
machine, with a gdbserver patched with the event fairness series:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c
5 infrun: 5298 [Thread 5302],
4 infrun: 5298 [Thread 5303],
4 infrun: 5298 [Thread 5304],
4 infrun: 5298 [Thread 5305],
4 infrun: 5298 [Thread 5306],
4 infrun: 5298 [Thread 5307],
4 infrun: 5298 [Thread 5308],
4 infrun: 5298 [Thread 5309],
4 infrun: 5298 [Thread 5310],
4 infrun: 5298 [Thread 5311],
4 infrun: 5298 [Thread 5312],
4 infrun: 5298 [Thread 5313],
4 infrun: 5298 [Thread 5314],
4 infrun: 5298 [Thread 5315],
4 infrun: 5298 [Thread 5316],
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (thread_test): Use srcfile and binfile from
the global scope. Set a breakpoint after all threads are started
rather than stepping over two source lines. Expect the prompt.
* gdb.base/watch_thread_num.c (threads_started_barrier): New
global.
(NUM): Now 15.
(main): Use threads_started_barrier to wait for all threads to
start. Main thread no longer calls thread_function. Exit after
180 seconds.
(loop): New function.
(thread_function): Wait on threads_started_barrier barrier. Call
'loop' at each iteration.
* gdb.base/watch_thread_num.exp: Continue to breakpoint after all
threads have started, instead of hardcoding number of "next"
steps. Use an access watchpoint instead of a write watchpoint.
These three test all spawn a few threads and then send a SIGSTOP to
their parent GDB in order to pause it while the new threads set things
up for the test. With a GDB patch that changes the inferior thread's
scheduling a bit, I sometimes see:
FAIL: gdb.threads/siginfo-threads.exp: catch signal 0 (timeout)
...
FAIL: gdb.threads/watchthreads-reorder.exp: reorder1: continue a (timeout)
...
FAIL: gdb.threads/ia64-sigill.exp: continue (timeout)
...
The issue is that the test program stops GDB before it had a chance of
processing the new thread's clone event:
(gdb) PASS: gdb.threads/siginfo-threads.exp: get pid
continue
Continuing.
Stopping GDB PID 21541.
Waiting till the threads initialize their TIDs.
FAIL: gdb.threads/siginfo-threads.exp: catch signal 0 (timeout)
On Linux (at least), new threads start stopped, and the debugger must
resume them. The fix is to make the test program wait for the new
threads to be running before stopping GDB.
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.threads/ia64-sigill.c (threads_started_barrier): New global.
(thread_func): Wait on barrier.
(main): Wait for all threads to start before stopping GDB.
* gdb.threads/siginfo-threads.c (threads_started_barrier): New
global.
(thread1_func, thread2_func): Wait on barrier.
(main): Wait for all threads to start before stopping GDB.
* gdb.threads/watchthreads-reorder.c (threads_started_barrier):
New global.
(thread1_func, thread2_func): Wait on barrier.
(main): Wait for all threads to start before stopping GDB.
Before the previous fixes, on Linux, this would trigger several
different problems, like:
[New LWP 27106]
[New LWP 27047]
warning: unable to open /proc file '/proc/-1/status'
[New LWP 27813]
[New LWP 27869]
warning: Can't attach LWP 11962: No child processes
Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: debugger service failed
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.threads/attach-many-short-lived-threads.c: New file.
* gdb.threads/attach-many-short-lived-threads.exp: New file.
[A test I wrote stumbled on a libthread_db issue related to thread
event breakpoints. See glibc PR17705:
[nptl_db: stale thread create/death events if debugger detaches]
https://sourceware.org/bugzilla/show_bug.cgi?id=17705
This patch avoids that whole issue by making GDB stop using thread
event breakpoints in the first place, which is good for other reasons
as well, anyway.]
Before PTRACE_EVENT_CLONE (Linux 2.6), the only way to learn about new
threads in the inferior (to attach to them) or to learn about thread
exit was to coordinate with the inferior's glibc/runtime, using
libthread_db. That works by putting a breakpoint at a magic address
which is called when a new thread is spawned, or when a thread is
about to exit. When that breakpoint is hit, all threads are stopped,
and then GDB coordinates with libthread_db to read data structures out
of the inferior to learn about what happened. Then the breakpoint is
single-stepped, and then all threads are re-resumed. This isn't very
efficient (stops all threads) and is more fragile (inferior's thread
list in memory may be corrupt; libthread_db bugs, etc.) than ideal.
When the kernel supports PTRACE_EVENT_CLONE (which we already make use
of), there's really no need to use libthread_db's event reporting
mechanism to learn about new LWPs. And if the kernel supports that,
then we learn about LWP exits through regular WIFEXITED wait statuses,
so no need for the death event breakpoint either.
GDBserver has been likewise skipping the thread_db events for a long
while:
https://sourceware.org/ml/gdb-patches/2007-10/msg00547.html
There's one user-visible difference: we'll no longer print about
threads being created and exiting while the program is running, like:
[Thread 0x7ffff7dbb700 (LWP 30670) exited]
[New Thread 0x7ffff7db3700 (LWP 30671)]
[Thread 0x7ffff7dd3700 (LWP 30667) exited]
[New Thread 0x7ffff7dab700 (LWP 30672)]
[Thread 0x7ffff7db3700 (LWP 30671) exited]
[Thread 0x7ffff7dcb700 (LWP 30668) exited]
This is exactly the same behavior as when debugging against remote
targets / gdbserver. I actually think that's a good thing (and as
such have listed this in the local/remote parity wiki page a while
ago), as the printing slows down the inferior. It's also a
distraction to keep bothering the user about short-lived threads that
she won't be able to interact with anyway. Instead, the user (and
frontend) will be informed about new threads that currently exist in
the program when the program next stops:
(gdb) c
...
* ctrl-c *
[New Thread 0x7ffff7963700 (LWP 7797)]
[New Thread 0x7ffff796b700 (LWP 7796)]
Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7ffff796b700 (LWP 7796)]
clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:81
81 testq %rax,%rax
(gdb) info threads
A couple of tests had assumptions on GDB thread numbers that no longer
hold.
Tested on x86_64 Fedora 20.
gdb/
2014-01-09 Pedro Alves <palves@redhat.com>
Skip enabling event reporting if the kernel supports
PTRACE_EVENT_CLONE.
* linux-thread-db.c: Include "nat/linux-ptrace.h".
(thread_db_use_events): New function.
(try_thread_db_load_1): Check thread_db_use_events before enabling
event reporting.
(update_thread_state): New function.
(attach_thread): Use it. Check thread_db_use_events before
enabling event reporting.
(thread_db_detach): Check thread_db_use_events before disabling
event reporting.
(find_new_threads_callback): Check thread_db_use_events before
enabling event reporting. Update the thread's state if not using
libthread_db events.
gdb/testsuite/
2014-01-09 Pedro Alves <palves@redhat.com>
* gdb.threads/fork-thread-pending.exp: Switch to the main thread
instead of to thread 2.
* gdb.threads/signal-command-multiple-signals-pending.c (main):
Add barrier around each pthread_create call instead of around all
calls.
* gdb.threads/signal-command-multiple-signals-pending.exp (test):
Set a break on thread_function and have the child threads hit it
one at at a time.
We already skip "attach" tests if the target board is remote, in
dejagnu's sense, as we use TCL's exec to spawn the program on the
build machine. We should also skip these tests if testing with
"target remote" or other stub-like targets where "attach" doesn't make
sense.
Add a helper procedure that centralizes the checks a test that needs
to spawn a program for testing "attach" and make all test files that
use spawn_wait_for_attach check it.
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (can_spawn_for_attach): New procedure.
(spawn_wait_for_attach): Error out if can_spawn_for_attach returns
false.
* gdb.base/attach.exp: Use can_spawn_for_attach instead of
checking whether the target board is remote.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Use can_spawn_for_attach before the
tests that need to attach, instead of checking whether the target
board is remote at the top of the file.
The test entry-values.exp doesn't recognize the call instructions
on MIPS, such as JAL, JALS and etc, so this patch sets call_insn
to match various jump and branch instructions first.
Currently, we assume the next instruction address of call instruction
is the address returned from foo, however it is not correct on MIPS
which has delay slot. We extend variable call_insn to match one
instruction after jump or branch instruction, so that
$returned_from_foo is correct on MIPS.
All tests in entry-values.exp are PASS.
gdb/testsuite:
2015-01-08 Yao Qi <yao@codesourcery.com>
* gdb.trace/entry-values.exp: Set call_insn for MIPS target.
The following python command fails:
(gdb) python print gdb.lookup_type('char').array(1, 0)
Traceback (most recent call last):
File "<string>", line 1, in <module>
ValueError: Array length must not be negative
Error while executing Python code.
The above is trying to create an empty array, which is fairly command
in Ada.
gdb/ChangeLog:
* python/py-type.c (typy_array_1): Do not raise negative-length
exception if N2 is equal to N1 - 1.
gdb/testsuite/ChangeLog:
* gdb.python/py-type.exp: Add a couple test about empty
array creation, and negative-length array creation.
This patch is to clean up gdb.trace/entry-values.exp as a preparation
of the next patch. It updates the comments to reflect the code.
One DIE generated in dwarf assembler is
GNU_call_site {
{low_pc "$bar_start + $bar_call_foo" addr}
{abstract_origin :$foo_label}
the DW_AT_low_pc attribute is the return address after the call, so I
rename variable bar_call_foo to returned_from_foo.
gdb/testsuite:
2014-12-29 Yao Qi <yao@codesourcery.com>
* gdb.trace/entry-values.exp: Update comments. Rename variable
bar_call_foo to returned_from_foo.
This patch fixes a problem when trying to insert a breakpoint on
a specific symbol defined in a specific file, eg:
break foo.c:func
This currently works for files in C/C++/Ada, etc, but doesn't always
work for Asm files. Analysis of the problem showed that this related
to a limitation in gas, which does not generate debug info for functions/
symbols. Thus, we have a symtab for the file ("info sources" shows
the file), but it contains no symbols.
When find_linespec_symbols is called in linespec_parse_basic, it calls
find_function_symbols, which uses add_matching_symbols_to_info to
collect all matching symbols.
That function does [pardon any mangled formatting]:
for (ix = 0; VEC_iterate (symtab_ptr, info->file_symtabs, ix, elt); ++ix)
{
if (elt == NULL)
{
iterate_over_all_matching_symtabs (info->state, name, VAR_DOMAIN,
collect_symbols, info,
pspace, 1);
search_minsyms_for_name (info, name, pspace);
}
else if (pspace == NULL || pspace == SYMTAB_PSPACE (elt))
{
/* Program spaces that are executing startup should have
been filtered out earlier. */
gdb_assert (!SYMTAB_PSPACE (elt)->executing_startup);
set_current_program_space (SYMTAB_PSPACE (elt));
iterate_over_file_blocks (elt, name, VAR_DOMAIN,
collect_symbols, info);
}
}
This iterates over the symtabs. In the failing use case, ELT is
non-NULL (points to the symtab for the .s file), so it calls
iterate_over_file_blocks. Herein is where the problem exists: it is
assumed that if NAME exists, it must exist in the given symtab -- a
reasonable assumption for "normal" (non-asm) cases. It never searches
minimal symbols (or in the global default symtab).
This patch fixes the problem by doing so. It is important to note that
iterating over minsyms is fairly expensive, so this patch only adds
that extra search if the language is language_asm and
iterate_over_file_blocks returns no symbols.
gdb/ChangeLog:
2014-12-20 Keith Seitz <keiths@redhat.com>
Mihail-Marian Nistor <mihail.nistor@freescale.com>
PR gdb/17394
* linespec.c (struct collect_minsyms): Add new member `symtab'.
(add_minsym): Handle cases where info.symtab is non-NULL.
(search_minsyms_for_name): Add new parameter `symtab'.
Handle limiting searches to a specific symtab.
(add_matching_symtabs_to_info): Search through minimal symbols
for language_asm files for which no new symbols are found.
gdb/testsuite/ChangeLog:
2014-12-20 Mihail-Marian Nistor <mihail.nistor@freescale.com>
PR gdb/17394
* gdb.linespec/break-asm-file.c: New file.
* gdb.linespec/break-asm-file.exp: New file.
* gdb.linespec/break-asm-file0.s: New file.
* gdb.linespec/break-asm-file1.s: New file.
This patch is the V2. V1 can be found in
https://sourceware.org/ml/gdb-patches/2012-05/msg00938.html
V2 is to address Joel's comment
<https://sourceware.org/ml/gdb-patches/2012-06/msg00289.html> about
keeping dumping floating point registers. Additionally, command
'info float' prints bits on nan2008 and abs2008.
------------------------------------------------------------------
The change below provides a MIPS-specific handler for the:
(gdb) info float
command. It provides information about the FPU type available (if any),
the FPU register width, and decodes the CP1 Floating Point Control and
Status Register (FCSR):
(gdb) print /x $fsr
$1 = 0xff83ffff
(gdb) info float
fpu type: double-precision
reg size: 32 bits
cond : 0 1 2 3 4 5 6 7
cause : inexact uflow oflow div0 inval unimp
mask : inexact uflow oflow div0 inval
flags : inexact uflow oflow div0 inval
rounding: -inf
flush : zero
One point to note about CP1.FCSR are the non-standard Flush-to-Nearest
and Flush-Override bits. They are not a part of the MIPS architecture and
take two positions reserved for an implementation-dependent use in the
architecture. They are present in all the FPU implementations made by
MIPS Technologies since the spin-off from SGI.
I haven't been able to track down a single other MIPS FPU implementation
that would make any use of these bits and they are required to be
hardwired to zero by the architecture specification if unimplemented.
Therefore I think it makes sense to report them in the current way.
GDB has no guaranteed access to the CP0 Processor Identification (PRId)
register to validate this feature properly and the ID information stored
in the CP1 Floating Point Implementation Register (FIR) is from my
experience not reliable enough (there's no Company ID available there for
once unlike in CP0.PRId and Processor ID is not guaranteed to be unique).
As a side note we should probably dump CP1.FIR information as well, as
there's useful stuff indicating some FPU features there. That's material
for another change however.
gdb/
2014-12-18 Nigel Stephens <nigel@mips.com>
Maciej W. Rozycki <macro@codesourcery.com>
* mips-tdep.c (print_fpu_flags): New function.
(mips_print_float_info): Likewise.
(mips_gdbarch_init): Install mips_print_float_info as gdbarch
print_float_info routine.
gdb/testsuite/
2014-12-18 Nigel Stephens <nigel@mips.com>
Maciej W. Rozycki <macro@codesourcery.com>
* gdb.base/float.exp: Handle the new output from "info float" on
MIPS targets.
On Sun, 14 Dec 2014 07:00:28 +0100, Yao Qi wrote:
The build on mingw host is broken because mingw has no mkdtemp.
../../../git/gdb/compile/compile.c: In function 'get_compile_file_tempdir':
../../../git/gdb/compile/compile.c:194:3: error: implicit declaration of function 'mkdtemp' [-Werror=implicit-function-declaration]
tempdir_name = mkdtemp (tname);
^
../../../git/gdb/compile/compile.c:194:16: error: assignment makes pointer from integer without a cast [-Werror]
tempdir_name = mkdtemp (tname);
^
cc1: all warnings being treated as errors
In the end I have managed to test it by Wine myself:
$ wine build_win32/gdb/gdb.exe -q build_win32/gdb/gdb.exe -ex start -ex 'compile code 1' -ex 'set confirm no' -ex quit
[...]
Temporary breakpoint 1, main (argc=1, argv=0x241418) at ../../gdb/gdb.c:29
29 args.argc = argc;
Could not load libcc1.so: Module not found.
Even if it managed to load libcc1.so (it needs host-dependent name libcc1.dll)
then it would soon end up at least on:
default_infcall_mmap:
error (_("This target does not support inferior memory allocation by mmap."));
As currently there is only:
linux-tdep.c:
set_gdbarch_infcall_mmap (gdbarch, linux_infcall_mmap);
While one could debug Linux targets from MS-Windows host I find it somehow
overcomplicated now when we are trying to get it running at least on native
Linux x86*.
The 'compile' project needs a larger port effort to run on MS-Windows.
gdb/ChangeLog
2014-12-17 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix MinGW compilation.
* compile/compile.c (get_compile_file_tempdir): Call error if
!HAVE_MKDTEMP.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac (AC_CHECK_FUNCS): Add mkdtemp.
gdb/testsuite/ChangeLog
2014-12-17 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix MinGW compilation.
* gdb.compile/compile-ops.exp: Update untested message if
!skip_compile_feature_tests.
* gdb.compile/compile-setjmp.exp: Likewise.
* gdb.compile/compile-tls.exp: Likewise.
* gdb.compile/compile.exp: Likewise.
* lib/gdb.exp (skip_compile_feature_tests): Check also "Command not
supported on this host".
This fixes a failure of the test case "complete 'info registers '" in
completion.exp on architectures where the user registers have numbers
above 99. In that case the output of "maint print user-registers" was
no longer indented, and the regexp in the test case failed to add them
to the list of expected completion results. The fix also swaps the
columns "Name" and "Nr", such that the indentation is always the same,
and to be consistent with the output of "maint print registers".
gdb/ChangeLog:
* user-regs.c (maintenance_print_user_registers): Swap "Nr" and
"Name" columns. Assure that the output is always indented.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Adjust to format changes of "maint
print user-registers".
When using aarch64 gdb with gdbserver, floating point registers are
not correctly displayed, as below:
(gdb) info registers fpsr fpcr
fpsr <unavailable>
fpcr <unavailable>
To fix these problems, the missing fpsr and fpcr registers are added
when floating point registers are read/write
Add test for aarch64 floating point
PR server/17457
gdb/gdbserver/
PR server/17457
* linux-aarch64-low.c (AARCH64_FPSR_REGNO): New define.
(AARCH64_FPCR_REGNO): Likewise.
(AARCH64_NUM_REGS): Update to include fpsr/fpcr registers.
(aarch64_fill_fpregset): Add missing fpsr/fpcr registers.
(aarch64_store_fpregset): Likewise.
gdb/testsuite/
PR server/17457
* gdb.arch/aarch64-fp.c: New file.
* gdb.arch/aarch64-fp.exp: New file.
Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
It has been a while since we don't sync this file with GCC upstream,
and in the meantime some interesting things have happened. The most
interesting is the inclusion of a new dg-extract-results.py which is
apparently faster than its shell equivalent.
This merge will probably fix the bug described in
<https://sourceware.org/ml/gdb-patches/2014-12/msg00421.html>
Though I am still proposing the patch for upstream GCC. Once it gets
accepted, I will merge it too.
OK to apply?
gdb/testsuite/ChangeLog:
2014-12-15 Sergio Durigan Junior <sergiodj@redhat.com>
Merge dg-extract-results.{sh,py} from GCC upstream (r210243,
r210637, r210913, r211666, r215400, r215817).
2014-05-08 Richard Sandiford <rdsandiford@googlemail.com>
* dg-extract-results.py: New file.
* dg-extract-results.sh: Use it if the environment seems
suitable.
2014-05-20 Richard Sandiford <rdsandiford@googlemail.com>
* dg-extract-results.py (parse_run): Handle warnings that
are printed before a test harness is run.
2014-05-25 Richard Sandiford <rdsandiford@googlemail.com>
* dg-extract-results.py (Named): Remove __cmp__ method.
(output_variation): Use a key to sort variation.harnesses.
2014-06-14 Richard Sandiford <rdsandiford@googlemail.com>
* dg-extract-results.py: For Python 3, force sys.stdout to
handle surrogate escape sequences.
(safe_open): New function.
(output_segment, main): Use it.
2014-09-19 Segher Boessenkool <segher@kernel.crashing.org>
* dg-extract-results.py (Prog.result_re): Include options
in test name.
2014-10-02 Segher Boessenkool <segher@kernel.crashing.org>
* dg-extract-results.py (output_variation): Always sort if
do_sum.
When gdb starts, the lines that appear before the first prompt may get
paginated if the terminal in which the tests are ran is too small (in
terms of rows). These lines include the welcome/license message and
possibly more, such as "Reading symbols from...". Pagination is disabled
right after gdb is started (with "set height 0"), but this output happens
before we are able to set height.
If these lines get paginated, gdb waits for the user to press enter and
the test harness waits for gdb to print its prompt, resulting in a
deadlock.
My first idea was to launch gdb with --quiet. However, some lines are
still printed ("Reading symbols from...", some more stuff when attaching
with --pid, etc).
The proposed solution simply expects that pagination can occur after
starting gdb. If this is the case, it sends a "\n" and loops.
gdb/testsuite/Changelog:
* lib/gdb.exp (default_gdb_start): After starting gdb, loop
as long as we get pagination notifications.
Doug Evans
Gary Benson
Joel Brobecker
Doug Evans
Mark Wielaard
Simon Marchi
Pedro Alves
Anders Granlund
Jan Kratochvil
Wei-cheng Wang
Don Breazeal
Yao Qi
Mihail-Marian Nistor
Andreas Arnez
Catalin Udma
Sergio Durigan Junior
Jason Merrill