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

[Pedro Alves <pedro@palves.net>]

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.