Commit graph

229 commits

Author SHA1 Message Date
Joel Brobecker
8b558f797a gdb.ada/info_exc.exp: Adjust expected output in "info exception" test.
Since multi_line was moved to gdb.exp in a slightly stricter form,
The gdb.ada/info_exc.exp:info exceptions test has been failing.
This is because it now expects a new-line sequence at the end of
each argument given to multi_line, including ".*". But the intent
when writing the test was to signify "could-be-nothing-at-all".
As a result, the test fails on x86_64-linux with a runtime built as
recommended, because of that
extra new-line sequence.

gdb/testsuite/ChangeLog:

        * gdb.ada/info_exc.exp: Adjust "info exceptions" expected output.
2015-07-20 15:18:24 -07:00
Jerome Guitton
931e5bc3e1 Non bit-packed packed arrays as variable-length fields
In the case of non bit-packed arrays, GNAT does not generate its
traditional XP encoding; it is not needed. However, it still generates
the so-called "implementation type" with a P suffix. This
implementation type shall be skipped when looking for other
descriptive types such as XA encodings for variable-length
fields.

Note also that there may be an intermediate typedef between the
implementation type and its XA description. It shall be skipped
as well.

gdb/ChangeLog:

        Jerome Guitton  <guitton@adacore.com>
	* ada-lang.c (find_parallel_type_by_descriptive_type):
	Go through typedefs during lookup.
	(to_fixed_array_type): Add support for non-bit packed arrays
	as variable-length fields.

gdb/testsuite/ChangeLog:

        * gdb.ada/byte_packed_arr: New testcase.
2015-05-15 14:00:57 -07:00
Joel Brobecker
9cd4d857bb [Ada] problem printing negative integer values in packed arrays.
Consider the following declarations:

   type Signed_Small is new Integer range - (2 ** 5) .. (2 ** 5 - 1);
   type Signed_Simple_Array is array (1 .. 4) of Signed_Small;
   pragma Pack (Signed_Simple_Array);
   SSA : Signed_Simple_Array := (-1, 2, -3, 4);

GDB currently print its value incorrectly for the elements that
are negative:

    (gdb) print ssa
    $1 = (65535, 2, 1048573, 4)
    (gdb) print ssa(1)
    $2 = 65535
    (gdb) print ssa(2)
    $3 = 2
    (gdb) print ssa(3)
    $4 = 1048573
    (gdb) print ssa(4)
    $5 = 4

What happens is that the sign-extension is not working because
we're trying to do left shift with a negative count. In
ada_value_primitive_packed_val, we have a loop which populates
the extra bits of the target (unpacked) value, after extraction
of the data from the original (packed) value:

        while (ntarg > 0)
          {
            accum |= sign << accumSize;
            unpacked[targ] = accum & ~(~0L << HOST_CHAR_BIT);
!!! ->      accumSize -= HOST_CHAR_BIT;
            accum >>= HOST_CHAR_BIT;
            ntarg -= 1;
            targ += delta;
          }

At each iteration, accumSize gets decremented by HOST_CHAR_BIT,
which can easily cause it to become negative, particularly on
little endian targets, where accumSize is at most HOST_CHAR_BIT - 1.
This causes us to perform a left-shift operation with a negative
accumSize at the next loop iteration, which is undefined, and
acutally does not produce the effect we wanted (value left untouched)
when the code is compiled with GCC.

This patch fixes the issue by simply setting accumSize to zero
if negative.

gdb/ChangeLog:

        * ada-lang.c (ada_value_primitive_packed_val): Make sure
        accumSize is never negative.

gdb/testsuite/ChangeLog:

        * gdb.ada/pckd_neg: New testcase.
2015-05-15 07:37:15 -07:00
Joel Brobecker
0fa7fe506c out of line functions nested inside inline functions.
This patch improves the handling of out-of-line functions nested
inside functions that have been inlined.

Consider for instance a situation where function Foo_O224_021
has a function Child1 declared in it, which itself has a function
Child2 nested inside Child1. After compiling the program with
optimization on, Child1 gets inlined, but not Child2.

After inserting a breakpoint on Child2, and running the program
until reaching that breakpoint, we get the following backtrace:

    % gdb foo_o224_021
    (gdb) break foo_o224_021.child1.child2
    (gdb) run
    [...]
    Breakpoint 1, foo_o224_021 () at foo_o224_021.adb:28
    28          Child1;
    (gdb) bt
    #0  0x0000000000402400 in foo_o224_021 () at foo_o224_021.adb:28
    #1  0x00000000004027a4 in foo_o224_021.child1 () at foo_o224_021.adb:23
    #2  0x00000000004027a4 in foo_o224_021 () at foo_o224_021.adb:28

GDB reports the wrong function name for frame #0. We also get the same
kind of error in the "Breakpoint 1, foo_o224_021 () [...]" message.
In both cases, the function name should be foo_o224_021.child1.child2,
and the parameters should be "s=...".

What happens is that the inlined frame handling does not handle well
the case where an inlined function is calling an out-of-line function
which was declared inside the inlined function's scope.

In particular, looking first at the inlined-frame sniffer when applying
to frame #0:

        /* Calculate DEPTH, the number of inlined functions at this
           location.  */
        depth = 0;
        cur_block = frame_block;
        while (BLOCK_SUPERBLOCK (cur_block))
          {
            if (block_inlined_p (cur_block))
              depth++;
            cur_block = BLOCK_SUPERBLOCK (cur_block);
          }

What happens is that cur_block starts as the block associated
to child2, which is not inlined. We shoud be stopping here, but
instead, we keep walking the superblock chain, which takes us
all the way to Foo_O224_021's block, via Child2's block. And
since Child1 was inlined, we end up with a depth count of 1,
wrongly making GDB think that frame #0 is an inlined frame.

Same kind of issue inside skip_inline_frames.

The fix is to stop checking for inlined frames as soon as we see
a block corresponding to a function which is not inlined.  This is
the behavior we now obtain:

    (gdb) run
    [...]
    Breakpoint 1, foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:9
    9               function Child2 (S : String) return Boolean is
    (gdb) bt
    #0  0x0000000000402400 in foo_o224_021.child1.child2 (s=...)
        at foo_o224_021.adb:9
    #1  0x00000000004027a4 in foo_o224_021.child1 () at foo_o224_021.adb:23
    #2  0x00000000004027a4 in foo_o224_021 () at foo_o224_021.adb:28

gdb/ChangeLog:

        * inline-frame.c (inline_frame_sniffer, skip_inline_frames):
        Stop counting inlined frames as soon as an out-of-line function
        is found.

gdb/testsuite/ChangeLog:

        * gdb.ada/out_of_line_in_inlined.exp: Add run and "bt" tests.
2015-05-05 11:08:14 -07:00
Pierre-Marie de Rodat
3ea89b92fb DWARF: cannot break on out-of-line function nested inside inlined function.
Consider the following code, which defines a function, Child2,
which is itself nested inside Child1:

    procedure Foo_O224_021 is
        O1 : constant Object_Type := Get_Str ("Foo");
        procedure Child1 is
            O2 : constant Object_Type := Get_Str ("Foo");
            function Child2 (S : String) return Boolean is -- STOP
            begin
                for C of S loop
                    Do_Nothing (C);
                    if C = 'o' then
                        return True;
                    end if;
                end loop;
                return False;
            end Child2;
            R : Boolean;
        begin
            R := Child2 ("Foo");
            R := Child2 ("Bar");
            R := Child2 ("Foobar");
        end Child1;
    begin
        Child1;
    end Foo_O224_021;

On x86_64-linux, when compiled at -O2, GDB is unable to insert
a breakpoint on Child2:

    % gnatmake -g -O2 foo_o224_021
    % gdb foo_o224_021
    (gdb) b child2
    Function "child2" not defined.
    (gdb) b foo_o224_021.child1.child2
    Function "foo_o224_021.child1.child2" not defined.

The problem is caused by the fact that GDB did not create a symbol
for Child2, and this, in turn, is caused by the fact that the compiler
decided to inline Child1, but not Child2. The DWARF debugging info
first provides an abstract instance tree for Child1...

 <3><1b7b>: Abbrev Number: 29 (DW_TAG_subprogram)
    <1b7c>   DW_AT_name        : (indirect string, offset: 0x23f8): foo_o224_021__child1
    <1b82>   DW_AT_inline      : 1      (inlined)
    <1b83>   DW_AT_sibling     : <0x1c01>

... where that subprogram is given the DW_AT_inline attribute.
Inside that function there is a lexical block which has no PC
range (corresponding to the fact that this is the abstract tree):

 <4><1b87>: Abbrev Number: 30 (DW_TAG_lexical_block)

... inside which our subprogram Child2 is described:

 <5><1b92>: Abbrev Number: 32 (DW_TAG_subprogram)
    <1b93>   DW_AT_name        : (indirect string, offset: 0x2452): foo_o224_021__child1__child2
    <1b99>   DW_AT_type        : <0x1ab1>
    <1b9d>   DW_AT_low_pc      : 0x402300
    <1ba5>   DW_AT_high_pc     : 0x57
    [...]

