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

Pedro Alves
2020-08-28T13:32:53Z

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.