Re: [PATCH] Add support for tracking/evaluating dwarf2 locationexpressions

[Daniel Berlin <dan at www dot cgsoftware dot com>]

On Fri, 6 Apr 2001, Kevin Buettner wrote:

> On Apr 6,  3:10pm, Daniel Berlin wrote:
>
> > On Fri, 6 Apr 2001, Andrew Cagney wrote:
> >
> > > > >   value_ptr stack[64];
> > > > > Is there a constant for this?  A quick glance at decode_locdesc() and it
> > > > > has the same hardwired constant.
> > > > Nobody has ever produced location expressions that need more.
> > >
> > > The problem typically isn't with what people are doing intentionally but
> > > rather unintentionally.  The code opens the way for an input file to
> > > cause gdb to overflow a buffer and trash its stack.
> >
> > Well, as I said, it will trash  GCC as well, since they do no range
> > checking, and have the exact same limit.
> > But i'll range check it, just the same.
>
> Maybe GCC has been designed so that it'll never need a bigger stack.
No, it hasn't.
It's a FIXME that's never been fixed :)

> But keep in mind that GDB needs to accept as input the output of
> compilers other than GCC.

Of course.

I think you aren't getting what i say by "break GCC". I mean that all of
the STL classes, and anything that *can* throw exceptions, would miserably
fail, and segfault, at runtime, if something ever went above that limit.

That's a much greater risk than we are facing, by having gdb maybe dump
core, no?

  Perhaps some other compiler, through either
> a bug or a feature, will produce more complicated location expressions
> than GCC.

Yeah, but a single location expression requiring 64 things on the stack,
just to evaluate? Remember, adds/removes/etc reduce the number of things
on the stack, or keep it constant, they don't add.

And also, location expressions are for a single web (unioned live ranges
of a variable), location lists are used to describe where it is over a
given range of PC's, which consist of multiple location expressions.

I can't even fathom a way to use more than 64 stack entries.  You could
split a variable into almost an infinite number of places (IE say the
first byte is in a register, the next byte is at this given memory
address, etc), at once, and *still* not hit the limit.
But anyway, i added the range check, so this is all moot. ust rambling. :)




 > Anyway, I'm glad  you've added the range check. >
> Kevin
>