Re: [unwind-20030108-branch] Add sentinel-frame + misc

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, Jan 11, 2003 at 03:42:43PM -0500, Andrew Cagney wrote:
> 
> >It's hardly a bug; more of a deep interface shortcoming.  Consider:
> 
> Which is a bug.
> 
> >File A declares a type 'struct foo'.
> >File B declares a type 'struct foo'.
> >Header C forward declares 'struct foo;' and 'struct foo *get_foo ()'.
> >File D includes Header C and uses 'get_foo'.
> >
> >I'm sitting in File D, and I want to look in the debugger at this
> >opaque unwind cache.  There's no possible way to associate it with
> >either struct foo.
> >
> >That's why I think the construct should be avoided; if one of them is
> >A_foo and the other is B_foo, and we do a bit of casting, then at least
> >I can dump the one I want.
> 
> Shouldn't something like:
> 	('File A:struct foo' *) get_foo()
> work?  Even:
> 	(gdb) list 'File A'
> 	(gdb) print *(struct foo) get_foo()

It would be nice if we defined a syntax for this, preferably one which
won't conflict with everything under the sun.  Neither of the above
work, by the way.

> How does GDB differentiate between variables and enum's when they have 
> multiple declarations?

Badly?  If I refer to a variable declared in File D, I always get the
version from File B; no matter what cast or listing games I play.  If I
print a variable in File A it gets the type from File A, but once I'm
outside that file, no beans.

Hmm, even worse: before loading symbols for Files A or B explicitly, I
get the type from File A; once symbols are loaded I get the type from
File B.

I suppose we could work around this for debugging purposes by:
File A:
  typedef struct foo foobaz;
File B:
  typedef struct foo foobar;

Which does work "correctly" in the debugger; so my objection is
withdrawn.  We do need to solve this problem someday.  I've put
together a testcase; I'll put it in GNATS later.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer