This is the mail archive of the
mailing list for the GDB project.
Re: [unwind-20030108-branch] Add sentinel-frame + misc
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
I suppose we could work around this for debugging purposes by:
typedef struct foo foobaz;
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.
MontaVista Software Debian GNU/Linux Developer