Then, later on, we get the concrete instance tree, starting at:

 <3><1c5e>: Abbrev Number: 41 (DW_TAG_inlined_subroutine)
    <1c5f>   DW_AT_abstract_origin: <0x1b7b>
    <1c63>   DW_AT_entry_pc    : 0x4025fd
    <1c6b>   DW_AT_ranges      : 0x150

... which refers to Child1. One of that inlined subroutine children
is the concrete instance of the empty lexical block we saw above
(in the abstract instance tree), which gives the actual address
range for this inlined instance:

 <5><1c7a>: Abbrev Number: 43 (DW_TAG_lexical_block)
    <1c7b>   DW_AT_abstract_origin: <0x1b87>
    <1c7f>   DW_AT_ranges      : 0x180

This is the DIE which provides the context inside which we can
record Child2. But unfortunately, GDB does not take the abstract
origin into account when handling lexical blocks, causing it
to miss the fact that this block contains some symbols described
in the abstract instance tree. This is the first half of this patch:
modifying GDB to follow DW_AT_abstract_origin attributes for
lexical blocks.

But this not enough to fix the issue, as we're still unable to
break on Child2 with just that change. The second issue can be
traced to the way inherit_abstract_dies determines the list of
DIEs to inherit from. For that, it iterates over all the DIEs in
the concrete instance tree, and finds the list of DIEs from the
abstract instance tree that are not referenced from the concrete
instance tree. As it happens, there is one type of DIE in the
concrete instance tree which does reference Child2's DIE, but
in fact does otherwise define a concrete instance of the reference
DIE; that's (where <0x1b92> is Child2's DIE):

 <6><1d3c>: Abbrev Number: 35 (DW_TAG_GNU_call_site)
    <1d3d>   DW_AT_low_pc      : 0x4026a4
    <1d45>   DW_AT_abstract_origin: <0x1b92>

So, the second part of the patch is to modify inherit_abstract_dies
to ignore DW_TAG_GNU_call_site DIEs when iterating over the concrete
instance tree.

This patch also includes a testcase which can be used to reproduce
the issue. Unfortunately, for it to actually pass, a smal patch in
GCC is also necessary to make sure that GCC provides lexical blocks'
DW_AT_abstract_origin attributes from the concrete tree back to
the abstract tree. We hope to be able to submit and integrate that
patch in the GCC tree soon. Meanwhile, a setup_xfail has been added.

gdb/ChangeLog:

	2014-05-05  Pierre-Marie de Rodat  <derodat@adacore.com>
	* dwarf2read.c (inherit_abstract_dies): Skip
	DW_TAG_GNU_call_site dies while inheriting children of an
	abstract DIE into a scope.
	(read_lexical_block_scope): Inherit abstract DIE's for
	lexical scopes.

gdb/testsuite/ChangeLog:

        * gdb.ada/out_of_line_in_inlined: New testcase.
2015-05-05 11:06:09 -07:00
Joel Brobecker
87b8eff03f testsuite/gdb.ada/var_rec_arr: New testcase.
gdb/testsuite/ChangeLog:

        * gdb.ada/var_rec_arr: New testcase.
2015-05-05 10:48:21 -07:00
Joel Brobecker
460efde16c [Ada] Preserve typedef layer when getting struct element
Consider the following declarations:

   type Int_Access is access Integer;
   type Record_Type is record
      IA : Int_Access;
   end record;

   R : Record_Type;

Printing the type name of "R.IA" yields:

    (gdb) whatis r.ia
    type = access integer

It should be:

    (gdb) whatis r.ia
    type = bar.int_access

Looking at the debugging info, field "r.ia" is defined as
a typedef which has the name of the field type:

        .uleb128 0x3    # (DIE (0x4e) DW_TAG_typedef)
        .long   .LASF4  # DW_AT_name: "bar__int_access"
        .long   0x8b    # DW_AT_type

... with the typedef's target type being an anonymous pointer
type:

        .uleb128 0x7    # (DIE (0x8b) DW_TAG_pointer_type)
        .byte   0x8     # DW_AT_byte_size
        .long   0x91    # DW_AT_type

What happens here is that a couple of function in ada-lang.c
always start by stripping all typedef layers when handling
struct fields, with the effect of making us lose the type name
in this case.

We did not understand this at the time the code was written,
but typedefs should be stripped only when we know we do not
need them. So this patch, adjust the code to avoid the stripping
while handling the fields, and adds it back in the lone place
which handles the result of processing and didn't know how to
handle typedefs struct fields yet.

gdb/ChangeLog:

        * ada-lang.c (ada_is_tagged_type): Add call to ada_check_typedef.
        (ada_lookup_struct_elt_type): Remove calls to ada_check_typedef.
        (template_to_static_fixed_type): Call ada_check_typedef only
        when necessary.

gdb/testsuite/ChangeLog:

        * gdb.ada/rec_comp: New testcase.
2015-04-27 11:04:47 +02:00
Pierre-Marie de Rodat
961f416025 Do not consider reference types as dynamic
Even when referenced types are dynamic, the corresponding referencing
type should not be considered as dynamic: it's only a pointer.  This
prevents reference type for values not in memory to be resolved.

gdb/ChangeLog:

	* gdbtypes.c (is_dynamic_type_internal): Remove special handling
	of TYPE_CODE_REF types so that they are not considered as
	dynamic depending on the referenced type.
	(resolve_dynamic_type_internal): Likewise.

gdb/testsuite/ChangeLog:

	* gdb.ada/funcall_ref.exp: New file.
	* gdb.ada/funcall_ref/foo.adb: New file.
2015-04-03 15:23:49 +02:00
Pierre-Marie de Rodat
3c724c8ca9 Share the "multi_line" helper among all testcases
gdb/testsuite/ChangeLog:

	* gdb.ada/complete.exp: Remove "multi_line".
	* gdb.ada/info_exc.exp: Remove "multi_line".
	* gdb.ada/packed_tagged.exp: Remove "multi_line".
	* gdb.ada/ptype_field.exp: Remove "multi_line".
	* gdb.ada/sym_print_name.exp: Remove "multi_line".
	* gdb.ada/tagged.exp: Remove "multi_line".
	* gdb.btrace/buffer-size.exp: Replace [join [list ...]] with
	[multi_line ...]
	* gdb.btrace/delta.exp: Likewise.
	* gdb.btrace/exception.exp: Likewise.
	* gdb.btrace/function_call_history.exp: Likewise.
	* gdb.btrace/instruction_history.exp: Likewise.
	* gdb.btrace/nohist.exp: Likewise.
	* gdb.btrace/record_goto.exp: Likewise.
	* gdb.btrace/segv.exp: Likewise.
	* gdb.btrace/stepi.exp: Likewise.
	* gdb.btrace/tailcall.exp: Likewise.
	* gdb.btrace/unknown_functions.exp: Likewise.
	* gdb.dwarf2/dw2-undefined-ret-addr.exp: Likewise.
	* lib/gdb.exp: Add the "multi_line" helper.
2015-04-01 15:06:39 +02:00
Doug Evans
85c3a371b3 testcase for PR symtab/17855
gdb/testsuite/ChangeLog:

	PR symtab/17855
	* gdb.ada/exec_changed.exp: Add second test where symbol lookup cache
	is read after symbols have been re-read.
	* gdb.ada/exec_changed/first.adb (First): New procedure Break_Me.
	* gdb.ada/exec_changed/second.adb (Second): Ditto.
2015-02-22 09:11:55 -08:00
Doug Evans
5dd31d7995 gdb.ada/dyn_arrayidx.exp: Add additional_flags=-gnat12.
gdb/testsuite/ChangeLog:

	* gdb.ada/dyn_arrayidx.exp: Add additional_flags=-gnat12.
2015-01-31 14:26:54 -08:00
Joel Brobecker
df25ebbd09 gdb/DWARF: Support for arrays whose bound is a discriminant.
Consider the following declarations:

   type Array_Type is array (Integer range <>) of Integer;
   type Record_Type (N : Integer) is record
      A : Array_Type (1 .. N);
   end record;
   R : Record_Type := Get (10);

It defines what Ada programers call a "discriminated record", where
"N" is a component of that record called a "discriminant", and where
"A" is a component defined as an array type whose upper bound is
equal to the value of the discriminant.

So far, we rely on a number of fairly complex GNAT-specific encodings
to handle this situation. This patch is to enhance GDB to be able to
print this record in the case where the compiler has been modified
to replace those encodings by pure DWARF constructs.

In particular, the debugging information generated for the record above
looks like the following. "R" is a record..

        .uleb128 0x10   # (DIE (0x13e) DW_TAG_structure_type)
        .long   .LASF17 # DW_AT_name: "foo__record_type"

... whose is is of course dynamic (not our concern here)...

        .uleb128 0xd    # DW_AT_byte_size
        .byte   0x97    # DW_OP_push_object_address
        .byte   0x94    # DW_OP_deref_size
        .byte   0x4
        .byte   0x99    # DW_OP_call4
        .long   0x19b
        .byte   0x23    # DW_OP_plus_uconst
        .uleb128 0x7
        .byte   0x9     # DW_OP_const1s
        .byte   0xfc
        .byte   0x1a    # DW_OP_and
        .byte   0x1     # DW_AT_decl_file (foo.adb)
        .byte   0x6     # DW_AT_decl_line

