Joel Brobecker a2cd4f1475 (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.		2019-02-17 08:32:45 -05:00
..
foo_ra24_010.adb
pck.adb
pck.ads