(Ada) fix GDB crash printing packed array
authorJoel Brobecker <brobecker@adacore.com>
Sun, 17 Feb 2019 13:32:45 +0000 (08:32 -0500)
committerJoel Brobecker <brobecker@adacore.com>
Sun, 17 Feb 2019 13:32:45 +0000 (08:32 -0500)
commita2cd4f14750ae27ea5c250c98965eef842ee57db
treefb3010d255aef8b34142af2379ca7a30b731d532
parentaa9e1dc0c6b965e0db07bf7e9fa93cbf0922a743
(Ada) fix GDB crash printing packed array

Trying to print a packed array sometimes leads to a crash (see
attached testcase for an example of when this happens):

  | (gdb) p bad
  | [1]    65571 segmentation fault  gdb -q foo

Variable "bad" is declared in the debug information as an array where
the array's type name has an XPnnn suffix:

  | .uleb128 0xc    # (DIE (0x566) DW_TAG_typedef)
  | .long   .LASF200        # DW_AT_name: "pck__t___XP1"
  | [loc info attributes snipped]
  | .long   0x550   # DW_AT_type
  | .byte   0x1     # DW_AT_alignment

The signals to GDB that the debugging information follows a GNAT encoding
used for packed arrays, and an in order to decode it, we need to find
the type whose name is the same minus the "___XPnnn" suffix: "pck__t".

For that, we make a call to ada-lang.c::standard_lookup, which is
a simple function which essentially does:

  | /* Return the result of a standard (literal, C-like) lookup of NAME in
  |    given DOMAIN, visible from lexical block BLOCK.  */
  |
  |   [...]
  |   sym = lookup_symbol_in_language (name, block, domain, language_c, 0);

Unfortunately for us, while the intent of this call was to perform
an exact-match lookup, in our case, it returns ... type pck__t___XP1
instead! In other words, it finds itself back. The reason why it finds
this type is a confluence of two factors:

  (1) Forcing the lookup into language_c currently does not affect
      how symbol matching is done anymore, because we look at the symbol's
      language to determine which kind of matching should be done;

  (2) The lookup searches the local context (via block) first, beforei
      doing a more general lookup. And looking at the debug info for
      the main subprogram, we see that type "pck__t" is not declared
      there, only in the debug info for pck.ads. In other words,
      there is no way that we accidently find "pck__t" by random chance.

I believe Pedro added a new function called ada_lookup_encoded_symbol
for that specific purpose, so I started by replacing the lookup
by language above by this. Unfortunately, still no joy.

This was because, even though ada_lookup_encoded_symbol puts angle-
brackets around the search name to signal that we want a verbatim
search, we end up losing that information in the function called
to compare a symbol with the search name:

  | static bool
  | do_full_match (const char *symbol_search_name,
  |                const lookup_name_info &lookup_name,
  |                completion_match_result *comp_match_res)
  | {
  |   return full_match (symbol_search_name, ada_lookup_name (lookup_name));
                                             ^^^^^^^^^^^^^^^
                                                    |
                                    <=> lookup_name.m_ada.m_encoded_name
                                           (no angle brackets)

The way I fixed this was by introducing a new function called
do_exact_match, and then adjust ada_get_symbol_name_matcher to
return that function when seeing that we have a verbatim non-wild-match
search.

As it happens, this fixes an incorrect test in gdb.ada/homony.exp,
where we were inserting a breakpoint on a symbol using the angle-brackets
notation, and got 2 locations for that breakpoint...

    (gdb) b <homonym__get_value>
    Breakpoint 1 at 0x4029fc: <homonym__get_value>. (2 locations)

...  each location being in a different function:

    (gdb) info break
    Num     Type           Disp Enb Address            What
    1       breakpoint     keep y   <MULTIPLE>
    1.1                         y   0x00000000004029fc in homonym.get_value
                                    at /[...]/homonym.adb:32
    1.2                         y   0x0000000000402a3a in homonym.get_value
                                    at /[...]/homonym.adb:50
    (gdb) x /i 0x00000000004029fc
       0x4029fc <homonym__get_value+8>:     movl   $0x1d,-0x4(%rbp)
    (gdb) x /i 0x0000000000402a3a
       0x402a3a <homonym__get_value__2+8>:  movl   $0x11,-0x4(%rbp)

Since we used angle-brackets, we shouldn't be matching the second one,
something this patch fixes.

gdb/ChangeLog:

        * ada-lang.c (standard_lookup): Use ada_lookup_encoded_symbol
        instead of lookup_symbol_in_language
        (do_exact_match): New function.
        (ada_get_symbol_name_matcher): Return do_exact_match when
        doing a verbatim match.

gdb/testsuite/ChangeLog:

        * gdb.ada/big_packed_array: New testcase.
        * gdb.ada/homonym.exp: Fix incorrect expected output for
        "break <homonym__get_value>" test.

Tested on x86_64-linux.
gdb/ChangeLog
gdb/ada-lang.c
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.ada/big_packed_array.exp [new file with mode: 0644]
gdb/testsuite/gdb.ada/big_packed_array/foo_ra24_010.adb [new file with mode: 0644]
gdb/testsuite/gdb.ada/big_packed_array/pck.adb [new file with mode: 0644]
gdb/testsuite/gdb.ada/big_packed_array/pck.ads [new file with mode: 0644]
gdb/testsuite/gdb.ada/homonym.exp