... and then has 2 members, fist "n" (our discriminant);

        .uleb128 0x11   # (DIE (0x153) DW_TAG_member)
        .ascii "n\0"    # DW_AT_name
        .byte   0x1     # DW_AT_decl_file (foo.adb)
        .byte   0x6     # DW_AT_decl_line
        .long   0x194   # DW_AT_type
        .byte   0       # DW_AT_data_member_location

... and "A"...

        .uleb128 0x11   # (DIE (0x181) DW_TAG_member)
        .ascii "a\0"    # DW_AT_name
        .long   0x15d   # DW_AT_type
        .byte   0x4     # DW_AT_data_member_location

... which is an array ...

        .uleb128 0x12   # (DIE (0x15d) DW_TAG_array_type)
        .long   .LASF18 # DW_AT_name: "foo__record_type__T4b"
        .long   0x194   # DW_AT_type

... whose lower bound is implicitly 1, and the upper bound
a reference to DIE 0x153 = "N":

        .uleb128 0x13   # (DIE (0x16a) DW_TAG_subrange_type)
        .long   0x174   # DW_AT_type
        .long   0x153   # DW_AT_upper_bound

This patch enhanced GDB to understand references to other DIEs
where the DIE's address is at an offset of its enclosing type.
The difficulty was that the address used to resolve the array's
type (R's address + 4 bytes) is different from the address used
as the base to compute N's address (an offset to R's address).

We're solving this issue by using a stack of addresses rather
than a single address when trying to resolve a type. Each address
in the stack corresponds to each containing level. For instance,
if resolving the field of a struct, the stack should contain
the address of the field at the top, and then the address of
the struct.  That way, if the field makes a reference to an object
of the struct, we can retrieve the address of that struct, and
properly resolve the dynamic property references that struct.

gdb/ChangeLog:

        * gdbtypes.h (struct dynamic_prop): New PROP_ADDR_OFFSET enum
        kind.
        * gdbtypes.c (resolve_dynamic_type_internal): Replace "addr"
        parameter by "addr_stack" parameter.
        (resolve_dynamic_range): Replace "addr" parameter by
        "stack_addr" parameter.  Update function documentation.
        Update code accordingly.
        (resolve_dynamic_array, resolve_dynamic_union)
        (resolve_dynamic_struct, resolve_dynamic_type_internal): Likewise.
        (resolve_dynamic_type): Update code, following the changes made
        to resolve_dynamic_type_internal's interface.
        * dwarf2loc.h (struct property_addr_info): New.
        (dwarf2_evaluate_property): Replace "address" parameter
        by "addr_stack" parameter.  Adjust function documentation.
        (struct dwarf2_offset_baton): New.
        (struct dwarf2_property_baton): Update documentation of
        field "referenced_type" to be more general. New field
        "offset_info" in union data field.
        * dwarf2loc.c (dwarf2_evaluate_property): Replace "address"
        parameter by "addr_stack" parameter.  Adjust code accordingly.
        Add support for PROP_ADDR_OFFSET properties.
        * dwarf2read.c (attr_to_dynamic_prop): Add support for
        DW_AT_data_member_location attributes as well.  Use case
        statements instead of if/else condition.

gdb/testsuite/ChangeLog:

        * gdb.ada/disc_arr_bound: New testcase.

Tested on x86_64-linux, no regression.
2015-01-29 12:08:47 +04:00
Joel Brobecker
4a0ca9ec1e [Ada/varobj] number of children of null pointer to dynamic array.
This is preparation work to avoid a regression in the Ada/varobj.
An upcoming patch is going to add support for types in DWARF
which have dynamic properties whose value is a reference to another
DIE.

Consider for instance the following declaration:

   type Variant_Type (N : Int := 0) is record
      F : String(1 .. N) := (others => 'x');
   end record;
   type Variant_Type_Access is access all Variant_Type;
   VTA : Variant_Type_Access := null;

This declares a variable "VTA" which is an access (=pointer)
to a variant record Variant_Type. This record contains two
components, the first being "N" (the discriminant), and the
second being "F", an array whose lower bound is 1, and whose
upper bound depends on the value of "N" (the discriminant).

Of interest to us, here, is that second component ("F"), and
in particular its bounds. The debugging info, and in particular
the info for the array looks like the following...

        .uleb128 0x9    # (DIE (0x91) DW_TAG_array_type)
        .long   .LASF16 # DW_AT_name: "bar__variant_type__T2b"
        .long   0xac    # DW_AT_GNAT_descriptive_type
        .long   0x2cb   # DW_AT_type
        .long   0xac    # DW_AT_sibling
        .uleb128 0xa    # (DIE (0xa2) DW_TAG_subrange_type)
        .long   0xc4    # DW_AT_type
        .long   0x87    # DW_AT_upper_bound
        .byte   0       # end of children of DIE 0x91

... where the upper bound of the array's subrange type is a reference
to "n"'s DIE (0x87):

        .uleb128 0x8    # (DIE (0x87) DW_TAG_member)
        .ascii "n\0"    # DW_AT_name
        [...]

Once the patch to handle this dynamic property gets applied,
this is what happens when creating a varobj for variable "VTA"
(whose value is null), and then trying to list its children:

    (gdb)
    -var-create vta * vta
    ^done,name="vta",numchild="2",value="0x0",
          type="bar.variant_type_access",has_more="0"
    (gdb)
    -var-list-children 1 vta
    ^done,numchild="2",
          children=[child={name="vta.n",[...]},
                    child={name="vta.f",exp="f",
                           numchild="43877616",  <<<<-----
                           value="[43877616]",   <<<<-----
                           type="array (1 .. n) of character"}],
          has_more="0"

It has an odd number of children.

In this case, we cannot really determine the number of children,
since that number depends on the value of a field in a record
for which we do not have a value. Up to now, the value we've been
displaying is zero - meaning we have an empty array.

What happens in this case, is that, because the VTA is a null pointer,
we're not able to resolve the pointer's target type, and therefore
end up asking ada_varobj_get_array_number_of_children to return
the number of elements in that array; for that, it relies blindly
on get_array_bounds, which assumes the type is no longer dynamic,
and therefore the reads the bound without seeing that it's value
is actually a reference rather than a resolved constant.

This patch prevents the issue by explicitly handling the case of
dynamic arrays, and returning zero child in that case.

gdb/ChangeLog:

        * ada-varobj.c (ada_varobj_get_array_number_of_children):
        Return zero if PARENT_VALUE is NULL and parent_type's
        range type is dynamic.

gdb/testsuite/ChangeLog:

        * gdb.ada/mi_var_array: New testcase.

Tested on x86_64-linux.
2015-01-29 12:07:25 +04:00
Joel Brobecker
bafffb51c4 [Ada] 'first/'last/'length of array whose bound is a discriminant
Consider the following code:

   type Table is array (Positive range <>) of Integer;
   type Object (N : Integer) is record
       Data : Table (1 .. N);
   end record;
   My_Object : Object := (N => 3, Data => (3, 5, 8));

Trying to print the range and length of the My_Object.Data array yields:

    (gdb) print my_object.data'first
    $1 = 1
    (gdb) print my_object.data'last
    $2 = 0
    (gdb) print my_object.data'length
    $3 = 0

The first one is correct, and that is thanks to the fact that
the lower bound is statically known.  However, for the upper
bound, and consequently the array's length, the values are incorrect.
It should be:

    (gdb) print my_object.data'last
    $2 = 3
    (gdb) print my_object.data'length
    $3 = 3

What happens here is that ada_array_bound_from_type sees that
our array has a parallel "___XA" type, and therefore tries to
use it.  In particular, it described our array's index type as:
[...]___XDLU_1__n, which means lower bound = 1, and upper bound
is value of "n". Unfortunately, ada_array_bound_from_type does
not have access to the discriminant, and is therefore unable to
compute the bound correctly.

Fortunately, at this stage, the bound has already been computed
a while ago, and therefore doesn't need to be re-computed here.
This patch fixes the issue by ignoring that ___XA type if the array
is marked as already fixed.

This also fixes the same issue with packed arrays.

gdb/ChangeLog:

        * ada-lang.c (ada_array_bound_from_type): Ignore array's parallel
        ___XA type if the array has already been fixed.

gdb/testsuite/ChangeLog:

        * gdb.ada/var_arr_attrs: New testcase.
2015-01-15 12:53:33 +04:00
Joel Brobecker
32d0add0a6 Update year range in copyright notice of all files owned by the GDB project.
gdb/ChangeLog:

        Update year range in copyright notice of all files.
2015-01-01 13:32:14 +04:00
Joel Brobecker
c1b5a1a6e7 Internal error trying to print uninitialized string.
Trying to print the value of a string whose size is not known at
compile-time before it gets assigned a value can lead to the following
internal error:

    (gdb) p my_str
    $1 =
    /[...]/utils.c:1089: internal-error: virtual memory exhausted.

