This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA/PATCH] breakpoint.c: fix until command
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Michael Elizabeth Chastain <mec at shout dot net>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 3 Jan 2003 11:57:09 -0500
- Subject: Re: [RFA/PATCH] breakpoint.c: fix until command
- References: <200301031638.h03GcP615183@duracef.shout.net>
On Fri, Jan 03, 2003 at 10:38:25AM -0600, Michael Elizabeth Chastain wrote:
> Hi Daniel,
>
> mec> So we might need additional promises.
> mec> I think it would be reasonable for us to ask for them if we decide
> mec> we need them.
>
> drow> I don't. Promises don't mean anything; we have existing code.
>
> A promise in a manual is a contract. If gcc violates its contract,
> then gcc is at fault, and we can file bug reports against it. That's
> what I'm getting at.
We support other compilers; we support other versions of GCC. The life
of a debugger is that making people fix the compiler isn't going to
fly.
> mec> If we are in foo:67, and the user asks to 'until 70',
> mec> then I bet we can figure out that '70' is in the current function no
> mec> matter where its object code addresses are.
>
> drow> No, we can't. It's a pretty fundamental rule that we can never do
> drow> anything except display source lines. Consider code re-organization,
> drow> templates, macros, #line directives...
>
> Okay, I am naive here. I see a DW_TAG_subprogram for each function
> with a DW_AT_decl_line. Can't we use that information to build a table
> that maps source line #'s to function names?
>
> But you know much more about this area then I do so if you are gloomy,
> I have to be gloomy, too.
No. Here's the problem: generally, a code address maps to one
file:line pair. Generally. It's not always clear what file:line it
is, and sometimes it could reasonably map to multiple file:line's; for
instance, common subexpression hoisting. But generally, we can go from
PC to file:line.
Right now we have code to go from file:line to PC. However, assuming
that you can do that is wrong. Consider:
inline int baz()
{
return something
-complicated;
}
int main()
{
int a;
a = baz();
return a * baz();
}
We're on the "return something" line. For the purposes of "until", if
someone said we could go to the "-complicated" line, it's obvious what
we mean; this inline instance. In general, that's not true. From the
linespec we have no way to figure out which inline instance is referred
to. We lose.
[Similarly, we need to stop assuming a symbol name maps to one PC.
This causes us to mess up constructor breakpoints right now. GDB has
essentially no support for debugging inline functions, and it's a
problem there too. DWARF-2 tells us where every single inlined copy
is, but what do we do with that information? More, how do we present
it to the user? Big interface problems here.]
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer