Breaking on C labels?

Breaking on C labels?

[Joel Brobecker]

Hello,

A customer asked us a question about the ability of breaking on labels
inside C code. Consider for instance:

        void
        procedure foo (void)
        {
           [...]
        error_handler:
           [...]
        }

The customer asked if it was possible to break at the error_handler
label. We are helping them with finding alternative solutions, but
I still did a bit of researching...

I discovered without much surprise that DWARF does indeed have provision
for labels (DW_TAG_label). However, I also noticed that GCC already
generates the associated DIEs. We actually even process them. However,
all my attempts in trying to reference them from the debugger failed.
I tried "break error_handler", or more simply "p error_handler", etc.

Did we ever make any attempt in implementing this sort of functionality
in the past?

Looking at the source code, I found in new_symbol ():

        case DW_TAG_label:
          attr = dwarf2_attr (die, DW_AT_low_pc, cu);
          if (attr)
            {
              SYMBOL_VALUE_ADDRESS (sym) = DW_ADDR (attr) + baseaddr;
            }
          SYMBOL_CLASS (sym) = LOC_LABEL;
          break;

So we setup the symbol, but we don't add to any of our symbol lists...
I am left wondering what it is that we'll be doing with this symbol.

Thanks,
-- 
Joel, curious

Re: Breaking on C labels?

[Jim Blandy]

Joel Brobecker <brobecker@adacore.com> writes:
> A customer asked us a question about the ability of breaking on labels
> inside C code. Consider for instance:
>
>         void
>         procedure foo (void)
>         {
>            [...]
>         error_handler:
>            [...]
>         }
>
> The customer asked if it was possible to break at the error_handler
> label. We are helping them with finding alternative solutions, but
> I still did a bit of researching...
>
> I discovered without much surprise that DWARF does indeed have provision
> for labels (DW_TAG_label). However, I also noticed that GCC already
> generates the associated DIEs. We actually even process them. However,
> all my attempts in trying to reference them from the debugger failed.
> I tried "break error_handler", or more simply "p error_handler", etc.
>
> Did we ever make any attempt in implementing this sort of functionality
> in the past?
>
> Looking at the source code, I found in new_symbol ():
>
>         case DW_TAG_label:
>           attr = dwarf2_attr (die, DW_AT_low_pc, cu);
>           if (attr)
>             {
>               SYMBOL_VALUE_ADDRESS (sym) = DW_ADDR (attr) + baseaddr;
>             }
>           SYMBOL_CLASS (sym) = LOC_LABEL;
>           break;
>
> So we setup the symbol, but we don't add to any of our symbol lists...
> I am left wondering what it is that we'll be doing with this symbol.

You're right, it looks to me as if we just throw the symbol away, too.

The logical thing would be to put it in the block of the function it's
in, since goto labels are block-scoped.  It would go in LABEL_DOMAIN,
since that's a separate namespace.  And then you'd need to teach
linespec.[ch] about them.

Re: Breaking on C labels?

[Michael Snyder]

On Thu, 2007-01-25 at 13:19 -0800, Jim Blandy wrote:
> Joel Brobecker <brobecker@adacore.com> writes:
> > A customer asked us a question about the ability of breaking on labels
> > inside C code. Consider for instance:
> >
> >         void
> >         procedure foo (void)
> >         {
> >            [...]
> >         error_handler:
> >            [...]
> >         }
> >
> > The customer asked if it was possible to break at the error_handler
> > label. We are helping them with finding alternative solutions, but
> > I still did a bit of researching...
> >
> > I discovered without much surprise that DWARF does indeed have provision
> > for labels (DW_TAG_label). However, I also noticed that GCC already
> > generates the associated DIEs. We actually even process them. However,
> > all my attempts in trying to reference them from the debugger failed.
> > I tried "break error_handler", or more simply "p error_handler", etc.
> >
> > Did we ever make any attempt in implementing this sort of functionality
> > in the past?
> >
> > Looking at the source code, I found in new_symbol ():
> >
> >         case DW_TAG_label:
> >           attr = dwarf2_attr (die, DW_AT_low_pc, cu);
> >           if (attr)
> >             {
> >               SYMBOL_VALUE_ADDRESS (sym) = DW_ADDR (attr) + baseaddr;
> >             }
> >           SYMBOL_CLASS (sym) = LOC_LABEL;
> >           break;
> >
> > So we setup the symbol, but we don't add to any of our symbol lists...
> > I am left wondering what it is that we'll be doing with this symbol.
> 
> You're right, it looks to me as if we just throw the symbol away, too.
> 
> The logical thing would be to put it in the block of the function it's
> in, since goto labels are block-scoped.  It would go in LABEL_DOMAIN,
> since that's a separate namespace.  And then you'd need to teach
> linespec.[ch] about them.