What happens is that my_str is described as a reference to an array
type whose bounds are dynamic. During the read of that variable's
value (in default_read_var_value), we end up resolving dynamic types
which, for reference types, makes us also resolve the target of that
reference type. This means we resolve our variable to a reference
to an array whose bounds are undefined, and unfortunately very far
appart.

So, when we pass that value to ada-valprint, and in particular to
da_val_print_ref, we eventually try to allocate too large of a buffer
corresponding to the (bogus) size of our array, hence the internal
error.

This patch fixes the problem by adding a size_check before trying
to print the dereferenced value. To perform this check, a function
that was previously specific to ada-lang.c (check_size) gets
exported, and renamed to something less prone to name collisions
(ada_ensure_varsize_limit).

gdb/ChangeLog:

        * ada-lang.h (ada_ensure_varsize_limit): Declare.
        * ada-lang.c (check_size): Remove advance declaration.
        (ada_ensure_varsize_limit): Renames check_size.
        Replace calls to check_size by calls to ada_ensure_varsize_limit
        throughout.
        * ada-valprint.c (ada_val_print_ref): Add call to
        ada_ensure_varsize_limit.  Add comment explaining why.

gdb/testsuite/ChangeLog:

        * gdb.ada/str_uninit: New testcase.
2014-12-13 11:00:24 -05:00
Simon Marchi
d7fc3181f7 Fix prints in tests for Python 3
Python 3's print requires to use parentheses, so this patch adds them
where they were missing.

gdb/testsuite/ChangeLog:

	* gdb.ada/py_range.exp: Add parentheses to calls to print.
	* gdb.dwarf2/symtab-producer.exp: Same.
	* gdb.gdb/python-interrupts.exp: Same.
	* gdb.gdb/python-selftest.exp: Same.
	* gdb.python/py-linetable.exp: Same.
	* gdb.python/py-type.exp: Same.
	* gdb.python/py-value-cc.exp: Same.
	* gdb.python/py-value.exp: Same.
2014-11-28 11:36:52 -05:00
Joel Brobecker
45e44d277a Handling of empty Ada ranges with a negative upper bound.
Consider the following variable declaration:

    type Array_Type is array (Integer range <>) of Integer;
    Var: Array_Type (0 .. -1);

"ptype var" prints the wrong upper bound for that array:

    (gdb) ptype var
    type = array (0 .. 4294967295) of integer

The debugging info for the type of variable "Var" is as follow:

  <2><cf>: Abbrev Number: 13 (DW_TAG_structure_type)
     <d0>   DW_AT_name        : foo__var___PAD
  <3><db>: Abbrev Number: 14 (DW_TAG_member)
     <dc>   DW_AT_name        : F
     <e0>   DW_AT_type        : <0xa5>

This is just an artifact from code generation, which is just
a wrapper that we should ignore. The real type is the type of
field "F" in that PAD type, which is described as:

  <2><a5>: Abbrev Number: 10 (DW_TAG_array_type)
     <a6>   DW_AT_name        : foo__TvarS
  <3><b6>: Abbrev Number: 11 (DW_TAG_subrange_type)
     <b7>   DW_AT_type        : <0xc1>
     <bb>   DW_AT_lower_bound : 0
     <bc>   DW_AT_upper_bound : 0xffffffff

Trouble occurs because DW_AT_upper_bound is encoded using
a DW_FORM_data4, which is ambiguous regarding signedness.
In that case, dwarf2read.c::dwarf2_get_attr_constant_value
reads the value as unsigned, which is not what we want
in this case.

As it happens, we already have code dealing with this situation
in dwarf2read.c::read_subrange_type which checks whether
the subrange's type is signed or not, and if it is, fixes
the bound's value by sign-extending it:

  if (high.kind == PROP_CONST
      && !TYPE_UNSIGNED (base_type) && (high.data.const_val & negative_mask))
    high.data.const_val |= negative_mask;

Unfortunately, what happens in our case is that the base type
of the array's subrange type is marked as being unsigned, and
so we never get to apply the sign extension. Following the DWARF
trail, the range's base type is described as another subrange type...

  <2><c1>: Abbrev Number: 12 (DW_TAG_subrange_type)
     <c7>   DW_AT_name        : foo__TTvarSP1___XDLU_0__1m
     <cb>   DW_AT_type        : <0x2d>

... whose base type is, (finally), a basic type (signed):

  <1><2d>: Abbrev Number: 2 (DW_TAG_base_type)
     <2e>   DW_AT_byte_size   : 4
     <2f>   DW_AT_encoding    : 5        (signed)
     <30>   DW_AT_name        : integer

