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.
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 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).
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.
* 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.
On ppc64-linux a function symbol does not point to code, but to the
function descriptor. Thus the previous change for this test case
broke it:
https://sourceware.org/ml/gdb-patches/2014-01/msg00275.html
This patch reverts to the original method, re-introducing '_start'
symbols. In addition, it adds sufficient alignment before the label,
such that the label never points into an alignment gap.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-dir-file-name.c (FUNC): Insert alignment and
define "*_start" label. Make "name" static.
* gdb.dwarf2/dw2-dir-file-name.exp: Replace references to
${name} by references to ${name}_start.
This test currently fails on ARM:
(gdb) PASS: gdb.dwarf2/dw2-dos-drive.exp: set breakpoint pending off
break 'z:file.c':func
Cannot access memory at address 0x0
The error is GDB trying to read the prologue at the breakpoint's
address, and failing:
38 throw_error() exceptions.c:444 0x0016728c
37 memory_error() corefile.c:204 0x001d1fcc
36 read_memory() corefile.c:223 0x001d201a
35 read_memory_unsigned_integer() corefile.c:312 0x001d2166
34 arm_skip_prologue() arm-tdep.c:1452 0x00054270
static CORE_ADDR
arm_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc)
{
...
for (skip_pc = pc; skip_pc < limit_pc; skip_pc += 4)
{
inst = read_memory_unsigned_integer (skip_pc, 4, byte_order_for_code);
The test doesn't execute the compiled object's code, so GDB will try
to read memory from the binary's sections. Instructions on ARM are
4-byte wide, and thus ARM's prologue scanner reads in 4-byte chunks.
As the section 'func' is put at is only 1 byte long, and no other
section is allocated contiguously:
...
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000001 00000000 00000000 00000034 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
...
... the exec target fails the read the 4 bytes.
Fix this by increasing the function's size.
gdb/testsuite/ChangeLog:
2014-01-16 Omair Javaid <Omair.Javaid@linaro.org>
* gdb.dwarf2/dw2-dos-drive.S: Increase text section size to 4
bytes.
S390, the dw2-dir-file-name test case fails in the first
gdb_continue_to_breakpoint. Indeed, the breakpoint is now placed into
the alignment gap *before* the actual function.
This happens because the test case declares the respective "*_start"
symbol as a "loose" label before the function definition, and the
compiler inserts the alignment between that label and the function
itself.
The "*_start" symbols were only necessary because FUNC made the
function static. The fix makes the functions extern instead, thus
making the "*_start" labels unnecessary.
testsuite/
2014-01-10 Andreas Arnez <arnez@linux.vnet.ibm.com>
Pedro Alves <palves@redhat.com>
* gdb.dwarf2/dw2-dir-file-name.c (FUNC): Remove "*_start" symbol.
Make "name" extern.
* gdb.dwarf2/dw2-dir-file-name.exp (out_cu, out_line): Replace
references to ${name}_start by references to ${name}.
Doing "info frame" in the outermost frame, when that was indicated by
the next frame saying the unwound PC is undefined/not saved, results
in error and incomplete output:
(gdb) bt
#0 thread_function0 (arg=0x0) at threads.c:63
#1 0x00000034cf407d14 in start_thread (arg=0x7ffff7fcb700) at pthread_create.c:309
#2 0x000000323d4f168d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
(gdb) frame 2
#2 0x000000323d4f168d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
115 call *%rax
(gdb) info frame
Stack level 2, frame at 0x0:
rip = 0x323d4f168d in clone (../sysdeps/unix/sysv/linux/x86_64/clone.S:115); saved rip Register 16 was not saved
(gdb)
Not saved register values are treated as optimized out values
internally throughout. stack.c:frame_info is handing unvailable
values, but not optimized out ones. The patch deletes the
frame_unwind_caller_pc_if_available wrapper function and instead lets
errors propagate to frame_info (it's only user).
As frame_unwind_pc now needs to be able to handle and cache two
different error scenarios, the prev_pc.p variable is replaced with an
enumeration.
(FWIW, I looked into making gdbarch_unwind_pc or a variant return
struct value's instead, but it results in lots of boxing and unboxing
for no real gain -- e.g., the mips and arm implementations need to do
computation on the unboxed PC value. Might as well throw an error on
first attempt to get at invalid contents.)
After the patch, we get:
(gdb) info frame
Stack level 2, frame at 0x0:
rip = 0x323d4f168d in clone (../sysdeps/unix/sysv/linux/x86_64/clone.S:115); saved rip = <not saved>
Outermost frame: outermost
caller of frame at 0x7ffff7fcafc0
source language asm.
Arglist at 0x7ffff7fcafb8, args:
Locals at 0x7ffff7fcafb8, Previous frame's sp is 0x7ffff7fcafc8
(gdb)
A new test is added. It's based off dw2-reg-undefined.exp, and tweaked to
mark the return address (rip) of "stop_frame" as undefined.
Tested on x86_64 Fedora 17.
gdb/
2013-12-06 Pedro Alves <palves@redhat.com>
* frame.c (enum cached_copy_status): New enum.
(struct frame_info) <prev_pc.p>: Change type to enum
cached_copy_status.
(fprint_frame): Handle not saved and unavailable prev_pc values.
(frame_unwind_pc_if_available): Delete and merge contents into ...
(frame_unwind_pc): ... here. Handle OPTIMIZED_OUT_ERROR. Adjust
to use enum cached_copy_status.
(frame_unwind_caller_pc_if_available): Delete.
(create_new_frame): Adjust.
* frame.h (frame_unwind_caller_pc_if_available): Delete
declaration.
* stack.c (frame_info): Use frame_unwind_caller_pc instead of
frame_unwind_caller_pc_if_available, and handle
NOT_AVAILABLE_ERROR and OPTIMIZED_OUT_ERROR errors.
* valprint.c (val_print_optimized_out): Use val_print_not_saved.
(val_print_not_saved): New function.
* valprint.h (val_print_not_saved): Declare.
gdb/testsuite/
2013-12-06 Pedro Alves <palves@redhat.com>
* gdb.dwarf2/dw2-undefined-ret-addr.S: New file.
* gdb.dwarf2/dw2-undefined-ret-addr.c: New file.
* gdb.dwarf2/dw2-undefined-ret-addr.exp: New file.
gdb/
2013-12-02 Doug Evans <dje@google.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
* objfiles.c (allocate_objfile): Save original_name as an absolute
path.
* objfiles.h (struct objfile): Expand comment on original_name.
* source.c (openp): Call gdb_abspath.
* utils.c (gdb_abspath): New function.
* utils.h (gdb_abspath): Declare.
gdb/testsuite/
2013-12-02 Doug Evans <dje@google.com>
* gdb.dwarf/dwp-symlink.c: Fake out gdb to not load debug info
at start.
* gdb.dwarf/dwp-symlink.exp: Test trying to load dwp when the binary
has been specified with a relative path and we have chdir'd before
accessing the debug info.
This reverts da2b2fdf57 and some
follow-up patches. They were incorrect.
2013-11-26 Tom Tromey <tromey@redhat.com>
* dwarf2-frame.c (dwarf2_frame_cache): Revert patch from
2013-11-22.
2013-11-26 Tom Tromey <tromey@redhat.com>
* gdb.dwarf2/dw2-unspecified-ret-addr.S: Remove.
* gdb.dwarf2/dw2-unspecified-ret-addr.c: Remove.
* gdb.dwarf2/dw2-unspecified-ret-addr.exp: Remove.
Pedro asked me to add a comment to dw2-bad-cfi.S explaining the nature
of the badness.
I'm checking this in.
2013-11-22 Tom Tromey <tromey@redhat.com>
* gdb.dwarf2/dw2-bad-cfi.S: Update comment.
Debugging PR 16155 further, I found that the DWARF unwinder found the
function in question, but thought it had no registers saved
(fs->regs.num_regs == 0).
It seems to me that if a frame does not specify the return address
column, or if the return address column is explicitly marked as
DWARF2_FRAME_REG_UNSPECIFIED, then we should set the
"undefined_retaddr" flag and let the DWARF unwinder gracefully stop.
This patch implements that idea.
With this patch the backtrace works properly:
(gdb) bt
#0 0x0000007fb7ed485c in nanosleep () from /lib64/libc.so.6
#1 0x0000007fb7ed4508 in sleep () from /lib64/libc.so.6
#2 0x00000000004008bc in thread_function (arg=0x4) at threadapply.c:73
#3 0x0000007fb7fad950 in start_thread () from /lib64/libpthread.so.0
#4 0x0000007fb7f0956c in clone () from /lib64/libc.so.6
2013-11-22 Tom Tromey <tromey@redhat.com>
PR backtrace/16155:
* dwarf2-frame.c (dwarf2_frame_cache): Set undefined_retaddr if
the return address column is unspecified.
2013-11-22 Tom Tromey <tromey@redhat.com>
* gdb.dwarf2/dw2-bad-cfi.c: New file.
* gdb.dwarf2/dw2-bad-cfi.exp: New file.
* gdb.dwarf2/dw2-bad-cfi.S: New file.
The UNWIND_SAME_ID check is done between THIS_FRAME and the next frame
when we go try to unwind the previous frame. But at this point, it's
already too late -- we ended up with two frames with the same ID in
the frame chain. Each frame having its own ID is an invariant assumed
throughout GDB. This patch applies the UNWIND_SAME_ID detection
earlier, right after the previous frame is unwound, discarding the dup
frame if a cycle is detected.
The patch includes a new test that fails before the change. Before
the patch, the test causes an infinite loop in GDB, after the patch,
the UNWIND_SAME_ID logic kicks in and makes the backtrace stop with:
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The test uses dwarf CFI to emulate a corrupted stack with a cycle. It
has a function with registers marked DW_CFA_same_value (most
importantly RSP/RIP), so that GDB computes the same ID for that frame
and its caller. IOW, something like this:
#0 - frame_id_1
#1 - frame_id_2
#2 - frame_id_3
#3 - frame_id_4
#4 - frame_id_4 <<<< outermost (UNWIND_SAME_ID).
(The test's code is just a copy of dw2-reg-undefined.S /
dw2-reg-undefined.c, adjusted to use DW_CFA_same_value instead of
DW_CFA_undefined, and to mark a different set of registers.)
The infinite loop is here, in value_fetch_lazy:
while (VALUE_LVAL (new_val) == lval_register && value_lazy (new_val))
{
frame = frame_find_by_id (VALUE_FRAME_ID (new_val));
...
new_val = get_frame_register_value (frame, regnum);
}
get_frame_register_value can return a lazy register value pointing to
the next frame. This means that the register wasn't clobbered by
FRAME; the debugger should therefore retrieve its value from the next
frame.
To be clear, get_frame_register_value unwinds the value in question
from the next frame:
struct value *
get_frame_register_value (struct frame_info *frame, int regnum)
{
return frame_unwind_register_value (frame->next, regnum);
^^^^^^^^^^^
}
In other words, if we get a lazy lval_register, it should have the
frame ID of the _next_ frame, never of FRAME.
At this point in value_fetch_lazy, the whole relevant chunk of the
stack up to frame #4 has already been unwound. The loop always
"unlazies" lval_registers in the "next/innermost" direction, not in
the "prev/unwind further/outermost" direction.
So say we're looking at frame #4. get_frame_register_value in frame
#4 can return a lazy register value of frame #3. So the next
iteration, frame_find_by_id tries to read the register from frame #3.
But, since frame #4 happens to have same id as frame #3,
frame_find_by_id returns frame #4 instead. Rinse, repeat, and we have
an infinite loop.
This is an old latent problem, exposed by the recent addition of the
frame stash. Before we had a stash, frame_find_by_id(frame_id_4)
would walk over all frames starting at the current frame, and would
always find #3 first. The stash happens to return #4 instead:
struct frame_info *
frame_find_by_id (struct frame_id id)
{
struct frame_info *frame, *prev_frame;
...
/* Try using the frame stash first. Finding it there removes the need
to perform the search by looping over all frames, which can be very
CPU-intensive if the number of frames is very high (the loop is O(n)
and get_prev_frame performs a series of checks that are relatively
expensive). This optimization is particularly useful when this function
is called from another function (such as value_fetch_lazy, case
VALUE_LVAL (val) == lval_register) which already loops over all frames,
making the overall behavior O(n^2). */
frame = frame_stash_find (id);
if (frame)
return frame;
for (frame = get_current_frame (); ; frame = prev_frame)
{
gdb/
2013-11-22 Pedro Alves <palves@redhat.com>
PR 16155
* frame.c (get_prev_frame_1): Do the UNWIND_SAME_ID check between
this frame and the new previous frame, not between this frame and
the next frame.
gdb/testsuite/
2013-11-22 Pedro Alves <palves@redhat.com>
PR 16155
* gdb.dwarf2/dw2-dup-frame.S: New file.
* gdb.dwarf2/dw2-dup-frame.c: New file.
* gdb.dwarf2/dw2-dup-frame.exp: New file.
The UNWIND_SAME_ID check is done between THIS_FRAME and the next frame
when we go try to unwind the previous frame. But at this point, it's
already too late -- we ended up with two frames with the same ID in
the frame chain. Each frame having its own ID is an invariant assumed
throughout GDB. This patch applies the UNWIND_SAME_ID detection
earlier, right after the previous frame is unwound, discarding the dup
frame if a cycle is detected.
The patch includes a new test that fails before the change. Before
the patch, the test causes an infinite loop in GDB, after the patch,
the UNWIND_SAME_ID logic kicks in and makes the backtrace stop with:
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
The test uses dwarf CFI to emulate a corrupted stack with a cycle. It
has a function with registers marked DW_CFA_same_value (most
importantly RSP/RIP), so that GDB computes the same ID for that frame
and its caller. IOW, something like this:
#0 - frame_id_1
#1 - frame_id_2
#2 - frame_id_3
#3 - frame_id_4
#4 - frame_id_4 <<<< outermost (UNWIND_SAME_ID).
(The test's code is just a copy of dw2-reg-undefined.S /
dw2-reg-undefined.c, adjusted to use DW_CFA_same_value instead of
DW_CFA_undefined, and to mark a different set of registers.)
The infinite loop is here, in value_fetch_lazy:
while (VALUE_LVAL (new_val) == lval_register && value_lazy (new_val))
{
frame = frame_find_by_id (VALUE_FRAME_ID (new_val));
...
new_val = get_frame_register_value (frame, regnum);
}
get_frame_register_value can return a lazy register value pointing to
the next frame. This means that the register wasn't clobbered by
FRAME; the debugger should therefore retrieve its value from the next
frame.
To be clear, get_frame_register_value unwinds the value in question
from the next frame:
struct value *
get_frame_register_value (struct frame_info *frame, int regnum)
{
return frame_unwind_register_value (frame->next, regnum);
^^^^^^^^^^^
}
In other words, if we get a lazy lval_register, it should have the
frame ID of the _next_ frame, never of FRAME.
At this point in value_fetch_lazy, the whole relevant chunk of the
stack up to frame #4 has already been unwound. The loop always
"unlazies" lval_registers in the "next/innermost" direction, not in
the "prev/unwind further/outermost" direction.
So say we're looking at frame #4. get_frame_register_value in frame
#4 can return a lazy register value of frame #3. So the next
iteration, frame_find_by_id tries to read the register from frame #3.
But, since frame #4 happens to have same id as frame #3,
frame_find_by_id returns frame #4 instead. Rinse, repeat, and we have
an infinite loop.
This is an old latent problem, exposed by the recent addition of the
frame stash. Before we had a stash, frame_find_by_id(frame_id_4)
would walk over all frames starting at the current frame, and would
always find #3 first. The stash happens to return #4 instead:
struct frame_info *
frame_find_by_id (struct frame_id id)
{
struct frame_info *frame, *prev_frame;
...
/* Try using the frame stash first. Finding it there removes the need
to perform the search by looping over all frames, which can be very
CPU-intensive if the number of frames is very high (the loop is O(n)
and get_prev_frame performs a series of checks that are relatively
expensive). This optimization is particularly useful when this function
is called from another function (such as value_fetch_lazy, case
VALUE_LVAL (val) == lval_register) which already loops over all frames,
making the overall behavior O(n^2). */
frame = frame_stash_find (id);
if (frame)
return frame;
for (frame = get_current_frame (); ; frame = prev_frame)
{
gdb/
2013-11-22 Pedro Alves <palves@redhat.com>
PR 16155
* frame.c (get_prev_frame_1): Do the UNWIND_SAME_ID check between
this frame and the new previous frame, not between this frame and
the next frame.
gdb/testsuite/
2013-11-22 Pedro Alves <palves@redhat.com>
PR 16155
* gdb.dwarf2/dw2-dup-frame.S: New file.
* gdb.dwarf2/dw2-dup-frame.c: New file.
* gdb.dwarf2/dw2-dup-frame.exp: New file.
dw2-case-insensitive.exp: p fuNC_lang fails on arm. The problem occurs
when thumb mode code is generated. On ARM last bit of function pointer
value indicates whether the target function is an ARM (if 0) or Thumb
(if 1) routine. The PC address should refer to actual address in
either case. This patch adds new compile unit and function labels to
code which act as address ranges of compile unit and functions in
debug information. Therefore address ranges will have correct
addresses and not the ones with an incremented least significant bit.
This patch has been tested on x86_64 and arm machines.
gdb/testsuite/ChangeLog:
2013-11-14 Omair Javaid <Omair.Javaid@linaro.org>
* gdb.dwarf2/dw2-case-insensitive-debug.S: Updated compile unit
and function label names.
* gdb.dwarf2/dw2-case-insensitive.c: Created function and
compile unit labels.
A couple of Fission tests rely on the current directory layout. This
assumption is not valid in parallel mode.
This patch fixes the problem by removing the relative directory from
the .S files and instead having the tests set debug-file-directory
before opening the main file.
2013-11-04 Tom Tromey <tromey@redhat.com>
* gdb.dwarf2/fission-base.S: Remove "gdb.dwarf/".
* gdb.dwarf2/fission-base.exp: Set debug-file-directory
before loading binfile.
* gdb.dwarf2/fission-loclists.S: Remove "gdb.dwarf/".
* gdb.dwarf2/fission-loclists.exp: Set debug-file-directory
before loading binfile.
This patch fixes gdb PR symtab/15597.
The bug is that the .gnu_debugaltlink section includes the build-id of
the alt file, but gdb does not use it.
This patch fixes the problem by changing gdb to do what it ought to
always have done: verify the build id of the file found using the
filename in .gnu_debugaltlink; and if that does not match, try to find
the correct debug file using the build-id and debug-file-directory.
This patch touches BFD. Previously, gdb had its own code for parsing
.gnu_debugaltlink; I changed it to use the BFD functions after those
were introduced. However, the BFD functions are incorrect -- they
assume that .gnu_debugaltlink is formatted like .gnu_debuglink.
However, it it is not. Instead, it consists of a file name followed
by the build-id -- no alignment, and the build-id is not a CRC.
Fixing this properly is a bit of a pain. But, because
separate_alt_debug_file_exists just has a FIXME for the build-id case,
I did not fix it properly. Instead I introduced a hack. This leaves
BFD working just as well as it did before my patch.
I'm willing to do something better here but I could use some guidance
as to what. It seems that the build-id code in BFD is largely punted
on.
FWIW gdb is the only user of bfd_get_alt_debug_link_info outside of
BFD itself.
I moved the build-id logic out of elfread.c and into a new file.
This seemed cleanest to me.
Writing a test case was a bit of a pain. I added a couple new
features to the DWARF assembler to handle this.
Built and regtested on x86-64 Fedora 18.
* bfd-in2.h: Rebuild.
* opncls.c (bfd_get_alt_debug_link_info): Add buildid_len
parameter. Change type of buildid_out. Update.
(get_alt_debug_link_info_shim): New function.
(bfd_follow_gnu_debuglink): Use it.
* Makefile.in (SFILES): Add build-id.c.
(HFILES_NO_SRCDIR): Add build-id.h.
* build-id.c: New file, largely from elfread.c. Modified
most functions.
* build-id.h: New file.
* dwarf2read.c (dwarf2_get_dwz_file): Update for change to
bfd_get_alt_debug_link_info. Verify dwz file's build-id.
Search for dwz file using build-id.
* elfread.c (build_id_bfd_get, build_id_verify)
(build_id_to_debug_filename, find_separate_debug_file): Remove.
* gdb.dwarf2/dwzbuildid.exp: New file.
* lib/dwarf.exp (Dwarf::_section): Add "flags" and "type"
parameters.
(Dwarf::_defer_output): Change "section" parameter to
"section_spec"; update.
(Dwarf::gnu_debugaltlink, Dwarf::_note, Dwarf::build_id): New
procs.
Currently, in some scenarios, GDB prints <optimized out> when printing
outer frame registers. An <optimized out> register is a confusing
concept. What this really means is that the register is
call-clobbered, or IOW, not saved by the callee. This patch makes GDB
say that instead.
Before patch:
(gdb) p/x $rax $1 = <optimized out>
(gdb) info registers rax
rax <optimized out>
After patch:
(gdb) p/x $rax
$1 = <not saved>
(gdb) info registers rax
rax <not saved>
However, if for some reason the debug info describes a variable as
being in such a register (**), we still want to print <optimized out>
when printing the variable. IOW, <not saved> is reserved for
inspecting registers at the machine level. The patch uses
lval_register+optimized_out to encode the not saved registers, and
makes it so that optimized out variables always end up in
!lval_register values.
** See <https://sourceware.org/ml/gdb-patches/2012-08/msg00787.html>.
Current/recent enough GCC doesn't mark variables/arguments as being in
call-clobbered registers in the ranges corresponding to function
calls, while older GCCs did. Newer GCCs will just not say where the
variable is, so GDB will end up realizing the variable is optimized
out.
frame_unwind_got_optimized creates not_lval optimized out registers,
so by default, in most cases, we'll see <optimized out>.
value_of_register is the function eval.c uses for evaluating
OP_REGISTER (again, $pc, etc.), and related bits. It isn't used for
anything else. This function makes sure to return lval_register
values. The patch makes "info registers" and the MI equivalent use it
too. I think it just makes a lot of sense, as this makes it so that
when printing machine registers ($pc, etc.), we go through a central
function.
We're likely to need a different encoding at some point, if/when we
support partially saved registers. Even then, I think
value_of_register will still be the spot to tag the intention to print
machine register values differently.
value_from_register however may also return optimized out
lval_register values, so at a couple places where we're computing a
variable's location from a dwarf expression, we convert the resulting
value away from lval_register to a regular optimized out value.
Tested on x86_64 Fedora 17
gdb/
2013-10-02 Pedro Alves <palves@redhat.com>
* cp-valprint.c (cp_print_value_fields): Adjust calls to
val_print_optimized_out.
* jv-valprint.c (java_print_value_fields): Likewise.
* p-valprint.c (pascal_object_print_value_fields): Likewise.
* dwarf2loc.c (dwarf2_evaluate_loc_desc_full)
<DWARF_VALUE_REGISTER>: If the register was not saved, return a
new optimized out value.
* findvar.c (address_from_register): Likewise.
* frame.c (put_frame_register): Tweak error string to say the
register was not saved, rather than optimized out.
* infcmd.c (default_print_one_register_info): Adjust call to
val_print_optimized_out. Use value_of_register instead of
get_frame_register_value.
* mi/mi-main.c (output_register): Use value_of_register instead of
get_frame_register_value.
* valprint.c (valprint_check_validity): Likewise.
(val_print_optimized_out): New value parameter. If the value is
lval_register, print <not saved> instead.
(value_check_printable, val_print_scalar_formatted): Adjust calls
to val_print_optimized_out.
* valprint.h (val_print_optimized_out): New value parameter.
* value.c (struct value) <optimized_out>: Extend comment.
(error_value_optimized_out): New function.
(require_not_optimized_out): Use it. Use a different string for
lval_register values.
* value.h (error_value_optimized_out): New declaration.
* NEWS: Mention <not saved>.
gdb/testsuite/
2013-10-02 Pedro Alves <palves@redhat.com>
* gdb.dwarf2/dw2-reg-undefined.exp <pattern_rax_rbx_rcx_print,
pattern_rax_rbx_rcx_info>: Set to "<not saved>".
* gdb.mi/mi-reg-undefined.exp (opt_out_pattern): Delete.
(not_saved_pattern): New.
Replace use of the former with the latter.
gdb/doc/
2013-10-02 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Registers): Expand description of saved registers
in frames. Explain <not saved>.
gdb/
2013-09-24 Jan Kratochvil <jan.kratochvil@redhat.com>
* dwarf2read.c (open_and_init_dwp_file): Try open_dwp_file also with
objfile->original_name.
gdb/testsuite/
2013-09-24 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.dwarf2/dwp-symlink.c: New file.
* gdb.dwarf2/dwp-symlink.exp: New file.
https://sourceware.org/ml/gdb-patches/2013-08/msg00170.html
gdb/ChangeLog
* infcmd.c (default_print_one_register_info): Add detection of
optimized out values.
(default_print_registers_info): Switch to using
get_frame_register_value.
gdb/testsuite/ChangeLog
* gdb.dwarf2/dw2-reg-undefined.exp: Change pattern for info
register to "<optimized out>", and also print the registers.
This finishes making gdb.dwarf2 parallel-safe.
To do this, this patch introduces a new gdb_remote_download proc, that
works somewhat differently in the one specific case where it matters:
for a copy to "host", if no destination was given, and the host is not
actually remote, then standard_output_file is used. In parallel mode
this guarantees that the resulting file will end up in a parallel-safe
location.
Tested on x86-64 Fedora 18.
* gdb.dwarf2/dw2-basic.exp: Use gdb_remote_download.
* gdb.dwarf2/dw2-compressed.exp: Use gdb_remote_download.
* gdb.dwarf2/dw2-intercu.exp: Use gdb_remote_download.
* gdb.dwarf2/dw2-intermix.exp: Use gdb_remote_download.
* gdb.dwarf2/dw2-producer.exp: Use gdb_remote_download.
* gdb.dwarf2/mac-fileno.exp: Use gdb_remote_download.
* lib/gdb.exp (gdb_remote_download): New proc.
This fixes a few gdb.dwarf2 tests to be more parallel-safe. This
mostly amounts to changing them to write their files into the
directory designated by standard_output_file.
Built and regtested on x86-64 Fedora 18.
* gdb.dwarf2/clztest.exp: Use standard_testfile.
* gdb.dwarf2/dw2-minsym-in-cu.exp: Use standard_testfile.
* gdb.dwarf2/fission-base.S: Remove directory from
DW_AT_GNU_dwo_name.
* gdb.dwarf2/fission-base.exp: Use build_executable. Set
debug-file-directory.
* gdb.dwarf2/fission-reread.S: Remove directory from
DW_AT_GNU_dwo_name.
* gdb.dwarf2/fission-reread.exp: Use build_executable. Set
debug-file-directory.
Doug pointed out a while ago that in the final dwz -m patch, nothing
ever set symtab::user.
This patch fixes this oversight and adds a test case showing why it is
important.
Built and regtested (both ways) on x86-64 Fedora 18.
The new test unconditionally tests the partial unit machinery, which I
think is an added plus.
* dwarf2read.c (recursively_compute_inclusions): Add
"immediate_parent" argument. Set symtab's "user" field
if not set.
(compute_symtab_includes): Update.
* gdb.dwarf2/dwz.exp: New file.
* dwarf2read.c (struct dwarf2_per_cu_data): New member tu_read.
(fill_in_sig_entry_from_dwo_entry): Reorganize asserts.
Add assert of sig_entry->dwo_unit == NULL.
(lookup_dwo_signatured_type): Don't assign TU to a DWO if the TU
had already been read.
(read_signatured_type): Set per_cu.tu_read.
testsuite/
* gdb.dwarf2/fission-mix.exp: New file.
* gdb.dwarf2/fission-mix.h: New file.
* gdb.dwarf2/fission-mix.c: New file.
* gdb.dwarf2/fission-mix2.c: New file.
http://sourceware.org/ml/gdb-patches/2013-07/msg00317.html
gdb/ChangeLog
* value.c (value_fetch_lazy): Mark optimized out values as such
rather than raising an error.
gdb/testsuite/ChangeLog
* gdb.dwarf2/pieces-optimized-out.exp: Expect "<optimized out>"
when printing an optimized out value. Expect an error when using
an optimized out value in an expression.
http://sourceware.org/ml/gdb-patches/2013-07/msg00316.html
gdb/ChangeLog
* value.c (value_fetch_lazy): Ensure parent value is not lazy
before checking which bits of the parent, not the child, value are
valid.
gdb/testsuite/ChangeLog
* gdb.dwarf2/pieces-optimized-out.exp: New file.
* gdb.dwarf2/pieces-optimized-out.c: New file.
* gdb.dwarf2/pieces-optimized-out.S: New file.
The ARM assembler recognises @ symbol as a comment marker and
therefore is unable to assemble some of gdb.dwarf2 testsuite tests.
This patch replaces all occurrences of @ symbol with % sign to allow
tests stay compatible with both ARM and x86 assembly. This patch has
been tested on x86_64 and ARMv7 targets.
gdb/testsuite/ChangeLog:
2013-07-19 Omair Javaid <Omair.Javaid@linaro.org>
* gdb.dwarf2/fission-reread.S: Replace @ sign with % sign to remove
assembler errors on arm.
* gdb.dwarf2/mac-fileno.S: Likewise.
* gdb.dwarf2/member-ptr-forwardref.S: Likewise.
* gdb.dwarf2/pr13961.S: Likewise.
gdb/ChangeLog
* stack.c (read_frame_arg): No longer fetch lazy values.
* value.c (value_optimized_out): If the value is not already
marked optimized out, and is lazy then fetch it.
(value_primitive_field): Move optimized out check to later in the
function, after we have loaded any lazy values.
(value_fetch_lazy): Use optimized out flag directly rather than
calling optimized_out method.
gdb/testsuite/ChangeLog
* gdb.dwarf2/dw2-reg-undefined.exp: New file.
* gdb.dwarf2/dw2-reg-undefined.c: Likewise.
* gdb.dwarf2/dw2-reg-undefined.S: Likewise.
PR symtab/15391 is a failure with the DW_OP_GNU_implicit_pointer
feature.
I tracked it down to a logic error in read_pieced_value. The code
truncates this_size_bits according to the type size and offset too
early -- it should do it after taking bits_to_skip into account.
This patch fixes the bug.
While testing this, I also tripped across a latent bug because
indirect_pieced_value does not sign-extend where needed. This patch
fixes this bug as well.
Finally, Pedro pointed out that a previous version implemented sign
extension incorrectly. This version introduces a new gdb_sign_extend
function for this. A couple of notes on this function:
* It has the gdb_ prefix to avoid clashes with various libraries that
felt free to avoid proper namespacing. There is a "sign_extend"
function in a Tile GX header, in an SOM-related BFD header (and in
sh64-tdep.c and as a macro in arm-wince-tdep.c, but those are
ours...)
* I looked at all the sign extensions in gdb and didn't see ones that
I felt comfortable converting to use this function; in large part
because I don't have a good way to test the conversion.
Built and regtested on x86-64 Fedora 18. New test cases included;
this required a minor addition to the DWARF assembler. Note that the
DWARF CU made by implptrpiece.exp uses a funny pointer size in order
to show the sign-extension bug on all platforms.
* dwarf2loc.c (read_pieced_value): Truncate this_size_bits
after taking bits_to_skip into account. Sign extend byte_offset.
* utils.h (gdb_sign_extend): Declare.
* utils.c (gdb_sign_extend): New function.
* gdb.dwarf2/implptrpiece.exp: New file.
* gdb.dwarf2/implptrconst.exp (d): New variable.
Print d.
* lib/dwarf2.exp (Dwarf::_location): Handle DW_OP_piece.