There's a risk that some symbol-lookup function would then select that
label instead of the function entry label when you tried to look up the
nearest label preceeding a given address.

Re: Breaking on C labels?

[Joel Brobecker]

> There's a risk that some symbol-lookup function would then select that
> label instead of the function entry label when you tried to look up the
> nearest label preceeding a given address.

Yes, I was actually also thinking about that... Even though GDB tends
to prefer debugging information over plain symbols, it still uses minsym
lookups during symbol/psymbol lookups...

This may not be as straightforward as it looks.

In any case, I was just curious about this, wondering whether we broke
this feature or never implemented it. Sounds like the latter. There are
other things that motivate me more than support for labels. I tend to
think that usage of labels in C should be relatively rare, and it's
pretty easy to implement ways of working around that limitation.

-- 
Joel

Re: Breaking on C labels?

[Jim Blandy]

Michael Snyder <Michael.Snyder@palmsource.com> writes:
> There's a risk that some symbol-lookup function would then select that
> label instead of the function entry label when you tried to look up the
> nearest label preceeding a given address.

This should be easy to avoid, shouldn't it?  We would only recognize
LOC_LABEL entries for breakpoints, and ignore them for lookups by
address.

Re: Breaking on C labels?

[Michael Snyder]

On Fri, 2007-01-26 at 10:55 -0800, Jim Blandy wrote:
> Michael Snyder <Michael.Snyder@palmsource.com> writes:
> > There's a risk that some symbol-lookup function would then select that
> > label instead of the function entry label when you tried to look up the
> > nearest label preceeding a given address.
> 
> This should be easy to avoid, shouldn't it?  We would only recognize
> LOC_LABEL entries for breakpoints, and ignore them for lookups by
> address.

I'm not sure, it's too long since I looked at it.
Are you sure LOC_LABEL is the correct attribute?
Seems to me, that might be what is used by the compiler
for all those ".L123" labels that it uses for loop
control etc.  

You don't want to get mixed up with those, because
there's a bazillion of them, and we want them to get
stripped out by the linker.

Re: Breaking on C labels?

[Jim Blandy]

Michael Snyder <Michael.Snyder@palmsource.com> writes:
> On Fri, 2007-01-26 at 10:55 -0800, Jim Blandy wrote:
>> Michael Snyder <Michael.Snyder@palmsource.com> writes:
>> > There's a risk that some symbol-lookup function would then select that
>> > label instead of the function entry label when you tried to look up the
>> > nearest label preceeding a given address.
>> 
>> This should be easy to avoid, shouldn't it?  We would only recognize
>> LOC_LABEL entries for breakpoints, and ignore them for lookups by
>> address.
>
> I'm not sure, it's too long since I looked at it.
> Are you sure LOC_LABEL is the correct attribute?
> Seems to me, that might be what is used by the compiler
> for all those ".L123" labels that it uses for loop
> control etc.  

No --- those would be minsyms.  LOC_LABEL is an 'enum address_class';
only symbols and partial symbols have those.

The original question was about breaking on C 'goto' labels.  Those
are source-level constructs, recorded in the DWARF.

We don't need to produce partial symbols for them, since they're local
to a function: the user must refer to the function (by name or by
address) before they can refer to the label, so the full symtabs for
that compilation unit will always be loaded.

We do need to produce full symbols for them, with the LOC_LABEL
address class.

We needn't make any changes at all to minsym handling.