Re: [PATCH 1/2] Fix "list ambiguous_variable"

Simon Marchi
2017-10-16T15:03:41Z

On 2017-09-20 11:25 AM, Pedro Alves wrote:
> On 09/06/2017 07:41 PM, Keith Seitz wrote:
>> On 09/04/2017 11:47 AM, Pedro Alves wrote:
>>> The "list" command allows specifying the name of variables as
>>> argument, not just functions, so that users can type "list
>>> a_global_variable".
>>>
>>> That support is a broken when it comes to ambiguous locations though.
>>
>> Very nice!
>>
>> FWIW, I have only one trivial nit (below).
>>
>> Keith
>>
>> PS. Out of curiosity, I hacked up a test program with multiple symbols named "ambiguous," both functions and variables. Well done!
>
> Awesome. :-)
>
>>
>> (gdb) set listsize 3
>> (gdb) list ambiguous
>> file: "amb1.c", line number: 5, symbol: "ambiguous"
>> 4
>> 5 static int ambiguous = 0;
>> 6
>> file: "amb2.c", line number: 3, symbol: "ambiguous"
>> 2 ambiguous (void)
>> 3 {
>> 4 return 0;
>> file: "amb3.c", line number: 3, symbol: "ambiguous"
>> 2 ambiguous (void)
>> 3 {
>> 4 return 0;
>> file: "amb4.c", line number: 1, symbol: "ambiguous"
>> 1 static int ambiguous = 0;
>> 2
>> 3 int
>>
>
>>> - /* The minimal symbol might point to a function descriptor;
>>> - resolve it to the actual code address instead. */
>>> - pc = gdbarch_convert_from_func_ptr_addr (gdbarch, sal.pc, &current_target);
>>> - if (pc != sal.pc)
>>> - sal = find_pc_sect_line (pc, NULL, 0);
>>> + /* The minimal symbol might point to a function descriptor;
>>> + resolve it to the actual code address instead. */
>>> + pc = gdbarch_convert_from_func_ptr_addr (gdbarch, sal.pc, &current_target);
>>
>> This line exceeds the 80-char line length limit.
>
> Indeed it does. Fixed before pushing (both patches).
>
> Thanks for the review!
>

Hi Pedro,

The buildbot shows some failures on ppc64be:

PASS -> FAIL: gdb.base/dbx.exp: whereis my_list
PASS -> FAIL: gdb.mi/gdb669.exp: -thread-list-ids
PASS -> FAIL: gdb.mi/gdb669.exp: finding MI result string
PASS -> FAIL: gdb.mi/gdb669.exp: finding number of threads in MI output

I tested on gcc110, and bisect points to this patch here (for both tests).
A symptom of the problem is that "break main" generates two locations.

Before (at e5f25bc5^):

(gdb) b main
Breakpoint 1 at 0x10000560: file test.c, line 3.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000010000560 in main at test.c:3

After (at e5f25bc5)

(gdb) b main
Breakpoint 1 at 0x10000560: main. (2 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x0000000010000560 in main at test.c:3
1.2 y 0x0000000010020078

Simon