* guile/scm-type.c (tyscm_copy_type_recursive): Move type to its
new eq?-hashtab.
testsuite/
* gdb.guile/scm-value.ep (test_value_after_death): Do a garbage
collect after discarding symbols.
* value.c (record_latest_value): Call release_value_or_incref
instead of release_value.
testsuite/
* gdb.guile/scm-value.exp (test_value_in_inferior): Verify value added
to history survives a gc.
Note that "target procfs" is used by QNX, but the test must be failing
there, as nto-procfs.c overrides to_open with a method that doesn't
throw the error being tested. So I'm just removing the test
completely.
gdb/
2014-03-13 Pedro Alves <palves@redhat.com>
* procfs.c (procfs_target): Don't override to_shortname,
to_longname or to_doc.
gdb/testsuite/
2014-03-13 Pedro Alves <palves@redhat.com>
* gdb.base/default.exp: Don't test "target procfs".
I find the mention of "Unix" unnecessary (and really slightly a lie)
on GNU/Linux in a couple of places:
(gdb) maint print target-stack
The current target stack is:
- multi-thread (multi-threaded child process.)
- child (Unix child process)
- exec (Local exec file)
- None (None)
(gdb) help target child
Unix child process (started by the "run" command).
(gdb) target child
Use the "run" command to start a Unix child process.
It's also odd that e.g., the Windows port says "Unix" in reaction to
"target child" (it was already that way before Windows used
inf-child.c):
(gdb) target child
Use the "run" command to start a Unix child process.
(gdb)
So drop "Unix", going in the direction of saying mostly the same on
all native targets:
(gdb) maint print target-stack
The current target stack is:
- multi-thread (multi-threaded child process.)
- - child (Unix child process)
+ - child (Child process)
- exec (Local exec file)
- None (None)
(gdb) help target child
- Unix child process (started by the "run" command).
+ Child process (started by the "run" command).
(gdb) target child
-Use the "run" command to start a Unix child process.
+Use the "run" command to start a child process.
gdb/
2014-03-13 Pedro Alves <palves@redhat.com>
* inf-child.c (inf_child_open, inf_child_target): Don't mention
Unix in user visible strings.
gdb/testsuite/
2014-03-13 Pedro Alves <palves@redhat.com>
* gdb.base/default.exp: Update "target child" and "target procfs"
tests to not expect "Unix".
A patch in the target cleanup series caused a regression when using
record with target-async. Version 4 of the patch is here:
https://sourceware.org/ml/gdb-patches/2014-03/msg00159.html
The immediate problem is that record supplies to_can_async_p and
to_is_async_p methods, but does not supply a to_async method. So,
when target-async is set, record claims to support async -- but if the
underlying target does not support async, then the to_async method
call will end up in that method's default implementation, namely
tcomplain.
This worked previously because the record target used to provide a
to_async method; one that (erroneously, only at push time) checked the
other members of the target stack, and then simply dropped to_async
calls in the "does not implement async" case.
My first thought was to simply drop tcomplain as the default for
to_async. This works, but Pedro pointed out that the only reason
record has to supply to_can_async_p and to_is_async_p is that these
default to using the find_default_run_target machinery -- and these
defaults are only needed by "run" and "attach".
So, a nicer solution presents itself: change run and attach to
explicitly call into the default run target when needed; and change
to_is_async_p and to_can_async_p to default to "return 0". This makes
the target stack simpler to use and lets us remove the method
implementations from record. This is also in harmony with other plans
for the target stack; namely trying to reduce the impact of
find_default_run_target. This approach makes it clear that
find_default_is_async_p is not needed -- it is asking whether a target
that may not even be pushed is actually async, which seems like a
nonsensical question.
While an improvement, this approach proved to introduce the same bug
when using the core target. Looking a bit deeper, the issue is that
code in "attach" and "run" may need to use either the current target
stack or the default run target -- but different calls into the target
API in those functions could wind up querying different targets.
This new patch makes the target to use more explicit in "run" and
"attach". Then these commands explicitly make the needed calls
against that target. This ensures that a single target is used for
all relevant operations. This lets us remove a couple find_default_*
functions from various targets, including the dummy target. I think
this is a decent understandability improvement.
One issue I see with this patch is that the new calls in "run" and
"attach" are not very much like the rest of the target API. I think
fundamentally this is due to bad factoring in the target API, which
may need to be fixed for multi-target. Tackling that seemed ambitious
for a regression fix.
While working on this I noticed that there don't seem to be any test
cases that involve both target-async and record, so this patch changes
break-precsave.exp to add some. It also changes corefile.exp to add
some target-async tests; these pass with current trunk and with this
patch applied, but fail with the v1 patch.
This patch differs from v4 in that it moves initialization of
to_can_async_p and to_supports_non_stop into inf-child, adds some
assertions to complete_target_initialization, and adds some comments
to target.h.
Built and regtested on x86-64 Fedora 20.
2014-03-12 Tom Tromey <tromey@redhat.com>
* inf-child.c (return_zero): New function.
(inf_child_target): Set to_can_async_p, to_supports_non_stop.
* aix-thread.c (aix_thread_inferior_created): New function.
(aix_thread_attach): Remove.
(init_aix_thread_ops): Don't set to_attach.
(_initialize_aix_thread): Register inferior_created observer.
* corelow.c (init_core_ops): Don't set to_attach or
to_create_inferior.
* exec.c (init_exec_ops): Don't set to_attach or
to_create_inferior.
* infcmd.c (run_command_1): Use find_run_target. Make direct
target calls.
(attach_command): Use find_attach_target. Make direct target
calls.
* record-btrace.c (init_record_btrace_ops): Don't set
to_create_inferior.
* record-full.c (record_full_can_async_p, record_full_is_async_p):
Remove.
(init_record_full_ops, init_record_full_core_ops): Update. Don't
set to_create_inferior.
* target.c (complete_target_initialization): Add assertion.
(target_create_inferior): Remove.
(find_default_attach, find_default_create_inferior): Remove.
(find_attach_target, find_run_target): New functions.
(find_default_is_async_p, find_default_can_async_p)
(target_supports_non_stop, target_attach): Remove.
(init_dummy_target): Don't set to_create_inferior or
to_supports_non_stop.
* target.h (struct target_ops) <to_attach>: Add comment. Remove
TARGET_DEFAULT_FUNC.
<to_create_inferior>: Add comment.
<to_can_async_p, to_is_async_p, to_supports_non_stop>: Use
TARGET_DEFAULT_RETURN.
<to_can_async_p, to_supports_non_stop, to_can_run>: Add comments.
(find_attach_target, find_run_target): Declare.
(target_create_inferior): Remove.
(target_has_execution_1): Update comment.
(target_supports_non_stop): Remove.
* target-delegates.c: Rebuild.
2014-03-12 Tom Tromey <tromey@redhat.com>
* gdb.base/corefile.exp (corefile_test_run, corefile_test_attach):
New procs. Add target-async tests.
* gdb.reverse/break-precsave.exp (precsave_tests): New proc.
Add target-async tests.
On PPC64, 'func' and 'main' are function descriptors and don't point
to the actual code. Thus the usage of these symbols in the DWARF
assembler source was broken. The patch introduces new labels
func_start and func_end for this purpose.
A "side effect" of the migration to Dwarf::assemble is that the DWARF
address size is now automatically adjusted to the target architecture.
The original assembler source hard-coded the DWARF address size to 4,
even on 64-bit architectures. This address size mismatch caused a
test case failure on s390x due to a wrong result from DW_OP_deref.
Now that prepare_for_testing etc. can cope with absolute path names,
this can be exploited for test cases with generated source files.
This is just to simplify the code and shouldn't cause any functional
change.
Test cases that produce source files in the build directory have not
been able to use prepare_for_testing and friends. This was because
build_executable_from_specs unconditionally prepended the source
directory path name to its arguments.
When evaluating an expression, if it is of a tagged type, GDB reads
the tag in memory and deduces the full view. At parsing time, however,
this operation is done only in the case of OP_VAR_VALUE. ptype does
not go through a full evaluation of expressions so it may return some
odd results:
(gdb) print c.menu_name
$1 = 0x0
(gdb) ptype $
type = system.strings.string_access
(gdb) ptype c.menu_name
type = <void>
This change removes this peculiarity by extending the tag resolution
to UNOP_IND and STRUCTOP_STRUCT. As in the case of OP_VAR_VALUE, this
implies switching from EVAL_AVOID_SIDE_EFFECTS to EVAL_NORMAL when a
tagged type is dereferenced.
gdb/
* ada-lang.c (ada_evaluate_subexp): Resolve tagged types to
full view in the case of UNOP_IND and STRUCTOP_STRUCT.
gdb/testsuite/
* gdb.ada/tagged_access: New testcase.
This patch fixes PR16508, which is about MI "-trace-find frame-number 0"
behaves differently from CLI "tfind 0". In CLI, we check both
status->running and status->filename, but in MI, we only check
status->running, which looks wrong to me. This patch moves the code
of checking to a new function check_trace_running, and use it in
both CLI and MI.
This patch also adds a test case pr16508.exp, which fails without this
fix, and passes with the fix applied.
FAIL: gdb.trace/pr16508.exp: interpreter-exec mi "-trace-find frame-number 0"
gdb:
2014-03-06 Yao Qi <yao@codesourcery.com>
PR breakpoints/16508
* tracepoint.c (check_trace_running): New function.
(trace_find_command): Move code to check_trace_running and
call check_trace_running.
(trace_find_pc_command): Likewise.
(trace_find_tracepoint_command): Likewise.
(trace_find_line_command): Likewise.
(trace_find_range_command): Likewise.
* tracepoint.h (check_trace_running): Likewise.
* mi/mi-main.c (mi_cmd_trace_find): Call check_trace_running.
gdb/testsuite:
2014-03-06 Yao Qi <yao@codesourcery.com>
* gdb.trace/pr16508.exp: New file.
In non-stop mode, or rather, breakpoints always-inserted mode, the
code cache can easily end up with stale breakpoint instructions:
All it takes is filling a cache line when breakpoints already exist in
that memory region, and then delete the breakpoint.
Vis. (from the new test):
(gdb) set breakpoint always-inserted on
(gdb) b 23
Breakpoint 2 at 0x400540: file ../../../src/gdb/testsuite/gdb.base/breakpoint-shadow.c, line 23.
(gdb) b 24
Breakpoint 3 at 0x400547: file ../../../src/gdb/testsuite/gdb.base/breakpoint-shadow.c, line 24.
disass main
Dump of assembler code for function main:
0x000000000040053c <+0>: push %rbp
0x000000000040053d <+1>: mov %rsp,%rbp
=> 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp)
0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp)
0x000000000040054e <+18>: mov $0x0,%eax
0x0000000000400553 <+23>: pop %rbp
0x0000000000400554 <+24>: retq
End of assembler dump.
So far so good. Now flush the code cache:
(gdb) set code-cache off
(gdb) set code-cache on
Requesting a disassembly works as expected, breakpoint shadowing is
applied:
(gdb) disass main
Dump of assembler code for function main:
0x000000000040053c <+0>: push %rbp
0x000000000040053d <+1>: mov %rsp,%rbp
=> 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp)
0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp)
0x000000000040054e <+18>: mov $0x0,%eax
0x0000000000400553 <+23>: pop %rbp
0x0000000000400554 <+24>: retq
End of assembler dump.
However, now delete the breakpoints:
(gdb) delete
Delete all breakpoints? (y or n) y
And disassembly shows the old breakpoint instructions:
(gdb) disass main
Dump of assembler code for function main:
0x000000000040053c <+0>: push %rbp
0x000000000040053d <+1>: mov %rsp,%rbp
=> 0x0000000000400540 <+4>: int3
0x0000000000400541 <+5>: rex.RB cld
0x0000000000400543 <+7>: add %eax,(%rax)
0x0000000000400545 <+9>: add %al,(%rax)
0x0000000000400547 <+11>: int3
0x0000000000400548 <+12>: rex.RB cld
0x000000000040054a <+14>: add (%rax),%al
0x000000000040054c <+16>: add %al,(%rax)
0x000000000040054e <+18>: mov $0x0,%eax
0x0000000000400553 <+23>: pop %rbp
0x0000000000400554 <+24>: retq
End of assembler dump.
Those breakpoint instructions are no longer installed in target memory
they're stale in the code cache. Easily confirmed by just disabling
the code cache:
(gdb) set code-cache off
(gdb) disass main
Dump of assembler code for function main:
0x000000000040053c <+0>: push %rbp
0x000000000040053d <+1>: mov %rsp,%rbp
=> 0x0000000000400540 <+4>: movl $0x1,-0x4(%rbp)
0x0000000000400547 <+11>: movl $0x2,-0x4(%rbp)
0x000000000040054e <+18>: mov $0x0,%eax
0x0000000000400553 <+23>: pop %rbp
0x0000000000400554 <+24>: retq
End of assembler dump.
I stumbled upon this when writing a patch to infrun.c, that made
handle_inferior_event & co fill in the cache before breakpoints were
removed from the target. Recall that wait_for_inferior flushes the
dcache for every event. So in that case, always-inserted mode was not
necessary to trigger this. It's just a convenient way to expose the
issue.
The dcache works at the raw memory level. We need to update it
whenever memory is written, no matter what kind of target memory
object was originally passed down by the caller. The issue is that
the dcache update code isn't reached when a caller explicitly writes
raw memory. Breakpoint insertion/removal is one such case --
mem-break.c uses target_write_read_memory/target_write_raw_memory.
The fix is to move the dcache update code from memory_xfer_partial_1
to raw_memory_xfer_partial so that it's always reachable.
When we do that, we can actually simplify a series of things.
memory_xfer_partial_1 no longer needs to handle writes for any kind of
memory object, and therefore dcache_xfer_memory no longer needs to
handle writes either. So the latter (dcache_xfer_memory) and its
callees can be simplified to only care about reads. While we're
touching dcache_xfer_memory's prototype, might as well rename it to
reflect that fact that it only handles reads, and make it follow the
new target_xfer_status/xfered_len style. This made me notice that
dcache_xfer_memory loses the real error status if a memory read fails:
we could have failed to read due to TARGET_XFER_E_UNAVAILABLE, for
instance, but we always return TARGET_XFER_E_IO, hence the FIXME note.
I felt that fixing that fell out of the scope of this patch.
Currently dcache_xfer_memory handles the case of a write failing. The
whole cache line is invalidated when that happens. However,
dcache_update, the sole mechanism for handling writes that will remain
after the patch, does not presently handle that scenario. That's a
bug. The patch makes it handle that, by passing down the
target_xfer_status status from the caller, so that it can better
decide what to do itself. While I was changing the function's
prototype, I constified the myaddr parameter, getting rid of the need
for the cast as seen in its existing caller.
Tested on x86_64 Fedora 17, native and gdbserver.
gdb/
2014-03-05 Pedro Alves <palves@redhat.com>
PR gdb/16575
* dcache.c (dcache_poke_byte): Constify ptr parameter. Return
void. Update comment.
(dcache_xfer_memory): Delete.
(dcache_read_memory_partial): New, based on the read bits of
dcache_xfer_memory.
(dcache_update): Add status parameter. Use ULONGEST for len, and
adjust. Discard cache lines if the reason for the update was
error.
* dcache.h (dcache_xfer_memory): Delete declaration.
(dcache_read_memory_partial): New declaration.
(dcache_update): Update prototype.
* target.c (raw_memory_xfer_partial): Update the dcache here.
(memory_xfer_partial_1): Don't handle dcache writes here.
gdb/testsuite/
2014-03-05 Pedro Alves <palves@redhat.com>
PR gdb/16575
* gdb.base/breakpoint-shadow.exp (compare_disassembly): New
procedure.
(top level): Adjust to use it. Add tests that exercise breakpoint
interaction with the code-cache.
Starting with DWARF version 4, the description of the DW_AT_high_pc
attribute was amended to say:
if it is of class constant, the value is an unsigned integer offset
which when added to the low PC gives the address of the first
location past the last instruction associated with the entity.
A change was made in Apr 27th, 2012 to reflect that change:
| commit 91da14142c
| Author: Mark Wielaard <mjw@redhat.com>
| Date: Fri Apr 27 18:55:19 2012 +0000
|
| * dwarf2read.c (dwarf2_get_pc_bounds): Check DW_AT_high_pc form to
| see whether it is an address or a constant offset from DW_AT_low_pc.
| (dwarf2_record_block_ranges): Likewise.
| (read_partial_die): Likewise.
Unfortunately, this new interpretation is now used regardless of
the CU's DWARF version. It turns out that one of WindRiver's compilers
(FTR: Diabdata 4.4) is generating DWARF version 2 info with
DW_AT_high_pc attributes improperly using the data4 form. Because of
that, we miscompute all high PCs incorrectly. This leads to a lot of
symtabs having overlapping ranges, which in turn causes havoc in
pc-to-symtab-and-line translations.
One visible effect is when inserting a breakpoint on a given function:
(gdb) b world
Breakpoint 1 at 0x4005c4
The source location of the breakpoint is missing. The output should be:
(gdb) b world
Breakpoint 1 at 0x4005c8: file dw2-rel-hi-pc-world.c, line 24.
What happens in this case is that the pc-to-SAL translation first
starts be trying to find the symtab associated to our PC using
each symtab's ranges. Because of the high_pc miscomputation,
many symtabs end up matching, and the heuristic trying to select
the most probable one unfortunately returns one that is unrelated
(it really had no change in this case to do any better). Once we
have the wrong symtab, the start searching the associated linetable,
where the addresses are correct, thus finding no match, and therefore
no SAL.
This patch is an attempt at handling the situation as gracefully
as we can, without guarantees. It introduces a new function
"attr_value_as_address" which uses the correct accessor for getting
the value of a given attribute. It then adjust the code throughout
this unit to use this function instead of assuming that addresses always
have the DW_FORM_addr format.
It also fixes the original issue of miscomputing the high_pc
by limiting the new interpretation of constant form DW_AT_high_pc
attributes to units using DWARF version 4 or later.
gdb/ChangeLog:
* dwarf2read.c (attr_value_as_address): New function.
(dwarf2_find_base_address, read_call_site_scope): Use
attr_value_as_address in place of DW_ADDR.
(dwarf2_get_pc_bounds): Use attr_value_as_address to get
the low and high addresses. Slight rework of the handling
of the high pc being a constant form, and limit it to
DWARF verson 4 or higher.
(dwarf2_record_block_ranges): Likewise.
(read_partial_die): Likewise.
(new_symbol_full): Use attr_value_as_address in place of DW_ADDR.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-abs-hi-pc-hello-dbg.S: New file.
* gdb.dwarf2/dw2-abs-hi-pc-hello.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc-world-dbg.S: New file.
* gdb.dwarf2/dw2-abs-hi-pc-world.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc.c: New file.
* gdb.dwarf2/dw2-abs-hi-pc.exp: New file.
Tested on x86_64-linux.
Consider the following type for which we would like to provide
a pretty-printer and manage it via RegexpCollectionPrettyPrinter:
typedef long time_t;
Currently, this does not work because this framework only considers
the type's tag name:
typename = gdb.types.get_basic_type(val.type).tag
if not typename:
return None
This patch extends it to use the type's name if the basic type
does not have a tag name, thus allowing the framework to also
work with typedefs like the above.
gdb/ChangeLog:
* python/lib/gdb/printing.py (RegexpCollectionPrettyPrinter):
Use the type's name if its basic type does not have a tag.
gdb/testsuite/ChangeLog:
* testsuite/gdb.python/py-pp-re-notag.c: New file.
* testsuite/gdb.python/py-pp-re-notag.ex: New file.
* testsuite/gdb.python/py-pp-re-notag.p: New file.
Consider the following Ada code:
-- An array whose index is an enumeration type with 128 enumerators.
type Enum_T is (Enum_000, Enum_001, [...], Enum_128);
type Table is array (Enum_T) of Boolean;
When the compiler is configured to generate pure DWARF debugging info,
trying to print type Table's description yields:
ptype pck.table
type = array (enum_000 .. -128) of boolean
The expected output was:
ptype pck.table
type = array (enum_000 .. enum_128) of boolean
The DWARF debugging info for our array looks like this:
<1><44>: Abbrev Number: 5 (DW_TAG_array_type)
<45> DW_AT_name : pck__table
<50> DW_AT_type : <0x28>
<2><54>: Abbrev Number: 6 (DW_TAG_subrange_type)
<55> DW_AT_type : <0x5c>
<59> DW_AT_lower_bound : 0
<5a> DW_AT_upper_bound : 128
The array index type is, by construction with the DWARF standard,
a subrange of our enumeration type, defined as follow:
<2><5b>: Abbrev Number: 0
<1><5c>: Abbrev Number: 7 (DW_TAG_enumeration_type)
<5d> DW_AT_name : pck__enum_t
<69> DW_AT_byte_size : 1
<2><6b>: Abbrev Number: 8 (DW_TAG_enumerator)
<6c> DW_AT_name : pck__enum_000
<7a> DW_AT_const_value : 0
[etc]
Therefore, while processing these DIEs, the array index type ends
up being a TYPE_CODE_RANGE whose target type is our enumeration type.
But the problem is that we read the upper bound as a negative value
(-128), which is then used as is by the type printer to print the
array upper bound. This negative value explains the "-128" in the
output.
To understand why the range type's upper bound is read as a negative
value, one needs to look at how it is determined, in read_subrange_type:
orig_base_type = die_type (die, cu);
base_type = check_typedef (orig_base_type);
[... high is first correctly read as 128, but then ...]
if (!TYPE_UNSIGNED (base_type) && (high & negative_mask))
high |= negative_mask;
The negative_mask is applied, here, because BASE_TYPE->FLAG_UNSIGNED
is not set. And the reason for that is because the base_type was only
partially constructed during the call to die_type. While the enum
is constructed on the fly by read_enumeration_type, its flag_unsigned
flag is only set later on, while creating the symbols corresponding to
the enum type's enumerators (see process_enumeration_scope), after
we've already finished creating our range type - and therefore too
late.
My first naive attempt at fixing this problem consisted in extracting
the part in process_enumeration_scope which processes all enumerators,
to generate the associated symbols, but more importantly set the type's
various flags when necessary. However, this does not always work well,
because we're still in the subrange_type's scope, and it might be
different from the scope where the enumeration type is defined.
So, instead, what this patch does to fix the issue is to extract
from process_enumeration_scope the part that determines whether
the enumeration type should have the flag_unsigned and/or the
flag_flag_enum flags set. It turns out that, aside from the code
implementing the loop, this part is fairly independent of the symbol
creation. With that part extracted, we can then use it at the end
of our enumeration type creation, to produce a type which should now
no longer need any adjustment.
Once the enumeration type produced is correctly marked as unsigned,
the subrange type's upper bound is then correctly read as an unsigned
value, therefore giving us an upper bound of 128 instead of -128.
gdb/ChangeLog:
* dwarf2read.c (update_enumeration_type_from_children): New
function, mostly extracted from process_structure_scope.
(read_enumeration_type): Call update_enumeration_type_from_children.
(process_enumeration_scope): Do not set THIS_TYPE's flag_unsigned
and flag_flag_enum fields.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/arr-subrange.c, gdb.dwarf2/arr-subrange.exp: New files.
Consider the following declarations in Ada...
type Item is range -32 .. 31;
for Item'Size use 6;
type Table is array (Natural range 0 .. 4) of Item;
pragma Pack (Table);
... which declare a packed array whose elements are 6 bits long.
The debugger currently does not notice that the array is packed,
and thus prints values of this type incorrectly. This can be seen
in the "ptype" output:
(gdb) ptype table
type = array (0 .. 4) of foo.item
Normally, the debugger should print:
(gdb) ptype table
type = array (0 .. 4) of foo.item <packed: 6-bit elements>
The debugging information for this array looks like this:
.uleb128 0xf # (DIE (0x15c) DW_TAG_array_type)
.long .LASF9 # DW_AT_name: "pck__table"
.byte 0x6 # DW_AT_bit_stride
.long 0x1a9 # DW_AT_type
.uleb128 0x10 # (DIE (0x16a) DW_TAG_subrange_type)
.long 0x3b # DW_AT_type
.byte 0 # DW_AT_lower_bound
.byte 0x4 # DW_AT_upper_bound
.byte 0 # end of children of DIE 0x15c
The interesting part is the DW_AT_bit_stride attribute, which tells
the size of the array elements is 6 bits, rather than the normal
element type's size.
This patch adds support for this attribute by first creating
gdbtypes.c::create_array_type_with_stride, which is an enhanced
version of create_array_type taking an extra parameter as the stride.
The old create_array_type can then be re-implemented very simply
by calling the new create_array_type_with_stride.
We can then use this new function from dwarf2read, to create
arrays with or without stride.
gdb/ChangeLog:
* gdbtypes.h (create_array_type_with_stride): Add declaration.
* gdbtypes.c (create_array_type_with_stride): New function,
renaming create_array_type, but with an added parameter
called "bit_stride".
(create_array_type): Re-implement using
create_array_type_with_stride.
* dwarf2read.c (read_array_type): Add support for DW_AT_byte_stride
and DW_AT_bit_stride attributes.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/arr-stride.c: New file.
* gdb.dwarf2/arr-stride.exp: New file.
The test, relying purely on generating an assembly file, only
verifies the type description of our array. But I was also
able to verify manually that the debugger print values of these
types correctly as well (which was not the case prior to this
patch).
With the test changed as in the patch, against current mainline, we get:
(gdb) PASS: gdb.ada/tasks.exp: info tasks before inserting breakpoint
break break_me task 1
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 1
break break_me task 3
Note: breakpoint 2 also set at pc 0x4030b0.
Breakpoint 3 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7dc7700 (LWP 27133)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) FAIL: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 3 main_task
2 63bd80 1 48 Accept or Select Term task_list(1)
* 3 63f510 1 48 Accepting RV with 1 task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) PASS: gdb.ada/tasks.exp: info tasks after hitting breakpoint
The breakpoint that caused a stop is breakpoint 3, but GDB end up
reporting (and running breakpoint commands of) "Breakpoint 2" instead.
The issue is that the bpstat_check_breakpoint_conditions logic of
"wrong thread" is missing the "wrong task" check. This is usually
harmless, because the thread hop code in infrun.c code that handles
wrong-task-hitting-breakpoint does check for task-specific breakpoints
(within breakpoint_thread_match):
/* Check if a regular breakpoint has been hit before checking
for a potential single step breakpoint. Otherwise, GDB will
not see this breakpoint hit when stepping onto breakpoints. */
if (regular_breakpoint_inserted_here_p (aspace, stop_pc))
{
if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid))
thread_hop_needed = 1;
}
IOW, usually, when one only has a task specific breakpoint at a given
address, things work correctly. Put another task-specific or
non-task-specific breakpoint there, and things break.
A patch that eliminates the special thread hop code in infrun.c is
what exposed this, as after that GDB solely relies on
bpstat_check_breakpoint_conditions to know whether the right or wrong
task hit a breakpoint. IOW, given the latent bug, Ada task-specific
breakpoints become non-task-specific, and that is caught by the
testsuite, as:
break break_me task 3
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7fcb700 (LWP 17122)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) PASS: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 2 main_task
* 2 63bd80 1 48 Accepting RV with 1 task_list(1)
3 63f510 1 48 Accept or Select Term task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint
It was after seeing this that I thought of how to expose the bug with
current mainline.
Tested on x86_64 Fedora 17.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
* breakpoint.c (bpstat_check_breakpoint_conditions): Handle
task-specific breakpoints.
gdb/testsuite/
2014-02-26 Pedro Alves <palves@redhat.com>
* gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me
that won't ever trigger. Make sure that GDB reports the correct
breakpoint that caused the stop.
Fix auto-load 7.7 regression,
the regression affects any loading from /usr/share/gdb/auto-load .
5b2bf9471f is the first bad commit
commit 5b2bf9471f
Author: Doug Evans <xdje42@gmail.com>
Date: Fri Nov 29 21:29:26 2013 -0800
Move .debug_gdb_script processing to auto-load.c.
Simplify handling of auto-loaded objfile scripts.
Fedora 20 x86_64
$ gdb -q /usr/lib64/libgobject-2.0.so
Reading symbols from /usr/lib64/libglib-2.0.so.0.3800.2...Reading symbols from
/usr/lib/debug/usr/lib64/libglib-2.0.so.0.3800.2.debug...done.
done.
(gdb) _
Fedora Rawhide x86_64
$ gdb -q /usr/lib64/libgobject-2.0.so
Reading symbols from /usr/lib64/libglib-2.0.so...Reading symbols from
/usr/lib/debug/usr/lib64/libglib-2.0.so.0.3990.0.debug...done.
done.
warning: File "/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py" auto-loading has been declined by your `auto-load safe-path'
set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
To enable execution of this file add
add-auto-load-safe-path /usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
line to your configuration file "/home/jkratoch/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/jkratoch/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
(gdb) _
That is it tries to load "forbidden"
/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
but it should load instead
/usr/share/gdb/auto-load/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py*
Although that is also not exactly this way, there does not exist any
/usr/lib64/libglib-2.0.so.0.3990.0-gdb.py
despite regressed GDB says so.
gdb/
2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/16626
* auto-load.c (auto_load_objfile_script_1): Change filename to
debugfile.
gdb/testsuite/
2014-02-24 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/16626
* gdb.base/auto-load-script: New file.
* gdb.base/auto-load.c: New file.
* gdb.base/auto-load.exp: New file.
Message-ID: <20140223212400.GA8831@host2.jankratochvil.net>
I realized that the name of this test only made sense when considering
the old (never committed) implementation of the fix that came along
with the test originally, that forced a schedlock while a step-resume
(to get over the signal handler) was inserted. The final solution
that went into the tree does not force that locking.
So this renames it to something more descriptive.
gdb/testsuite/
2014-02-21 Pedro Alves <palves@redhat.com>
* gdb.threads/step-after-sr-lock.c: Rename to ...
* gdb.threads/signal-while-stepping-over-bp-other-thread.c: ... this.
* gdb.threads/step-after-sr-lock.exp: Rename to ...
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
... this.
This is the continuation of what Joel proposed on:
<https://sourceware.org/ml/gdb-patches/2013-12/msg00977.html>
Now that I have already submitted and pushed the patch to split
i386_stap_parse_special_token into two smaller functions, it is indeed
simpler to understand this patch.
It occurs because, on x86, triplet displacement operands are allowed
(like "-4+8-20(%rbp)"), and the current parser for this expression is
buggy. It does not correctly extract the register name from the
expression, which leads to incorrect evaluation. The parser was also
being very "generous" with the expression, so I included a few more
checks to ensure that we're indeed dealing with a triplet displacement
operand.
This patch also includes testcases for the two different kind of
expressions that can be encountered on x86: the triplet displacement
(explained above) and the three-argument displacement (as in
"(%rbx,%ebx,-8)"). The tests are obviously arch-dependent and are
placed under gdb.arch/.
Message-ID: <m3mwj1j12v.fsf@redhat.com>
URL: <https://sourceware.org/ml/gdb-patches/2014-01/msg00310.html>
gdb/
2014-02-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR tdep/16397
* i386-tdep.c (i386_stap_parse_special_token_triplet): Check if a
number comes after the + or - signs. Adjust length of register
name to be extracted.
gdb/testsuite/
2014-02-20 Sergio Durigan Junior <sergiodj@redhat.com>
PR tdep/16397
* gdb.arch/amd64-stap-special-operands.exp: New file.
* gdb.arch/amd64-stap-three-arg-disp.S: Likewise.
* gdb.arch/amd64-stap-three-arg-disp.c: Likewise.
* gdb.arch/amd64-stap-triplet.S: Likewise.
* gdb.arch/amd64-stap-triplet.c: Likewise.
The arm-elf assembler chokes on the extra parameters in the .section
pseudo-op, so this patch removes them.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-icycle.S: Remove second and third parameters
in .section pseudo-op.
* dwarf2read.c (struct die_info): New member in_process.
(reset_die_in_process): New function.
(process_die): Set it at the start, reset when returning.
(inherit_abstract_dies): Only call process_die if origin_child_die
not already being processed.
testsuite/
* gdb.dwarf2/dw2-icycle.S: New file.
* gdb.dwarf2/dw2-icycle.c: New file.
* gdb.dwarf2/dw2-icycle.exp: New file.
* NEWS: Add entry for the new feature
* python/py-value.c (valpy_binop): Call value_x_binop for struct
and class values.
testsuite/
* gdb.python/py-value-cc.cc: Improve test case to enable testing
operations on gdb.Value objects.
* gdb.python/py-value-cc.exp: Add new test to test operations on
gdb.Value objects.
doc/
* python.texi (Values From Inferior): Add description about the
new feature.
* Makefile.in (TESTS): New variable.
(expanded_tests, expanded_tests_or_none): New variables
(check-single): Pass $(expanded_tests_or_none) to runtest.
(check-parallel): Only run tests in $(TESTS) if non-empty.
(check/no-matching-tests-found): New rule.
* README: Document TESTS makefile variable.
If GDB has crashed then gdb_spawn_id still exists (although it does not work).
So my patch does not change anything. And also currently it will leave the
stale gdbserver running anyway.
In general if gdb_spawn_id does not exist then send_gdb + gdb_expect just do
not make sense anyway. So this patch just prevents the error in such case.
The killing of stale gdbserver could be improved multiple ways (also as
suggested by Pedro in the original thread) but that is IMO outside of the
scope of this patch. Apparently if there is no good response from GDB then
gdb_finish() should try to call gdb_start just to kill that gdbserver, IIUC.
gdb/testsuite/
2014-02-16 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix "ERROR: no fileid for" in the testsuite.
* lib/gdb.exp (gdb_finish): Check gdb_spawn_id.
Message-ID: <20140206205814.GA18495@host2.jankratochvil.net>
* gdb.dwarf2/Makefile.in (EXECUTABLES): Add dwp-symlink.
(MISCELLANEOUS): New variable.
(clean): rm -rf $(MISCELLANEOUS).
* gdb.dwarf2/dwp-symlink.exp: Test the case where the executable and
dwp live in the same directory as symlinks, with each symlink pointed
to a differently named file in a different directory.
Consider the following code:
type Color is (Black, Red, Green, Blue, White);
type Primary_Table is array (Color range Red .. Blue) of Boolean;
Prim : Primary_Table := (True, False, False);
GDB prints the length of arrays in a fairly odd way:
(gdb) p prim'length
$2 = blue
The length returned should be an integer, not the array index type,
and this patch fixes this.
gdb/ChangeLog:
* ada-lang.c (ada_evaluate_subexp): Set the type of the value
returned by the 'Length attribute to integer.
testsuite/ChangeLog:
* gdb.ada/tick_length_array_enum_idx: New testcase.
Tests in gdb.gdb fail because directory gdb/testsuite/gdb.gdb doesn't
exist in build tree. This patch appends gdb.gdb/Makefile in AC_OUTPUT,
and adds new Makefile.in in gdb.gdb, so that directory gdb.gdb can be
created during configure.
With this patch applied, tests under gdb.gdb can be run,
$ make check RUNTESTFLAGS='--directory=gdb.gdb'
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../../../git/gdb/testsuite/config/unix.exp as tool-and-target-specific interface file.
Running ../../../../git/gdb/testsuite/gdb.gdb/complaints.exp ...
Running ../../../../git/gdb/testsuite/gdb.gdb/observer.exp ...
Running ../../../../git/gdb/testsuite/gdb.gdb/python-interrupts.exp ...
FAIL: gdb.gdb/python-interrupts.exp: signal SIGINT
Running ../../../../git/gdb/testsuite/gdb.gdb/python-selftest.exp ...
FAIL: gdb.gdb/python-selftest.exp: call catch_command_errors(execute_command, "python print 5", 0, RETURN_MASK_ALL)
Running ../../../../git/gdb/testsuite/gdb.gdb/selftest.exp ...
Running ../../../../git/gdb/testsuite/gdb.gdb/xfullpath.exp ...
=== gdb Summary ===
gdb/testsuite:
2014-02-10 Yao Qi <yao@codesourcery.com>
PR testsuite/16543
* configure.ac: Append gdb.gdb/Makefile in AC_OUTPUT.
* configure: Regenerated.
* Makefile.in: New file.
As design, =breakpoint-modified isn't emitted when breakpoints are modified
by MI commands. This patch is to add tests for this.
gdb/testsuite:
2014-02-08 Yao Qi <yao@codesourcery.com>
* gdb.mi/mi-breakpoint-changed.exp (test_insert_delete_modify): Test
that no =breakpoint-modified is emitted when breakpoints are
modified through MI commands.
Say:
<stopped at a breakpoint in thread 2>
(gdb) thread 3
(gdb) step
The above triggers the prepare_to_proceed/deferred_step_ptid process,
which switches back to thread 2, to step over its breakpoint before
getting back to thread 3 and "step" it.
If while stepping over the breakpoint in thread 2, a signal arrives,
and it is set to pass/nostop, we'll set a step-resume breakpoint at
the supposed signal-handler resume address, and call keep_going. The
problem is that we were supposedly stepping thread 3, and that
keep_going delivers a signal to thread 2, and due to scheduler-locking
off, resumes everything else, _including_ thread 3, the thread we want
stepping. This means that we lose control of thread 3 until the next
event, when we stop everything. The end result for the user, is that
GDB lost control of the "step".
Here's the current infrun debug output of the above, with the testcase
in the patch below:
infrun: clear_proceed_status_thread (Thread 0x2aaaab8f5700 (LWP 11663))
infrun: clear_proceed_status_thread (Thread 0x2aaaab6f4700 (LWP 11662))
infrun: clear_proceed_status_thread (Thread 0x2aaaab4f2b20 (LWP 11659))
infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1)
infrun: prepare_to_proceed (step=1), switched to [Thread 0x2aaaab6f4700 (LWP 11662)]
infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
infrun: status->kind = stopped, signal = SIGUSR1
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40098f
infrun: random signal 30
Program received signal SIGUSR1, User defined signal 1.
infrun: signal arrived while stepping over breakpoint
infrun: inserting step-resume breakpoint at 0x40098f
infrun: resume (step=0, signal=30), trap_expected=0, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
^^^ this is a wildcard resume.
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40098f
infrun: BPSTAT_WHAT_STEP_RESUME
infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
^^^ step-resume hit, meaning the handler returned, so we go back to stepping thread 3.
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40088b
infrun: switching back to stepped thread
infrun: Switching context from Thread 0x2aaaab6f4700 (LWP 11662) to Thread 0x2aaaab8f5700 (LWP 11663)
infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x400938
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40093a
infrun: keep going
infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x40093a
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40091e
infrun: stepped to a different line
infrun: stop_stepping
[Switching to Thread 0x2aaaab8f5700 (LWP 11663)]
69 (*myp) ++; /* set breakpoint child_two here */
^^^ we stopped at the wrong line. We still stepped a bit because the
test is running in a loop, and when we got back to stepping thread 3,
it happened to be in the stepping range. (The loop increments a
counter, and the test makes sure it increments exactly once. Without
the fix, the counter increments a bunch, since the user-stepped thread
runs free without GDB noticing.)
The fix is to switch to the stepping thread before continuing for the
step-resume breakpoint.
gdb/
2014-02-07 Pedro Alves <palves@redhat.com>
* infrun.c (handle_signal_stop) <signal arrives while stepping
over a breakpoint>: Switch back to the stepping thread.
gdb/testsuite/
2014-02-07 Pedro Alves <pedro@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdb.threads/step-after-sr-lock.c: New file.
* gdb.threads/step-after-sr-lock.exp: New file.
Currently on software single-step Linux targets we get:
(gdb) PASS: gdb.threads/stepi-random-signal.exp: before stepi: get hexadecimal valueof "$pc"
stepi
infrun: clear_proceed_status_thread (Thread 0x7ffff7fca700 (LWP 7073))
infrun: clear_proceed_status_thread (Thread 0x7ffff7fcb740 (LWP 7069))
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 7069)] at 0x400700
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 7069 [Thread 0x7ffff7fcb740 (LWP 7069)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400704
infrun: software single step trap for Thread 0x7ffff7fcb740 (LWP 7069)
infrun: stepi/nexti
infrun: stop_stepping
44 while (counter != 0)
(gdb) FAIL: gdb.threads/stepi-random-signal.exp: stepi (no random signal)
Vs hardware-step targets:
(gdb) PASS: gdb.threads/stepi-random-signal.exp: before stepi: get hexadecimal valueof "$pc"
stepi
infrun: clear_proceed_status_thread (Thread 0x7ffff7fca700 (LWP 9565))
infrun: clear_proceed_status_thread (Thread 0x7ffff7fcb740 (LWP 9561))
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 9561)] at 0x400700
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 9561 [Thread 0x7ffff7fcb740 (LWP 9561)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_CHLD
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400700
infrun: random signal (GDB_SIGNAL_CHLD)
infrun: random signal, keep going
infrun: resume (step=1, signal=GDB_SIGNAL_CHLD), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 9561)] at 0x400700
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 9561 [Thread 0x7ffff7fcb740 (LWP 9561)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400704
infrun: stepi/nexti
infrun: stop_stepping
44 while (counter != 0)
(gdb) PASS: gdb.threads/stepi-random-signal.exp: stepi
The test turns on infrun debug, does a stepi while a SIGCHLD is
pending, and checks whether the "random signal" paths in infrun.c are
taken.
On the software single-step variant above, those paths were not taken.
This is a test bug.
The Linux backend short-circuits reporting signals that are set to
pass/nostop/noprint. But _only_ if the thread is _not_
single-stepping. So on hardware-step targets, even though the signal
is set to pass/nostop/noprint by default, the thread is indeed told to
single-step, and so the core sees the signal. On the other hand, on
software single-step architectures, the backend never actually gets a
single-step request (steps are emulated by setting a breakpoint at the
next pc, and then the target told to continue, not step). So the
short-circuiting code triggers and the core doesn't see the signal.
The fix is to make the test be sure the target doesn't bypass
reporting the signal to the core.
Tested on x86_64 Fedora 17, both with and without a series that
implements software single-step for x86_64.
gdb/testsuite/
2014-02-07 Pedro Alves <palves@redhat.com>
* gdb.threads/stepi-random-signal.exp: Set SIGCHLD to print.
gdb/testsuite/
2014-02-06 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix i386-sse-stack-align.exp regression since GDB_PARALLEL.
* gdb.arch/i386-sse-stack-align.exp: Use standard_output_file.
* configure.ac (libpython checking): Remove all but python.o from
CONFIG_OBS. Remove all but python.c from CONFIG_SRCS.
* configure: Regenerate.
* Makefile.in (SFILES): Add extension.c.
(HFILES_NO_SRCDIR): Add extension.h, extension-priv.h
(COMMON_OBS): Add extension.o.
* extension.h: New file.
* extension-priv.h: New file.
* extension.c: New file.
* python/python-internal.h: #include "extension.h".
(gdbpy_auto_load_enabled): Declare.
(gdbpy_apply_val_pretty_printer): Declare.
(gdbpy_apply_frame_filter): Declare.
(gdbpy_preserve_values): Declare.
(gdbpy_breakpoint_cond_says_stop): Declare.
(gdbpy_breakpoint_has_cond): Declare.
(void source_python_script_for_objfile): Delete.
* python/python.c: #include "extension-priv.h".
Delete inclusion of "observer.h".
(extension_language_python): Moved here and renamed from
script_language_python in py-auto-load.c.
Redefined to be of type extension_language_defn.
(python_extension_script_ops): New global.
(python_extension_ops): New global.
(struct python_env): New member previous_active.
(restore_python_env): Call restore_active_ext_lang.
(ensure_python_env): Call set_active_ext_lang.
(gdbpy_clear_quit_flag): Renamed from clear_quit_flag, made static.
New arg extlang.
(gdbpy_set_quit_flag): Renamed from set_quit_flag, made static.
New arg extlang.
(gdbpy_check_quit_flag): Renamed from check_quit_flag, made static.
New arg extlang.
(gdbpy_eval_from_control_command): Renamed from
eval_python_from_control_command, made static. New arg extlang.
(gdbpy_source_script) Renamed from source_python_script, made static.
New arg extlang.
(gdbpy_before_prompt_hook): Renamed from before_prompt_hook. Change
result to int. New arg extlang.
(gdbpy_source_objfile_script): Renamed from
source_python_script_for_objfile, made static. New arg extlang.
(gdbpy_start_type_printers): Renamed from start_type_printers, made
static. New args extlang, extlang_printers. Change result type to
"void".
(gdbpy_apply_type_printers): Renamed from apply_type_printers, made
static. New arg extlang. Rename arg printers to extlang_printers
and change type to ext_lang_type_printers *.
(gdbpy_free_type_printers): Renamed from free_type_printers, made
static. Replace argument arg with extlang, extlang_printers.
(!HAVE_PYTHON, eval_python_from_control_command): Delete.
(!HAVE_PYTHON, source_python_script): Delete.
(!HAVE_PYTHON, gdbpy_should_stop): Delete.
(!HAVE_PYTHON, gdbpy_breakpoint_has_py_cond): Delete.
(!HAVE_PYTHON, start_type_printers): Delete.
(!HAVE_PYTHON, apply_type_printers): Delete.
(!HAVE_PYTHON, free_type_printers): Delete.
(_initialize_python): Delete call to observer_attach_before_prompt.
(finalize_python): Set/restore active extension language.
(gdbpy_finish_initialization) Renamed from
finish_python_initialization, made static. New arg extlang.
(gdbpy_initialized): New function.
* python/python.h: #include "extension.h". Delete #include
"value.h", "mi/mi-cmds.h".
(extension_language_python): Declare.
(GDBPY_AUTO_FILE_NAME): Delete.
(enum py_bt_status): Moved to extension.h and renamed to
ext_lang_bt_status.
(enum frame_filter_flags): Moved to extension.h.
(enum py_frame_args): Moved to extension.h and renamed to
ext_lang_frame_args.
(finish_python_initialization): Delete.
(eval_python_from_control_command): Delete.
(source_python_script): Delete.
(apply_val_pretty_printer): Delete.
(apply_frame_filter): Delete.
(preserve_python_values): Delete.
(gdbpy_script_language_defn): Delete.
(gdbpy_should_stop, gdbpy_breakpoint_has_py_cond): Delete.
(start_type_printers, apply_type_printers, free_type_printers): Delete.
* auto-load.c: #include "extension.h".
(GDB_AUTO_FILE_NAME): Delete.
(auto_load_gdb_scripts_enabled): Make public. New arg extlang.
(script_language_gdb): Delete, moved to extension.c and renamed to
extension_language_gdb.
(source_gdb_script_for_objfile): Delete.
(auto_load_pspace_info): New member unsupported_script_warning_printed.
(loaded_script): Change type of language member to
struct extension_language_defn *.
(init_loaded_scripts_info): Initialize
unsupported_script_warning_printed.
(maybe_add_script): Make static. Change type of language arg to
struct extension_language_defn *.
(clear_section_scripts): Reset unsupported_script_warning_printed.
(auto_load_objfile_script_1): Rewrite to use extension language API.
(auto_load_objfile_script): Make public. Remove support-compiled-in
and auto-load-enabled checks, moved to auto_load_scripts_for_objfile.
(source_section_scripts): Rewrite to use extension language API.
(load_auto_scripts_for_objfile): Rewrite to use
auto_load_scripts_for_objfile.
(collect_matching_scripts_data): Change type of language member to
struct extension_language_defn *.
(auto_load_info_scripts): Change type of language arg to
struct extension_language_defn *.
(unsupported_script_warning_print): New function.
(script_not_found_warning_print): Make static.
(_initialize_auto_load): Rewrite construction of scripts-directory
help.
* auto-load.h (struct objfile): Add forward decl.
(struct script_language): Delete.
(struct auto_load_pspace_info): Add forward decl.
(struct extension_language_defn): Add forward decl.
(maybe_add_script): Delete.
(auto_load_objfile_script): Declare.
(script_not_found_warning_print): Delete.
(auto_load_info_scripts): Update prototype.
(auto_load_gdb_scripts_enabled): Declare.
* python/py-auto-load.c (gdbpy_auto_load_enabled): Renamed from
auto_load_python_scripts_enabled and made public.
(script_language_python): Delete, moved to python.c.
(gdbpy_script_language_defn): Delete.
(info_auto_load_python_scripts): Update to use
extension_language_python.
* breakpoint.c (condition_command): Replace call to
gdbpy_breakpoint_has_py_cond with call to get_breakpoint_cond_ext_lang.
(bpstat_check_breakpoint_conditions): Replace call to gdbpy_should_stop
with call to breakpoint_ext_lang_cond_says_stop.
* python/py-breakpoint.c (gdbpy_breakpoint_cond_says_stop): Renamed
from gdbpy_should_stop. Change result type to enum scr_bp_stop.
New arg slang. Return SCR_BP_STOP_UNSET if py_bp_object is NULL.
(gdbpy_breakpoint_has_cond): Renamed from gdbpy_breakpoint_has_py_cond.
New arg slang.
(local_setattro): Print name of extension language with existing
stop condition.
* valprint.c (val_print, value_print): Update to call
apply_ext_lang_val_pretty_printer.
* cp-valprint.c (cp_print_value): Update call to
apply_ext_lang_val_pretty_printer.
* python/py-prettyprint.c: Remove #ifdef HAVE_PYTHON.
(gdbpy_apply_val_pretty_printer): Renamed from
apply_val_pretty_printer. New arg extlang.
(!HAVE_PYTHON, apply_val_pretty_printer): Delete.
* cli/cli-cmds.c (source_script_from_stream): Rewrite to use
extension language API.
* cli/cli-script.c (execute_control_command): Update to call
eval_ext_lang_from_control_command.
* mi/mi-cmd-stack.c (mi_cmd_stack_list_frames): Update to use
enum ext_lang_bt_status values. Update call to
apply_ext_lang_frame_filter.
(mi_cmd_stack_list_locals): Ditto.
(mi_cmd_stack_list_args): Ditto.
(mi_cmd_stack_list_variables): Ditto.
* mi/mi-main.c: Delete #include "python/python-internal.h".
Add #include "extension.h".
(mi_cmd_list_features): Replace reference to python internal variable
gdb_python_initialized with call to ext_lang_initialized_p.
* stack.c (backtrace_command_1): Update to use enum ext_lang_bt_status.
Update to use enum ext_lang_frame_args. Update to call
apply_ext_lang_frame_filter.
* python/py-framefilter.c (extract_sym): Update to use enum
ext_lang_bt_status.
(extract_value, py_print_type, py_print_value): Ditto.
(py_print_single_arg, enumerate_args, enumerate_locals): Ditto.
(py_mi_print_variables, py_print_locals, py_print_args): Ditto.
(py_print_frame): Ditto.
(gdbpy_apply_frame_filter): Renamed from apply_frame_filter.
New arg extlang. Update to use enum ext_lang_bt_status.
* top.c (gdb_init): Delete #ifdef HAVE_PYTHON call to
finish_python_initialization. Replace with call to
finish_ext_lang_initialization.
* typeprint.c (do_free_global_table): Update to call
free_ext_lang_type_printers.
(create_global_typedef_table): Update to call
start_ext_lang_type_printers.
(find_global_typedef): Update to call apply_ext_lang_type_printers.
* typeprint.h (struct ext_lang_type_printers): Add forward decl.
(type_print_options): Change type of global_printers from "void *"
to "struct ext_lang_type_printers *".
* value.c (preserve_values): Update to call preserve_ext_lang_values.
* python/py-value.c: Remove #ifdef HAVE_PYTHON.
(gdbpy_preserve_values): Renamed from preserve_python_values.
New arg extlang.
(!HAVE_PYTHON, preserve_python_values): Delete.
* utils.c (quit_flag): Delete, moved to extension.c.
(clear_quit_flag, set_quit_flag, check_quit_flag): Delete, moved to
extension.c.
* eval.c: Delete #include "python/python.h".
* main.c: Delete #include "python/python.h".
* defs.h: Update comment.
testsuite/
* gdb.python/py-breakpoint.exp (test_bkpt_eval_funcs): Update expected
output.
* gdb.gdb/python-interrupts.exp: New file.
This patch creates inferior when GDB opens a ctf trace data, to be
consistent with tfile target. A test case is added to test for
live target, tfile and ctf target.
gdb:
2014-02-05 Yao Qi <yao@codesourcery.com>
* ctf.c: Include "inferior.h" and "gdbthread.h".
(CTF_PID): A new macro.
(ctf_open): Call inferior_appeared and add_thread_silent.
(ctf_close): Call exit_inferior_silent and set inferior_ptid.
(ctf_thread_alive): New function.
(init_ctf_ops): Install ctf_thread_alive to to_thread_alive.
gdb/testsuite:
2014-02-05 Yao Qi <yao@codesourcery.com>
* gdb.trace/report.exp (use_collected_data): Test the output
of "info threads" and "info inferiors".
When a trace file is loaded in Eclipse, it is expected to see thread
and process (=thread-group-started and =thread-created). Create an
inferior and add a thread for this purpose.
This patch just reverts my previous patch.
gdb/testsuite:
2014-02-05 Yao Qi <yao@codesourcery.com>
Revert this patch:
2013-05-24 Yao Qi <yao@codesourcery.com>
* gdb.trace/tfile.exp: Test inferior and thread.
gdb:
2014-02-05 Yao Qi <yao@codesourcery.com>
Revert this patch:
2013-05-24 Yao Qi <yao@codesourcery.com>
* tracepoint.c (TFILE_PID): Remove.
(tfile_open): Don't add thread and inferior.
(tfile_close): Don't set 'inferior_ptid'. Don't call
exit_inferior_silent.
(tfile_thread_alive): Remove.
(init_tfile_ops): Don't set field 'to_thread_alive' of
tfile_ops.
This patch handles another aspect of the ELFv2 ABI, which unfortunately
requires common code changes.
In ELFv2, functions may provide both a global and a local entry point.
The global entry point (where the function symbol points to) is intended
to be used for function-pointer or cross-module (PLT) calls, and requires
r12 to be set up to the entry point address itself. The local entry
point (which is found at a fixed offset after the global entry point,
as defined by bits in the symbol table entries' st_other field), instead
expects r2 to be set up to the current TOC.
Now, when setting a breakpoint on a function by name, you really want
that breakpoint to trigger either way, no matter whether the function
is called via its local or global entry point. Since the global entry
point will always fall through into the local entry point, the way to
achieve that is to simply set the breakpoint at the local entry point.
One way to do that would be to have prologue parsing skip the code
sequence that makes up the global entry point. Unfortunately, this
does not work reliably, since -for optimized code- GDB these days
will not actuall invoke the prologue parsing code but instead just
set the breakpoint at the symbol address and rely on DWARF being
correct at any point throughout the function ...
Unfortunately, I don't really see any way to express the notion of
local entry points with the current set of gdbarch callbacks.
Thus this patch adds a new callback, skip_entrypoint, that is
somewhat analogous to skip_prologue, but is called every time
GDB needs to determine a function start address, even in those
cases where GDB decides to not call skip_prologue.
As a side effect, the skip_entrypoint implementation on ppc64
does not need to perform any instruction parsing; it can simply
rely on the local entry point flags in the symbol table entry.
With this implemented, two test cases would still fail to set
the breakpoint correctly, but that's because they use the construct:
gdb_test "break *hello"
Now, using "*hello" explicitly instructs GDB to set the breakpoint
at the numerical value of "hello" treated as function pointer, so
it will by definition only hit the global entry point.
I think this behaviour is unavoidable, but acceptable -- most people
do not use this construct, and if they do, they get what they
asked for ...
In one of those two test cases, use of this construct is really
not appropriate. I think this was added way back when as a means
to work around prologue skipping problems on some platforms. These
days that shouldn't really be necessary any more ...
For the other (step-bt), we really want to make sure backtracing
works on the very first instruction of the routine. To enable that
test also on powerpc64le-linux, we can modify the code to call the
test function via function pointer (which makes it use the global
entry point in the ELFv2 ABI).
gdb/ChangeLog:
* gdbarch.sh (skip_entrypoint): New callback.
* gdbarch.c, gdbarch.h: Regenerate.
* symtab.c (skip_prologue_sal): Call gdbarch_skip_entrypoint.
* infrun.c (fill_in_stop_func): Likewise.
* ppc-linux-tdep.c: Include "elf/ppc64.h".
(ppc_elfv2_elf_make_msymbol_special): New function.
(ppc_elfv2_skip_entrypoint): Likewise.
(ppc_linux_init_abi): Install them for ELFv2.
gdb/testsuite/ChangeLog:
* gdb.base/sigbpt.exp: Do not use "*" when setting breakpoint
on a function.
* gdb.base/step-bt.c: Call hello via function pointer to make
sure its first instruction is executed on powerpc64le-linux.
The powerpc64le-linux ABI specifies that when a 128-bit DFP value is
passed in a pair of floating-point registers, the first register holds
the most-significant part of the value. This is as opposed to the
usual rule on little-endian systems, where the first register would
hold the least-significant part.
This affects two places in GDB, the read/write routines for the
128-bit DFP pseudo-registers, and the function call / return
sequence. For the former, current code already distinguishes
between big- and little-endian targets, but gets the latter
wrong. This is presumably because *GCC* also got it wrong,
and GDB matches the old GCC behavior. But GCC is now fixed:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02145.html
so GDB needs to be fixed too. (Old code shouldn't really be
an issue since there is no code "out there" so far that uses
dfp128 on little-endian ...)
gdb/ChangeLog:
* ppc-sysv-tdep.c (ppc64_sysv_abi_push_freg): Use correct order
within a register pair holding a DFP 128-bit value on little-endian.
(ppc64_sysv_abi_return_value_base): Likewise.
* rs6000-tdep.c (dfp_pseudo_register_read): Likewise.
(dfp_pseudo_register_write): Likewise.
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-d128-regs.exp: Enable on powerpc64*-*.
Many VSX test were failing on powerpc64le-linux, since -as opposed to the
AltiVec tests- there never were little-endian versions of the test patterns.
This patch adds such patterns, along the lines of altivec-regs.exp.
In addition, there is an actual code change required: For those VSX
registers that overlap a floating-point register, the FP register
overlaps the most-significant half of the VSX register both on big-
and little-endian systems. However, on little-endian systems, that
half is stored at an offset of 8 bytes (not 0). This works already
for the "real" FP registers, but current code gets it wrong for
the "extended" pseudo FP register GDB generates for the second
half of the VSX register bank.
This patch updates the corresponding pseudo read/write routines
to take the appropriate offset into consideration.
gdb/ChangeLog:
* rs6000-tdep.c (efpr_pseudo_register_read): Use correct offset
of the overlapped FP register within the VSX register on little-
endian platforms.
(efpr_pseudo_register_write): Likewise.
gdb/testsuite/ChangeLog:
* gdb.arch/vsx-regs.exp: Check target endianness. Provide variants
of the test patterns for use on little-endian systems.
A couple of AltiVec tests fail spuriously on powerpc64le-linux, because
they compare against an incorrect pattern. Note that those tests already
contain little-endian variants of the patterns, but those seem to have
bit-rotted a bit: when outputting a vector, GDB no longer omits trailing
zero elements (as it used to do in the past).
This patch updates the pattern to the new GDB output behavior.
In addition, the patch updates the endian test to use the new
gdb_test_multiple logic instead of gdb_expect.
gdb/testsuite/ChangeLog:
* gdb.arch/altivec-regs.exp: Use gdb_test_multiple for endian test.
(decimal_vector): Fix for little-endian.