[PATCH][gdb/breakpoint] Handle setting breakpoint on label without address

[Tom de Vries]

On 8/28/20 3:53 PM, Tom de Vries wrote:
> On 8/28/20 3:32 PM, Pedro Alves wrote:
>> On 8/27/20 2:49 PM, Tom de Vries wrote:
>>> On 8/27/20 2:41 PM, Pedro Alves wrote:
>>>> On 8/27/20 12:52 PM, Tom de Vries wrote:
>>>>> Hi,
>>>>>
>>>>> Consider test-case test.c:
>>>>> ...
>>>>> $ cat test.c
>>>>> int main (void) {
>>>>>   return 0;
>>>>>  L1:
>>>>>   (void)0;
>>>>> }
>>>>> ...
>>>>>
>>>>> Compiled with debug info:
>>>>> ...
>>>>> $ gcc test.c -g
>>>>> ...
>>>>>
>>>>> When attempting to set a breakpoint at L1, which is a label without address:
>>>>> ...
>>>>>  <1><f4>: Abbrev Number: 2 (DW_TAG_subprogram)
>>>>>     <f5>   DW_AT_name        : main
>>>>>  <2><115>: Abbrev Number: 3 (DW_TAG_label)
>>>>>     <116>   DW_AT_name        : L1
>>>>>     <119>   DW_AT_decl_file   : 1
>>>>>     <11a>   DW_AT_decl_line   : 5
>>>>>  <2><11b>: Abbrev Number: 0
>>>>
>>>> Is this a debug info bug,
>>>
>>> Strictly speaking, this is a debug info bug.  The standard says that:
>>> ...
>>> The label entry has a DW_AT_low_pc attribute whose value is the address
>>> of the first executable instruction for the location identified by the
>>> label in the source program.
>>> ...
>>>
>>> But I interpret the missing DW_AT_low_pc attribute as: there is a label
>>> in the source, but the corresponding code has been optimized out.
>>>
>>>> or is the debug info telling us that the
>>>> address of the label is the same as the line number's address?
>>>>
>>>> How about looking up the line number address instead of throwing
>>>> an error?
>>>>
>>>
>>> Well, in this particular case, that wouldn't help.
>>>
>>> With L1 at line 3:
>>> ...
>>> $ cat -n test.c
>>>      1  int main (void) {
>>>      2    return 0;
>>>      3   L1:
>>>      4    (void)0;
>>>      5  }
>>>      6
>>> ...
>>> there's no corresponding address:
>>> ...
>>> $ readelf -wL a.out
>>> CU: test.c:
>>> File name                            Line number    Starting address
>>> View    Stmt
>>> test.c                                         1            0x400497
>>>            x
>>> test.c                                         2            0x40049b
>>>            x
>>> test.c                                         5            0x4004a0
>>>            x
>>> test.c                                         -            0x4004a2
>>> ...
>>>
>>> My suspicion is that this won't be useful in general.
>>
>> I don't understand the "not useful" remark.  If a user does gets
>> the error, they'll probably do:
>>
>>   "b 3",
>>
>> and they'll get a breakpoint at line 5, no?
>>
>> That's very likely what a user would do after the error.
>>
>> IMO GDB should do that for the user.
>>
>> So far I don't agree with your patch.
>>
> 
> I see what you mean, but let's try this counter-example:
> ...
>  cat -n test.c
>      1  int
>      2  main (void)
>      3  {
>      4    goto L2;
>      5
>      6   L3:
>      7    return 0;
>      8
>      9   L1:
>     10    (void)0;
>     11    return 1;
>     12
>     13   L2:
>     14    goto L3;
>     15  }
>     16
> ...
> compiled like this:
> ...
> $ gcc test.c -g
> ...
> 
> With the patch, we're not able to set a breakpoint at L1, and setting
> the breakpoint at the corresponding line, line 9:
> ...
> $ gdb a.out
> Reading symbols from a.out...
> (gdb) b main:L1
> Location main:L1 not available
> (gdb) b 9
> Breakpoint 1 at 0x40049c: file test.c, line 14.
> (gdb)
> ...
> yields a breakpoint at line 14, a piece of code that's not reachable
> from L1.
> 
> To me, label L1 and line 14 are unrelated enough to convince me to not
> do this automatically.
> 

FWIW, lldb does the same:
...
$ lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) b main:L1
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) b 9
Breakpoint 2: where = a.out`main + 5 at test.c:14, address =
0x000000000040049c
(lldb)
...

Thanks,
- Tom