This fills out a few of the test places where needed for Blackfin targets.
Signed-off-by: Jie Zhang <jie.zhang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Comment says it all. I just felt that putting some new text in
a separate paragraph allowed us to clearly identify the section
about ELFOSABI_NONE, and the part that talks about the new
ELFOSABI_GNU.
gdb/ChangeLog:
* osabi.c (generic_elf_osabi_sniffer): Minor comment reformatting.
The mapping between Ada tasks, and the underlying threads is
normally maintained by the GNAT runtime under the known_tasks
array. For performance reasons, this array is just a static
array with 10_000 entries in it. However, this is not very
practical in certain environments where memory is limited.
For those environments, the runtime has been enhanced to use
an alternate scheme with a linked list.
This change enhances the Ada tasking support to recognize this
situation and use the correct way of reading the tasks info
based on the the situation.
gdb/ChangeLog (Tristan Gingold)
* ada-tasks.c (KNOWN_TASKS_LIST): New macro.
(tcb_fieldno): Add activation_link field.
(get_known_tasks_addr): Moved and rewritten.
(get_tcb_types_info): Set activation_link field.
(read_known_tasks_array): Add parameter. Rewritten.
(read_known_tasks_list): New function.
(read_known_tasks): New function.
(ada_build_task_list): Call read_known_tasks instead of
read_known_tasks_array.
* ravenscar-thread.c: Add first_task_name constant.
(has_ravenscar_runtime): Check for task list too.
Just some minor cleanup changes in preparation for an upcoming
change...
gdb/ChangeLog (Tristan Gingold)
* ada-tasks.c: Renames fieldno to actb_fieldno.
(ada_get_task_number): Indentation.
(get_tcb_types_info): Remove all parameters. Write directly
the globals.
(ptid_from_atcb_common): Adjust.
(read_atcb): Adjust.
We don't need to read the .eh_frame section from the separate
object files, because this data is already present in the
main executable (it needs to, or the program wouldn't work).
We discovered this investigating a problem with the 'next' command,
which was due to unwind failures, which came from the fact that
the .eh_frame was incorrectly relocated.
gdb/ChangeLog (Tristan Gingold):
* dwarf2-frame.c (dwarf2_build_frame_info): Do not load .eh_frame
section in separate object files.
* gdb.cp/m-static.exp: Call get_compiler_info.
(static const int initialized nowhere): Call setup_xfail for gcc <= 4.4.
* gdb.cp/pr9167.exp (p b): Likewise.
* gdb.cp/temargs.exp: Do not set have_pr_45024_fixed for gcc 4.6.
(test value of P in inner_m, test type of Z in inner_m): Call
setup_xfail for gcc <= 4.5.
* linespec.c (find_method): Accept the function type automatically only
if it was specified with parameter types.
gdb/testsuite/
* gdb.cp/paren-type.cc: New files.
* gdb.cp/paren-type.exp: New files.
Stop on first linespec terminator instead of eating what we can.
* linespec.c (is_linespec_boundary): New function.
(name_end): Remove function.
(keep_name_info): New parameter on_boundary, replace the body.
(decode_line_1): Provide the parameter to keep_name_info.
(decode_compound): Likewise. Drop the trailing java return type
handling. Twice.
gdb/testsuite/
Stop on first linespec terminator instead of eating what we can.
* gdb.cp/minsym-fallback-main.cc (main): Call also C::operator ().
* gdb.cp/minsym-fallback.cc (C::operator ()): Define.
* gdb.cp/minsym-fallback.exp (break 'C::f()'): Change to ...
(break C::f()): ... this one.
(break C::operator()()): New test.
* gdb.cp/minsym-fallback.h (C::operator ()): Declare.
* gdb.java/jmisc.exp (break jmisc.main(java.lang.String[])int): New
test.
Fall back linespec to minimal symbols.
* linespec.c (decode_line_1): New variable ex, saved_argptr. Protect
decode_compound by TRY_CATCH, fall back on minsyms if it failed.
(find_method, symbol_found): Change error to cplusplus_error.
gdb/testsuite/
Fall back linespec to minimal symbols.
* gdb.base/psymtab.exp (Don't search past end of psymtab.): Update the
error message.
* gdb.cp/cplusfuncs.exp (list foo::operator int*): Likewise.
* gdb.cp/minsym-fallback-main.cc: New file.
* gdb.cp/minsym-fallback.cc: New file.
* gdb.cp/minsym-fallback.exp: New file.
* gdb.cp/minsym-fallback.h: New file.
* dwarf2read.c (check_physname): New variable.
(dwarf2_physname): Prefer DW_AT_linkage_name over dwarf2_compute_name.
(show_check_physname): New function.
(_initialize_dwarf2_read): Add `check-physname' for check_physname.
gdb/doc/
* gdb.texinfo (Debugging Output): Document set debug
check-physname.
gdb/testsuite/
* gdb.base/break-interp.exp (reach_1, test_ld): Allow also the prefix
__GI_.
* gdb.cp/psymtab-parameter.cc (func): Make it a template function.
(f): New function.
* gdb.cp/psymtab-parameter.exp (complete break 'func(): Rename to ...
(complete p 'func<short>(): ... here.
* gdb.dwarf2/dw2-linkage-name-trust-main.cc: New file.
* gdb.dwarf2/dw2-linkage-name-trust.S: New file.
* gdb.dwarf2/dw2-linkage-name-trust.exp: New file.
* gdb.cp/temargs.exp (test type of F in k3_m, test value of F in k3_m):
Make them KFAIL gcc/49546.
This current_oso global was used to store the OSO's symbol table
in order to relocate common symbols. But it is also making the
assumption that all sections are going to be immediately relocated
as macho_add_oso_symfile does:
- Initialize the current_oso
- Use it through symbol_file_add_from_bfd
- Reset the current_oso (to all fields NULL)
What actually happens is that the .debug_frame section gets read
lazily, and thus relocated at a later time. This relocation causes
current_oso.symbol_table to be initialized (see macho_symfile_relocate)
again. And this eventually causes to trip the...
gdb_assert (current_oso.symbol_table == NULL);
...assertion to fail because the symbol_table was never free'ed.
To be complete, this happens because macho_symfile_relocate was
called outside of macho_add_oso_symfile's control, where the
set-global/use/unset-global dance happens.
But it looks like keeping this global around is not necessary, as
this symbol table is only used to relocate the common symbols.
We can do that prior to relocating the rest of the symbols.
gdb/ChangeLog:
* machoread.c (struct macho_oso_data): Delete.
(current_oso): Delete.
(macho_relocate_common_syms): New function, mostly extracted
out of
(macho_add_oso_symfile): Call macho_relocate_common_syms.
Remove code that sets and unset current_oso.
(macho_symfile_relocate): Delete handling of common symbols,
now moved to macho_relocate_common_syms.
It might not be a debugger bug that caused the PT_KILL ptrace operation
to fail. So emit a warning instead, and try to continue.
This patch also tries to handle the case where ptrace return -1,
but left errno set to zero. According to the ptrace man page,
it is possible for some ptrace operations to return -1 in non-error
situations, and to detect those situations, it explains that errno
should be set prior to calling ptrace, and then checked again after.
gdb/ChangeLog:
* darwin-nat.c (darwin_ptrace): Add documentation.
Set errno to zero before calling ptrace. If ptrace returns
-1 and errno is zero, then change then return zero.
(darwin_kill_inferior): Issue a warning instead of triggering
a failed assertion when the PT_KILL ptrace operations returned
nonzero.
When trying to detach from an inferior that we start from the debugger,
GDB prints the following warning:
(gdb) detach
Detaching from program: /[...]/foo, process 74593
warning: Mach error at "/[...]/darwin-nat.c:445" in function "darwin_resume_inferior": (os/kern) failure (0x5)
The warning comes from the following code in darwin_detach:
darwin_resume_inferior (inf);
This is because the process has already been resumed by the
PT_DETACH ptrace operation that has just been performed.
On the other hand, when trying to detach from an inferior that
was started outside of debugger control (thus after having attached
the debugger to that inferior), things go smoothly. That's because
we don't use ptrace to control the process in that case, and so
the resume is perfectly justified.
This patch makes sure that we resume the inferior during the detach
only when we're NOT using ptrace.
gdb/ChangeLog:
* darwin-nat.c (darwin_detach): Call darwin_resume_inferior
only when inf->private->no_ptrace.
Temporary catchpoints on Ada exceptions are now displayed as "Temporary
catchpoint" as opposed to just "Catchpoint". This is cosmetic only, but
in line with what's done for other catchpoints as well as breakpoints.
gdb/ChangeLog:
* ada-lang.c (print_it_exception): Print temporary catchpoints
as "Temporary catchpoint".
(print_mention_exception): Likewise.
gdb/testsuite/ChangeLog:
* gdb.ada/catch_ex.exp: Add temporary catchpoint tests.
Test GCC PR debug/49546.
* gdb.cp/temargs.exp (set sixth breakpoint for temargs)
(test type of F in k3_m, test value of F in k3_m): New.
* gdb.cp/temargs.cc (struct S3, struct K3): New.
(main): New variable k3. Call k3.k3_m.
If the debugging info is incorrect or incomplete, printing the
type description of a variable that's a variant tagged type can
trigger a crash. The crash comes from us trying print a NULL
string which was supposed to be the parent type name.
We observed this behavior on bareboard targets where a-tags is
not always linked in, as is the case for native platforms, for
instance. Coupled with -feliminate-unused-debug-types, this leads
to GDB being unable to find type ada__tags__type_specific_data,
without which printing the type description above cannot be done
acurately. There is an easy workaround for this limitation,
which is to compile at least 1 unit with
-fno-eliminate-unused-debug-types, but GDB should also be made
resilient to this situation.
gdb/ChangeLog:
* ada-typeprint.c (print_record_type): If unable to decode
the name of the parent type, use the encoded name.
When trying to print the address of a non-packed array, GDB
correctly prints the type name and address:
(gdb) print &var
$2 = (access pa.var) 0xbffff1d8
However, it is behaving differently when dealing with a packed
array:
(gdb) p &var
(access array (4 .. 8) of boolean <packed: 1-bit elements>) (4 =>
false, false, false, true, false)
The type description isn't all that bad, but GDB shouldn't be
printing the array value!
This patch fixes the `print` and `ptype` command on packed and
non-packed array. It also fixes a gdb.ada test to match with
the new ouput.
gdb/ChangeLog (Jean-Charles Delay):
* ada-typeprint.c (ada_print_type): Fix both PAD type and
pointer to constrained packed array type output.
* ada-valprint.c (ada_val_print_1): Fix pointer to constrained
packed array output.
gdb/testsuite/ChangeLog (Jean-Charles Delay):
* gdb.ada/packed_array.exp: Fix expected outout.
Array bounds were not correctly displayed when the SHOW parameter of
print_type functions is set to -1. This shows up in the following
type of situation, where we have a declaration as follow:
Anon_Array_Int_Obj : array (1..10) of Integer := (others => 8);
In GDB/MI mode, trying to print the type info for our array object
yields:
(gdb) -var-create ai 0 Anon_Array_Int_Obj
(gdb) -var-info-type ai
^done,type="array (...) of integer"
The actual bounds are missing. Contrast this with what happens
when in GDB/CLI mode:
(gdb) ptype Anon_Array_Int_Obj
type = array (1 .. 10) of integer
This patch fixes array type printing accordingly. And as it turns
out, it also improves the output for one of the tests already present,
so it shows that it's not just the GDB/MI mode that's affected.
gdb/ChangeLog (Jean-Charles Delay):
* ada-typeprint.c (print_array_type): removed if condition on show
being negative for bounds printing.
gdb/testsuite/ChangeLog (Jean-Charles Delay):
* gdb.ada/packed_array.exp: fixed expected output.
This is to avoid an unnecessary multiple-choice menu for an
expression involving an enumeral declared in two types, when
the second type is an identical copy of the first type. This
happens in the following situation:
type Color is (Black, Red, Green, Blue, White);
type RGB_Color is new Color range Red .. Blue;
In that case, an implict type is created, and is used as the base
type for type RGB_Color. This base type is a copy of type Color.
We've added some extensive comments explaining the situation and
our approach further.
gdb/ChangeLog:
* ada-lang.c (ada_identical_enum_types_p): New function.
(symbols_are_identical_enums): New function.
(remove_extra_symbols): Do nothing if NSYMS < 2.
Use symbols_are_identical_enums.
gdb/testsuite/ChangeLog:
* gdb.ada/same_enum: New testcase.
If we evaluate an expression that results in a value that is a typedef
to pointer, then the debugger fails to print the type description
before printing the actual value:
(gdb) print e.plan(1)
$1 = 0x0
The expected output is:
(gdb) print e.plan(1)
$1 = (access integer) 0x0
gdb/ChangeLog:
* ada-valprint.c (ada_value_print): Handle typedefs.
gdb/testsuite/ChangeLog:
* gdb.ada/ptr_typedef: New testcase.
If we declare a type as being an access to array type, and then
declare a variable of that type, for instance:
type Some_Array is array [...];
type Array_Access is access all Some_Array;
Table : Array_Access := [...];
The variable "Table" may be defined in the debugging information
as being a typedef to the array pointer type. In the past, it was
defined directly as the array pointer type, but this has been changed
to make sure that the typedef type gets used.
If the typedef type wasn't used, it would allow the compiler to stop
emitting that typedef type when compiling with
-feliminate-unused-debug-types. The removal of this typedef would
be a problem, because GDB relies on the typedef to create symbols
for pointer types, and without it, we would no longer be able to
do "ptype array_access".
This patch helps prevent incorrect output or even crashes when that
extra typedef layer is used.
The testing is already mostly covered by arrayptr.exp, but I still
added a 'ptype' test, just for good measure.
gdb/ChangeLog: (Eric Botcazou)
* ada-lang.c (thin_descriptor_type): Deal with typedefs.
(decode_constrained_packed_array): Likewise.
(ada_evaluate_subexp) <TERNOP_SLICE>: Likewise.
gdb/testsuite/ChangeLog (Joel Brobecker):
* gdb.ada/arrayptr.exp: Add ptype test.
Consider the following type:
type Char_Enum_Type is ('A', 'B', 'C', 'D');
If the compiler generates a Char_Enum_Type typedef in the debugging
information, the debugger fails in the following case:
(gdb) p Char_Enum_Type'('B')
$1 = 66
For our type, the underlying value of 'B' is actually 1, not 66
(ASCII 'B'). We are failing this case because we were not handling
typedef to enum types before. This patch fixes this.
gdb/ChangeLog:
* ada-exp.y (convert_char_literal): Handle typedef types.
gdb/testsuite/ChangeLog:
* gdb.ada/char_enum: New testcase.