The reason why GDB thinks that foo__TTvarSP1___XDLU_0__1m
(the base type of the array's range type) is an unsigned type
is found in gdbtypes.c::create_range_type.  We consider that
a range type is unsigned iff its lower bound is >= 0:

  if (low_bound->kind == PROP_CONST && low_bound->data.const_val >= 0)
    TYPE_UNSIGNED (result_type) = 1;

That is normally sufficient, as one would expect the upper bound to
always be greater or equal to the lower bound. But Ada actually
allows the declaration of empty range types where the upper bound
is less than the lower bound. In this case, the upper bound is
negative, so we should not be marking the type as unsigned.

This patch fixes the issue by simply checking the upper bound as well
as the lower bound, and clears the range type's unsigned flag when
it is found to be constant and negative.

gdb/ChangeLog:

        * gdbtypes.c (create_range_type): Unset RESULT_TYPE's
        flag_unsigned if HIGH_BOUND is constant and negative.

gdb/testsuite/ChangeLog:

        * gdb.ada/n_arr_bound: New testcase.

Tested on x86_64-linux.
2014-11-21 07:07:07 +04:00
Joel Brobecker
8908fca577 [Ada] Ignore __XA types when redundant.
Consider the following code which declares a variable A2 which
is an array of arrays of integers.

   type Array2_First is array (24 .. 26) of Integer;
   type Array2_Second is array (1 .. 2) of Array2_First;
   A1 : Array1_Second := ((10, 11, 12), (13, 14, 15));

Trying to print the type of that variable currently yields:

    (gdb) ptype A2
    type = array (1 .. 2, 24 .. 26) of integer

This is not correct, as this is the description of a two-dimension
array, which is different from an array of arrays. The expected
output is:

    (gdb) ptype a2
    type = array (1 .. 2) of foo_n926_029.array2_first

GDB's struct type currently handles multi-dimension arrays the same
way arrays of arrays, where each dimension is stored as a sub-array.
The ada-valprint module considers that consecutive array layers
are in fact multi-dimension arrays. For array of arrays, a typedef
layer is introduced between the two arrays, creating a break between
each array type.

In our situation, A2 is a described as a typedef of an array type...

        .uleb128 0x8    # (DIE (0x125) DW_TAG_variable)
        .ascii "a2\0"   # DW_AT_name
        .long   0xfc    # DW_AT_type

        .uleb128 0x4    # (DIE (0xfc) DW_TAG_typedef)
        .long   .LASF5  # DW_AT_name: "foo__array2_second"
        .long   0x107   # DW_AT_type

        .uleb128 0x5    # (DIE (0x107) DW_TAG_array_type)
        .long   .LASF5  # DW_AT_name: "foo__array2_second"
        .long   0xb4    # DW_AT_type
        .uleb128 0x6    # (DIE (0x114) DW_TAG_subrange_type)
        .long   0x11b   # DW_AT_type
        .byte   0x2     # DW_AT_upper_bound
        .byte   0       # end of children of DIE 0x107

... whose element type is, as expected, a typedef to the sub-array
type:

        .uleb128 0x4    # (DIE (0xb4) DW_TAG_typedef)
        .long   .LASF4  # DW_AT_name: "foo__array2_first"
        .long   0xbf    # DW_AT_type

        .uleb128 0x9    # (DIE (0xbf) DW_TAG_array_type)
        .long   .LASF4  # DW_AT_name: "foo__array2_first"
        .long   0xd8    # DW_AT_GNAT_descriptive_type
        .long   0x1c5   # DW_AT_type
        .uleb128 0xa    # (DIE (0xd0) DW_TAG_subrange_type)
        .long   0xf0    # DW_AT_type
        .byte   0x18    # DW_AT_lower_bound
        .byte   0x1a    # DW_AT_upper_bound
        .byte   0       # end of children of DIE 0xbf

The reason why things fails is that, during expression evaluation,
GDB tries to "fix" A1's type. Because the sub-array has a parallel
(descriptive) type (DIE 0xd8), GDB thinks that our array's index
type must be dynamic and therefore needs to be fixed. This in turn
causes the sub-array to be "fixed", which itself results in the
typedef layer to be stripped.

However, looking closer at the parallel type, we see...

        .uleb128 0xb    # (DIE (0xd8) DW_TAG_structure_type)
        .long   .LASF8  # DW_AT_name: "foo__array2_first___XA"
        [...]
        .uleb128 0xc    # (DIE (0xe4) DW_TAG_member)
        .long   .LASF10 # DW_AT_name: "foo__Tarray2_firstD1___XDLU_24__26"

... that all it tells us is that the array bounds are 24 and 26,
which is already correctly provided by the array's DW_TAG_subrange_type
bounds, meaning that this parallel type is just redundant.

Parallel types in general are slowly being removed in favor of
standard DWARF constructs. But in the meantime, this patch kills
two birds with one stone:

  1. It recognizes this situation where the XA type is useless,
     and saves an unnecessary range-type fixing;

  2. It fixes the issue at hand because ignoring the XA type results
     in no type fixing being required, which allows the typedef layer
     to be preserved.

gdb/ChangeLog:

        * ada-lang.c (ada_is_redundant_range_encoding): New function.
        (ada_is_redundant_index_type_desc): New function.
        (to_fixed_array_type): Ignore parallel XA type if redundant.

gdb/testsuite/ChangeLog:

        * gdb.ada/arr_arr: New testcase.

Tested on x86_64-linux.
2014-11-19 12:48:07 +04:00
Joel Brobecker
4a46959e7b varsize-limit error printing element of packed array...
... when that packed array is part of a discriminated record and
one of the bounds is a discriminant.

Consider the following code:

   type FUNNY_CHAR_T is (NUL, ' ', '"', '#', [etc]);
   type FUNNY_STR_T is array (POSITIVE range <>) of FUNNY_CHAR_T;
   pragma PACK (FUNNY_STR_T);
   type FUNNY_STRING_T (SIZE : NATURAL := 1) is
      record
         STR    : FUNNY_STR_T (1 .. SIZE) := (others => '0');
         LENGTH : NATURAL := 4;
      end record;
   TEST: FUNNY_STRING_T(100);

GDB is able to print the value of variable "test" and "test.str".
But not "test.str(1)":

    (gdb) p test
    $1 = (size => 100, str => (33 'A', nul <repeats 99 times>), length => 1)
    (gdb) p test.str
    $2 = (33 'A', nul <repeats 99 times>)
    (gdb) p test.str(1)
    object size is larger than varsize-limit

The problem occurs during the phase where we are trying to resolve
the expression subscript operation. On the one hand of the subscript
operator, we have the result of the evaluation of "test.str", which
is our packed array. We have the following code to handle packed
arrays in particular:

      if (ada_is_constrained_packed_array_type
          (desc_base_type (value_type (argvec[0]))))
        argvec[0] = ada_coerce_to_simple_array (argvec[0]);

This eventually leads to a call to constrained_packed_array_type
to return the "simple array".  This function relies on a parallel
___XA type, when available, to determine the bounds.  In our case,
we find type...

    failure__funny_string_t__T4b___XA"

... which has one field describing the bounds of our array as:

    failure__funny_string_t__T3b___XDLU_1__size

The part that interests us is after the ___XD suffix or,
in other words: "LU_1__size". What this means in GNAT encoding
parlance is that the lower bound is 1, and that the upper bound
is the value of "size". "size" is our discriminant in this case.

Normally, we would access the record's discriminant in order to
get the upper bound's value, but we do not have that information,
here. We are in a mode where we are just trying to "fix" the type
without an actual value. This is what the call to to_fixed_range_type
is doing, and because the fix'ing fails, it ends up returning
the ___XDLU type unmodified as our index type.

This shouldn't be a problem, except that the later part of
constrained_packed_array_type then uses that index_type to
determine the array size, via a call to get_discrete_bounds.
The problem is that the upper bound of the ___XDLU type is
dynamic (in the DWARF sense) while get_discrete_bounds implicitly
assumes that the bounds are static, and therefore accesses
them using macros that assume the bounds values are constants:

    case TYPE_CODE_RANGE:
      *lowp = TYPE_LOW_BOUND (type);
      *highp = TYPE_HIGH_BOUND (type);

This therefore returns a bogus value for the upper bound,
leading to an unexpectedly large size for our array, which
later triggers the varsize-limit guard we've seen above.

This patch avoids the problem by adding special handling
of dynamic range types. It also extends the documentation
of the constrained_packed_array_type function to document
what happens in this situation.

gdb/ChangeLog:

        * ada-lang.c (constrained_packed_array_type): Set the length
        of the return array as if both bounds where zero if that
        returned array's index type is dynamic.

gdb/testsuite/ChangeLog:

        * gdb.ada/pkd_arr_elem: New Testcase.

Tested on x86_64-linux.
2014-11-19 12:06:19 +04:00
Andreas Arnez
a59add0c2e GDB testsuite: Fix warnings with -std=gnu11
Since upstream GCC has changed the default C language dialect to
'gnu11', it yields multiple warnings in the GDB testsuite for missing
function return types and implicit function declarations.  This patch
attempts to fix these.

gdb/testsuite/ChangeLog:

	* gdb.ada/cond_lang/foo.c (callme): Add return type.
	* gdb.base/call-sc.c (zed): Likewise.
	* gdb.base/checkpoint.c (main): Likewise.
	* gdb.base/dump.c (main): Likewise.
	* gdb.base/gcore.c (main): Likewise.
	* gdb.base/huge.c (main): Likewise.
	* gdb.base/multi-forks.c (main): Likewise.
	* gdb.base/pr10179-a.c (main): Likewise.
	* gdb.base/savedregs.c (main): Likewise.
	* gdb.base/sigaltstack.c (main): Likewise.
	* gdb.base/siginfo.c (main): Likewise.
	* gdb.base/structs.c (zed): Likewise.
	* gdb.mi/mi-stack.c (callee3, callee2, callee1, main): Likewise.
	* gdb.mi/mi-syn-frame.c (main): Likewise.
	* gdb.mi/until.c (foo, main): Likewise.
	* gdb.base/global-var-nested-by-dso.c (b_main, c_main): Declare.
	* gdb.base/solib-weak.c (foo): Declare.
	* gdb.base/attach-twice.c: Include stdio.h.
	* gdb.base/weaklib1.c: Likewise.
	* gdb.base/weaklib2.c: Likewise.
	* gdb.base/catch-signal-fork.c: Include stdio.h and sys/wait.h.
	* gdb.mi/mi-condbreak-call-thr-state-mt.c: Include stdio.h and
	unistd.h.
	* gdb.base/attach-pie-misread.c: Include stdlib.h.
	* gdb.mi/mi-exit-code.c: Likewise.
	* gdb.base/break-interp-lib.c: Include string.h.
	* gdb.base/coremaker.c: Likewise.
	* gdb.base/testenv.c: Likewise.
	* gdb.python/py-finish-breakpoint.c: Likewise.
	* gdb.base/inferior-died.c: Include sys/wait.h.
	* gdb.base/fileio.c: Include time.h.
	* gdb.base/async-shell.c: Include unistd.h.
	* gdb.base/dprintf-non-stop.c: Likewise.
	* gdb.base/info-os.c: Likewise.
	* gdb.mi/mi-console.c: Likewise.
	* gdb.mi/watch-nonstop.c: Likewise.
	* gdb.python/py-events.c: Likewise.
	* gdb.base/async.c (baz): Move up before its invocation.
	* gdb.base/code_elim2.c (my_global_func): Likewise.
	* gdb.base/skip-solib-lib.c (multiply): Likewise.
	* gdb.base/advance.c (func2): Likewise.
2014-11-13 10:20:44 +01:00
Joel Brobecker
c40cc657bc [Ada] Error adding/subtracting pointer value to/from integral.
When trying to evaluate an expression which adds a pointer and
an integral, the evaluation succeeds if the pointer is on
the left handside of the operator, but not when it is on the right
handside:

    (gdb) p something'address + 0
    $1 = (system.address) 0x613418 <pck.something>
    (gdb) p 0 + something'address
    Argument to arithmetic operation not a number or boolean.

Same issue when doing subtractions:

    (gdb) p something'address - 0
    $2 = (system.address) 0x613418 <pck.something>
    (gdb) p 0 - something'address
    Argument to arithmetic operation not a number or boolean.

This patch enhances the Ada expression evaluator to handle
these two situations.

gdb/ChangeLog:

        * ada-lang.c (ada_evaluate_subexp) <BINOP_ADD>: Add handling
        of the case where the second operand is a pointer.
        <BINOP_SUB>: Likewise.

gdb/testsuite/ChangeLog:

        * gdb.ada/addr_arith: New testcase.

Tested on x86_64-linux.
2014-10-14 14:05:11 -07:00
Joel Brobecker
cac0dc8f4b Add gdb.ada/dyn_arrayidx testcase.
This add a testcases that verifies correct handling of dynamicity
for lower bounds of arrays.

gdb/testsuite/ChangeLog:

        * gdb.ada/dyn_arrayidx: New testcase.
2014-04-28 15:48:11 -04:00
Joel Brobecker
8776cfe971 [varobj] false type-changed status for reference to Ada array
Given the following variable...

   BT : Bounded := New_Bounded (Low => 1, High => 3);

... where type Bounded is defined as a simple unconstrained array:

   type Bounded is array (Integer range <>) of Integer;

Creating a varobj for that variable, and immediately asking for
varobj updates, GDB says that our varobj changed types!

    (gdb)
    -var-create bt * bt
    ^done,name="bt",numchild="3",value="[3]",type="<ref> array (1 .. 3) of integer",has_more="0"
    (gdb)
    -var-update 1 *
    ^done,changelist=[{name="bt",value="[3]",in_scope="true",type_changed="true",new_type="<ref> array (1 .. 3) of integer",new_num_children="3",has_more="0"}]

The expected output for the -var-update command is, in this case:

    (gdb)
    -var-update 1 *
    ^done,changelist=[]

The problem occurs because the ada-varobj module does not handle
references, and while the references gets stripped when the varobj
gets created, it doesn't when computing varobj updates.

More specifically, when creating the varobj, varobj_create creates
a new value which is a reference to a TYPE_CODE_ARRAY. It then calls
install_new_value which calls coerce_ref with the following comment:

    /* We are not interested in the address of references, and given
       that in C++ a reference is not rebindable, it cannot
       meaningfully change.  So, get hold of the real value.  */
    if (value)
      value = coerce_ref (value);

This leaves the varobj's type component still a ref, while
the varobj's value is now our array, without the ref. This explains
why the "value" field in the varobj indicates an array with 3 elements
"[3]" while the "type" field shows a ref to an array. Generally
speaking, most users have said that showing the ref was a useful
piece of information, so this patch is not touching this part.

Next, when the user issues the -var-update request, varobj_update
calls value_of_root to compute the varobj's new value as well as
determine whether the value's type has changed or not. What happens
in a nutshell is that it calls value_of_root_1 (which re-evaluates
the expression and returns the corresponding new value), finds that
the new value is not NULL, and thus asks whether it has mutated:

    else if (varobj_value_has_mutated (var, value, value_type (value)))

This then indirectly delegates the determination to the language-specific
callback, which fails, because it does not handle references.

This patch fixes the issue by adjusting varobj_value_has_mutated to
expect references, and strip them when seen. This allows the various
language-specific implementations to remain unaware of references.

gdb/ChangeLog:

        * varobj.c (varobj_value_has_mutated): If NEW_VALUE is
        a reference, strip the reference layer before calling
        the lang_ops value_has_mutated callback.

gdb/testsuite/ChangeLog:

        * gdb.ada/mi_dyn_arr: New testcase.
2014-03-28 06:22:24 -07:00
Yao Qi
0d4d0e772a Skip tests on completion and readline when readline lib isn't used
The completion feature and other features on readline depend on the
readline library.  However, readline library is not always used, for
example, running testsuite like

  make check RUNTESTFLAGS="--host_board=local-remote-host"

the input stream is not a tty, and GDB doesn't use readline library
as a result.

This patch is to skip tests on completion and readline if
'show editing' is off, which means readline isn't used.  Note that
some tests in gdb.base/completion.exp test command complete, which
isn't related to readline, so these tests aren't affected by readline
library.  This patch also moves these tests up, run them
unconditionally, and run the rest if readline library is used.

gdb/testsuite:

2014-03-26  Yao Qi  <yao@codesourcery.com>

	* lib/gdb.exp (readline_is_used): New proc.
	* gdb.base/completion.exp: Move tests on command complete up.
	Skip the rest of tests if readline is not used.
	* gdb.ada/complete.exp: Skp the test if readline is not
	used.
	* gdb.base/filesym.exp: Likewise.
	* gdb.base/macscp.exp: Likewise.
	* gdb.base/readline-ask.exp: Likewise.
	* gdb.base/readline.exp: Likewise.
	* gdb.python/py-cmd.exp: Likewise.
	* gdb.trace/tfile.exp: Likewise.
2014-03-26 21:11:08 +08:00
Joel Brobecker
f7c77d9323 [testsuite/Ada] New testcase for packed array renaming.
gdb/testsuite/ChangeLog:

        * gdb.ada/pckd_arr_ren: New testcase.
2014-03-17 08:45:55 -07:00
Jerome Guitton
5ec18f2b48 [Ada] Full view of tagged type with ptype
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.
2014-03-10 14:40:35 +01:00
Pedro Alves
12ab52e977 Multiple Ada task-specific breakpoints at the same address.
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.
2014-02-26 14:22:33 +00:00
Joel Brobecker
aa4fb036e9 Wrong type for 'Length result.
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.
2014-02-10 13:15:43 +04:00
Joel Brobecker
fb15121096 Try printing array range using the name of its index type
type Char_Table is array (Character range Character'First .. Character'Last)
     of Natural;

Trying to print the type description of this type currently yields:

   (gdb) ptype char_table
   type = array ('["00"]' .. '["ff"]') of natural

Although technically correct, it seemed more useful to print the array
range as:

   (gdb) ptype char_table
   type = array (character) of natural

This patch implements this suggestion.

gdb/ChangeLog:

        * ada-typeprint (type_is_full_subrange_of_target_type):
        New function.
        (print_range): Add parameter bounds_prefered_p.  If not set,
        try printing range types using the name of their base type.
        (print_range_type): Add parameter bounds_prefered_p.
        Use it in call to print_range.
        (print_array_type, ada_print_type): Update calls to print_range
        and print_range_type.

gdb/testsuite/ChangeLog:

        * gdb.ada/array_char_idx: New testcase.
2014-01-27 08:27:21 +04:00
Joel Brobecker
a2cd8cfed1 Remove path from gdb.ada/pp-rec-component.exp "source" test
gdb/testsuite/ChangeLog:

	* gdb.ada/pp-rec-component.exp: Remove path from "source" test.
2014-01-10 07:57:11 +04:00
Joel Brobecker
f30b8b38d4 varobj/Ada: Missing children for interface-wide tagged types
Consider the following code:

   type Element is abstract tagged null record;
   type GADataType is interface;
   type Data_Type is new Element and GADataType with record
      I : Integer := 42;
   end record;
   Result1 : Data_Type;
   GGG1    : GADataType'Class := GADataType'Class (Result1);

When trying to create a varobj for variable ggg1, GDB currently
returns an object which has no child:

    -var-create ggg1 * ggg1
    ^done,name="ggg1",numchild="0",[...]

This is incorrect, it should return an object which has one child
(field "i"). This is because tagged-type objects are dynamic, and
we need to apply a small transformation in order to get their actual
type. This is already done on the GDB/CLI side in ada-valprint,
and it needs to be done on the ada-varobj side as well.

gdb/ChangeLog:

        * ada-varobj.c (ada_varobj_adjust_for_child_access): Convert
        tagged type objects to their actual type.

gdb/testsuite/ChangeLog:

        * gdb.ada/mi_interface: New testcase.
2014-01-07 08:29:04 +04:00
Joel Brobecker
8e355c5d24 Ada: Fix missing call to pretty-printer for fields of records.
Consider the following types:

   type Time_T is record
      Secs : Integer;
   end record;
   Before : Time_T := (Secs => 1384395743);

In this example, we assume that type Time_T is the number of seconds
since Epoch, and so added a Python pretty-printer, to print this
type in a more human-friendly way. For instance:

    (gdb) print before
    $1 = Thu Nov 14 02:22:23 2013 (1384395743)

However, we've noticed that things stop working when this type is
embedded inside another record, and we try to print that record.
For instance, with the following declarations:

   type Composite is record
      Id : Integer;
      T : Time_T;
   end record;
   Afternoon : Composite := (Id => 1, T => (Secs => 1384395865));

    (gdb) print afternoon
    $2 = (id => 1, t => (secs => 1384395865))

We expected instead:

    (gdb) print afternoon
    $2 = (id => 1, t => Thu Nov 14 02:24:25 2013 (1384395865))

This patch fixes the problem by making sure that we try to print
each field via a call to val_print, rather than calling ada_val_print
directly. We need to go through val_print, as the val_print
handles all language-independent features such as calling the
pretty-printer, knowing that ada_val_print will get called eventually
if actual Ada-specific printing is required (which should be the
most common scenario).

And because val_print takes the language as parameter, we enhanced
the print_field_values and print_variant_part to also take a language.
As a bonus, this allows us to remove a couple of references to
current_language.

gdb/ChangeLog:

        * ada-valprint.c (print_field_values): Add "language" parameter.
        Update calls to print_field_values and print_variant_part.
        Pass new parameter "language" in call to val_print instead
        of "current_language".  Replace call to ada_val_print by call
        to val_print.
        (print_variant_part): Add "language" parameter.
        (ada_val_print_struct_union): Update call to print_field_values.

gdb/testsuite/ChangeLog:

        * gdb.ada/pp-rec-component.exp, gdb.ada/pp-rec-component.py,
        gdb.ada/pp-rec-component/foo.adb, gdb.ada/pp-rec-component/pck.adb,
        gdb.ada/pp-rec-component/pck.ads: New files.
2014-01-07 08:17:40 +04:00
Joel Brobecker
ecd75fc8ee Update Copyright year range in all files maintained by GDB. 2014-01-01 07:54:24 +04:00
Joel Brobecker
8a48ac9579 wrong dimension found in ada-lang.c:ada_array_bound_from_type
This function has the following code:

  elt_type = type;
  for (i = n; i > 1; i--)
    elt_type = TYPE_TARGET_TYPE (type);

For multi-dimension arrays, the code above tries to find the array
type corresponding to the dimension we're trying to inspect.
The problem is that, past the second dimension, the loop does
nothing other than repeat the first iteration. There is a little
thinko where it got the TYPE_TARGET_TYPE of TYPE instead of ELT_TYPE!

To my surprise, I was unable to produce an Ada exemple that demonstrated
the problem.  That's because the examples I created all trigger a parallel
___XA type which we then use in place of the ELT_TYPE in order to
determine the bounds - see the code that immediately follows our
loop above:

    index_type_desc = ada_find_parallel_type (type, "___XA");
    ada_fixup_array_indexes_type (index_type_desc);
    if (index_type_desc != NULL)
    [...]

So, in order to avoid depending on an Ada example where the compiler
can potentially decide one way or the other, I decided to use an
artificial example, written in C. With ...

  int multi[1][2][3];

... forcing the language to Ada, and trying to print the 'last,
we get:

    (gdb) p multi'last(1)
    $1 = 0
    (gdb) p multi'last(2)
    $2 = 1
    (gdb) p multi'last(3)
    $3 = 1   <<<---  This should be 2!

Additionally, I noticed that a couple of check_typedef's were missing.
This patch adds them. And since the variable in question only gets
used within an "else" block, I moved the variable declaration and
use inside that block - making it clear what the scope of the variable
is.

gdb/ChangeLog:

        * ada-lang.c (ada_array_bound_from_type): Move the declaration
        and assignment of variable "elt_type" inside the else block
        where it is used.  Add two missing check_typedef calls.
        Fix bug where we got TYPE's TYPE_TARGET_TYPE, where in fact
        we really wanted to get ELT_TYPE's TYPE_TARGET_TYPE.

gdb/testsuite/ChangeLog:

        * gdb.ada/arraydim: New testcase.
2013-12-13 09:55:24 +01:00
Joel Brobecker
036e93dfda Set language for Ada minimal symbols.
This helps with the following issue: Given an Ada program defining
a global variable:

    package Pck is
       Watch : Integer := 1974;
    end Pck;

When printing the address of this variable, GDB also tries to print
the associated symbol name:

    (gdb) p watch'address
    $1 = (access integer) 0x6139d8 <pck__watch>
                                       ^^
                                       ||

The problem is that GDB prints the variable's linkage name, instead
of its natural name. This is because the language of the associated
minimal symbol never really gets set.

This patch adds handling for Ada symbols in symbol_find_demangled_name.
After this patch, we now get:

    (gdb) p watch'address
    $1 = (access integer) 0x6139d8 <pck.watch>
                                       ^
                                       |

gdb/ChangeLog:

        * symtab.c (symbol_find_demangled_name): Add handling of
        Ada symbols.

gdb/testsuite/ChangeLog:

        * gdb.ada/int_deref.exp: Add test verifying that we print
        the decoded symbol name when printing the address of Ada
        symbols.
2013-12-10 12:16:47 +01:00
Mike Frysinger
594d8fa8e9 strip off +x bits on non-executable/script files
These files are source files and have no business being +x.  We couldn't
easily fix it in CVS (you need login+write access to the raw rcs files),
but we can fix this w/git.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2013-12-07 02:03:03 -05:00
Joel Brobecker
7fb1b8b13f Ada: Reserved word "all" should not need to be spelled in lowercase.
Consider the following code:

   type Ptr is access all Integer;
   IP : Ptr := new Integer'(123);

IP is the Ada exception of a pointer to an integer. To dereference
the pointer and get its value, the user uses the reserved word "all"
as follow:

    (gdb) p ip.all
    $1 = 123

Ada being a case-insensitive language, the casing should not matter.
Unfortunately, for the reserved word "all", things don't work. For
instance:

    (gdb) p ip.ALL
    Type integer is not a structure or union type

This patch fixes the problem.

gdb/ChangeLog:

	* ada-lex.l (find_dot_all): Use strncasecmp instead of strncmp.

gdb/testsuite/ChangeLog:

        * gdb.ada/dot_all: New testcase.
2013-12-03 16:04:26 +04:00
Joel Brobecker
df7752b044 Fix int() builtin with range type gdb.Value objects.
Consider the following variable:

    type Small is range -128 .. 127;
    SR : Small := 48;

Trying to get its value as an integer within Python code yields:

    (gdb) python sr = gdb.parse_and_eval('sr')
    (gdb) python print int(sr)
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    gdb.error: Cannot convert value to int.
    Error while executing Python code.

This is happening because our variable is a range type, and
py-value's is_intlike does not handle TYPE_CODE_RANGE. This
patch fixes this.

gdb/ChangeLog:

        * python/py-value.c (is_intlike): Add TYPE_CODE_RANGE handling.

gdb/testsuite/ChangeLog:

        * gdb.ada/py_range: New testcase.
2013-11-19 06:44:40 +04:00
Joel Brobecker
ee4a1c63da gdb.ada/info_exc.exp,mi_exc_info.exp: Use more unique exception name.
In the case where the GNAT runtime was built with full debugging info,
several of the exceptions defined there might have a name contain
the word "global". To make this less likely, this patch renames
the exception name, replacing "Global" by "Global_GDB". It still
keeps the exeption name relatively short, while it is unlikely that
the GNAT runtime has an exception whose name explicitly mentions GDB,
and even less likely that it contains "Global_GDB".

gdb/testsuite/ChangeLog:

        * info_exc/const.ads (Aint_Global_GDB_E): Renames Aint_Global_E.
        * info_exc/foo.adb: Adjust to new exception name.
        * info_exc.exp: Adjust after exception renaming in const.ads.
        Update "info exception global" test to test "info exceptions
        global_gdb" instead.

        * mi_exc_info/const.ads (Aint_Global_GDB_E): Renames Aint_Global_E.
        * mi_exc_info/foo.adb (Adjust to new exception name.
        * mi_exc_info.exp: Adjust after exception renaming in const.ads.
        Update "-info-ada-exceptions global" test to test
        "-info-ada-exceptions global_gdb" instead.
2013-11-16 06:45:57 +04:00
Joel Brobecker
391d340008 gdb.ada/info_exc.exp,mi_exc_info.exp: handle runtimes with full debug info.
If the runtime has full debug info, then the non-standard exceptions
declared in the GNAT runtime will appear in the list of exceptions
printed by GDB ("info exceptions" or "-info-ada-exceptions").
This is valid output, so this patch allows for it.

gdb/testsuite/ChangeLog:

        * gdb.ada/info_exc.exp: Allow other global exceptions to be
        listed in the output of "info exceptions".
        * gdb.ada/mi_exc_info.exp: Allow other global exceptions to be
        listed in the output of "-info-ada-exceptions".
2013-11-15 20:41:06 +04:00
Joel Brobecker
e092da2903 Start inferior before running test listing Ada exceptions.
This patch fixes some spurious failures when the inferior is linked
against the shared version of libgnat by default, as appears to be
the case on many GNU/Linux distributions.  When that happens, we have
to start the program in order to ensure that the GNAT runtime is
mapped to memory, in order for us to find the standard exceptions
(defined within the runtime).  Otherwise, they will not be shown,
as expected, by the debugger.

gdb/testsuite/ChangeLog:

        * gdb.ada/info_exc.exp: Start inferior before starting
        the "info exceptions" tests.
        * gdb.ada/mi_exc_info.exp: Start inferior before starting
        the "-info-ada-exceptions" tests.
2013-11-15 20:14:25 +04:00
Joel Brobecker
0acf8b658c Fix DW_OP_GNU_regval_type with FP registers
Consider the following code, compiled at -O2 on ppc-linux:

    procedure Increment (Val : in out Float; Msg : String);

The implementation does not really matter in this case). In our example,
this function is being called from a function with Param_1 set to 99.0.
Trying to break inside that function, and running until reaching that
breakpoint yields:

    (gdb) b increment
    Breakpoint 1 at 0x100014b4: file callee.adb, line 6.
    (gdb) run
    Starting program: /[...]/foo

    Breakpoint 1, callee.increment (val=99.0, val@entry=0.0, msg=...)
        at callee.adb:6
    6             if Val > 200.0 then

The @entry value for parameter "val" is incorrect, it should be 99.0.

The associated call-site parameter DIE looks like this:

        .uleb128 0xc     # (DIE (0x115) DW_TAG_GNU_call_site_parameter)
        .byte   0x2      # DW_AT_location
        .byte   0x90     # DW_OP_regx
        .uleb128 0x21
        .byte   0x3      # DW_AT_GNU_call_site_value
        .byte   0xf5     # DW_OP_GNU_regval_type
        .uleb128 0x3f
        .uleb128 0x25

The DW_AT_GNU_call_site_value uses a DW_OP_GNU_regval_type
operation, referencing register 0x3f=63, which is $f31,
an 8-byte floating register. In that register, the value is
stored using the usual 8-byte float format:

    (gdb) info float
    f31            99.0 (raw 0x4058c00000000000)

The current code evaluating DW_OP_GNU_regval_type operations
currently is (dwarf2expr.c:execute_stack_op):

            result = (ctx->funcs->read_reg) (ctx->baton, reg);
            result_val = value_from_ulongest (address_type, result);
            result_val = value_from_contents (type,
                                              value_contents_all (result_val));

What the ctx->funcs->read_reg function does is read the contents
of the register as if it contained an address. The rest of the code
continues that assumption, thinking it's OK to then use that to
create an address/ulongest struct value, which we then re-type
to the type specified by DW_OP_GNU_regval_type.

We're getting 0.0 above because the read_reg implementations
end up treating the contents of the FP register as an integral,
reading only 4 out of the 8 bytes. Being a big-endian target,
we read the high-order ones, which gives us zero.

This patch fixes the problem by introducing a new callback to
read the contents of a register as a given type, and then adjust
the handling of DW_OP_GNU_regval_type to use that new callback.

gdb/ChangeLog:

        * dwarf2expr.h (struct dwarf_expr_context_funcs) <read_reg>:
        Extend the documentation a bit.
        <get_reg_value>: New field.
        * dwarf2loc.c (dwarf_expr_get_reg_value)
        (needs_frame_get_reg_value): New functions.
        (dwarf_expr_ctx_funcs, needs_frame_ctx_funcs): Add "get_reg_value"
        callback.
        * dwarf2-frame.c (get_reg_value): New function.
        (dwarf2_frame_ctx_funcs): Add "get_reg_value" callback.
        * dwarf2expr.c (execute_stack_op) <DW_OP_GNU_regval_type>:
        Use new callback to compute result_val.

gdb/testsuite/ChangeLog:

        * gdb.ada/O2_float_param: New testcase.
2013-11-14 22:38:48 -05:00
Joel Brobecker
a7e332c24b Implement GDB/MI equivalent of "info exceptions" CLI command.
This patch implements a new GDB/MI command implementing the equivalent
of the "info exceptions" CLI command.  The command syntax is:

    -info-ada-exceptions [REGEXP]

Here is an example of usage (slightly formatted by hand to make it
easier to read):

    -info-ada-exceptions ions\.a_
    ^done,ada-exceptions=
      {nr_rows="2",nr_cols="2",
       hdr=[{width="1",alignment="-1",col_name="name",colhdr="Name"},
            {width="1",alignment="-1",col_name="address",colhdr="Address"}],
       body=[{name="global_exceptions.a_global_exception",
              address="0x0000000000613a80"},
             {name="global_exceptions.a_private_exception",
              address="0x0000000000613ac0"}]}

Also, in order to allow graphical frontends to easily determine
whether this command is available or not, the output of the
"-list-features" command has been augmented to contain
"info-ada-exceptions".

gdb/Changelog:

        * mi/mi-cmds.h (mi_cmd_info_ada_exceptions): Add declaration.
        * mi/mi-cmds.c (mi_cmds): Add entry for -info-ada-exceptions
        command.
        * mi/mi-cmd-info.c: #include "ada-lang.c" and "arch-utils.c".
        (mi_cmd_info_ada_exceptions): New function.
        * mi/mi-main.c (mi_cmd_list_features): Add "info-ada-exceptions".

gdb/testsuite/ChangeLog:

        * gdb.ada/mi_exc_info: New testcase.
2013-11-12 06:47:16 +04:00
Joel Brobecker
778865d3e2 Add command to list Ada exceptions
This patch adds a new command "info exceptions" whose purpose is to
provide the list of exceptions currently defined in the inferior.
The usage is:

    (gdb) info exceptions [REGEXP]

Without argument, the command lists all exceptions.  Otherwise,
only those whose name match REGEXP are listed.

For instance:

    (gdb) info exceptions
    All defined Ada exceptions:
    constraint_error: 0x613dc0
    program_error: 0x613d40
    storage_error: 0x613d00
    tasking_error: 0x613cc0
    global_exceptions.a_global_exception: 0x613a80
    global_exceptions.a_private_exception: 0x613ac0

The name of the command, as well as its output is part of a legacy
I inherited long ago. It's output being parsed by frontends such as
GPS, I cannot easily change it. Same for the command name.

The implementation is mostly self-contained, and is written in a way
that should make it easy to implement the GDB/MI equivalent. The
careful reviewer will notice that the code added in ada-lang.h could
normally be made private inside ada-lang.c.  But these will be used
by the GDB/MI implementation.  Rather than making those private now,
only to move them later, I've made them public right away.

gdb/ChangeLog:

        * ada-lang.h: #include "vec.h".
        (struct ada_exc_info): New.
        (ada_exc_info): New typedef.
        (DEF_VEC_O(ada_exc_info)): New vector.
        (ada_exceptions_list): Add declaration.
        * ada-lang.c (ada_is_exception_sym)
        (ada_is_non_standard_exception_sym, compare_ada_exception_info)
        (sort_remove_dups_ada_exceptions_list)
        (ada_exc_search_name_matches, ada_add_standard_exceptions)
        (ada_add_exceptions_from_frame, ada_add_global_exceptions)
        (ada_exceptions_list_1, ada_exceptions_list)
        (info_exceptions_command): New function.
        (_initialize_ada_language): Add "info exception" command.

gdb/testsuite/ChangeLog:

        * gdb.ada/info_exc: New testcase.
2013-11-12 06:45:29 +04:00
Joel Brobecker
2df4d1d5c4 Dandling memory pointers in Ada catchpoints with GDB/MI.
When using the GDB/MI commands to insert a catchpoint on a specific
Ada exception, any re-evaluation of that catchpoint (for instance
a re-evaluation performed after a shared library got mapped by the
inferior) fails. For instance, with any Ada program:

    (gdb)
    -catch-exception -e program_error
    ^done,bkptno="1",bkpt={[...]}
    (gdb)
    -exec-run
    =thread-group-started,id="i1",pid="28315"
    =thread-created,id="1",group-id="i1"
    ^running
    *running,thread-id="all"
    (gdb)
    =library-loaded,[...]
    &"warning: failed to reevaluate internal exception condition for catchpoint 1: No definition of \"exec\" in current context.\n"
    &"warning: failed to reevaluate internal exception condition for catchpoint 1: No definition of \"exec\" in current context.\n"
    [...]

The same is true if using an Ada exception catchpoint.

The problem comes from the fact that that we deallocate the strings
given as arguments to create_ada_exception_catchpoint, while the latter
just makes shallow copies of those strings, thus creating dandling
pointers.

This patch fixes the issue by passing freshly allocated strings to
create_ada_exception_catchpoint, while at the same time updating
create_ada_exception_catchpoint's documentation to make it clear
that deallocating the strings is no longer the responsibility of
the caller.

gdb/ChangeLog:

        * ada-lang.c (create_ada_exception_catchpoint): Enhance
        the documentation of fields "except_string" and "condition".
        * mi/mi-cmd-catch.c (mi_cmd_catch_assert): Reallocate
        CONDITION on the heap before passing it to
        create_ada_exception_catchpoint.
        (mi_cmd_catch_exception): Likewise for EXCEPTION_NAME and
        CONDITION.

gdb/testsuite/ChangeLog:

        * gdb.ada/mi_ex_cond: New testcase.

Tested on x86_64-linux.  The "-break-list" test FAILs without
this patch.
2013-11-11 19:19:07 +04:00
Joel Brobecker
2a3be96627 Adjust gdb.ada/mi_catch_ex.exp to use GDB/MI catch commands...
... in place of the CLI "catch ..." commands.  The latter were used
because the GDB/MI equivalents were not available at the time.

gdb/testsuite/ChangeLog:

        * gdb.ada/mi_catch_ex.exp: Adjusts all "catch ..." tests to
        use the appropriate GDB/MI command instead, and verify
        the test output.
2013-10-11 13:49:36 +00:00
Joel Brobecker
c968bd18df gdb.ada/mi_catch_ex.exp: Make test names unique.
gdb/testsuite/ChangeLog:

        * gdb.ada/mi_catch_ex.exp: Make "mi_execute_to" test names unique.
2013-10-08 10:25:22 +00:00
Tom Tromey
4229ca0ea6 simple test suite fix in gdb.ada
This changes one spot in gdb.ada to use standard_testfile.

	* gdb.ada/info_types.exp: Use standard_testfile.
2013-07-16 18:52:18 +00:00
Joel Brobecker
51b8642693 [testsuite/Ada] Add testing of access to packed arrays.
This patch adds some tests that evidence a regression fixed by
the following patch from Pedro Alves:

    [PATCH] ada-lang.c:coerce_unspec_val_to_type: Preserve laziness
    http://www.sourceware.org/ml/gdb-patches/2013-07/msg00178.html

gdb/testsuite/ChangeLog:

        * gdb.ada/arrayptr/foo.adb: Add some code defining an access
        to a packed array.
        * gdb.ada/arrayptr.exp: Add a few tests using that new access
        to packed array.
2013-07-10 00:35:01 +00:00