This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Breaking on C labels?


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]