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

[Simon Marchi <simon dot marchi at ericsson dot com>]

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 <main>

Simon