From: Jim Blandy <jimb@codesourcery.com>
To: Michael Snyder <Michael.Snyder@palmsource.com>
Cc: Joel Brobecker <brobecker@adacore.com>, gdb@sourceware.org
Subject: Re: Breaking on C labels?
Date: Fri, 26 Jan 2007 21:04:00 -0000 [thread overview]
Message-ID: <m364atmrdq.fsf@codesourcery.com> (raw)
In-Reply-To: <1169839590.14604.31.camel@localhost.localdomain> (Michael Snyder's message of "Fri, 26 Jan 2007 11:26:30 -0800")
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.
prev parent reply other threads:[~2007-01-26 21:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-25 19:48 Joel Brobecker
2007-01-25 21:19 ` Jim Blandy
2007-01-26 0:05 ` Michael Snyder
2007-01-26 1:01 ` Joel Brobecker
2007-01-26 18:55 ` Jim Blandy
2007-01-26 19:41 ` Michael Snyder
2007-01-26 21:04 ` Jim Blandy [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m364atmrdq.fsf@codesourcery.com \
--to=jimb@codesourcery.com \
--cc=Michael.Snyder@palmsource.com \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox