This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64

On Sat, Jan 10, 2004 at 07:00:35PM +0100, Mark Kettenis wrote:
> This (together with the previous patch) fixes the problems I saw with
> gdb.cp/bs15503.exp.  The check for non-POD-ness isn't complete though.
> I hope to revisit that later, after someone tells me how to properly
> determine non-POD-ness.
> Mark
> P.S. The amd64_non_pod_p function should probably be moved to the
>      generic cod, but we can do that later.

Does the x86-64 ABI really pass non-POD and POD types of the same size
differently?  If so, I hope the ABI defines non-POD rather than relying
on the C++ definition, since we do not generally have enough
information in the debug info to determine whether a type is POD.

> +  /* ??? A class with a base class certainly isn't POD, but does this
> +     catch all non-POD structure types?  */
> +  if (TYPE_CODE (type) == TYPE_CODE_STRUCT && TYPE_N_BASECLASSES (type) > 0)
> +    return 1;

No, at least any type with explicitly declared methods is non-POD.  For
DWARF you can probably get this right by checking for a non-artificial
method but for stabs you're SOL.

I don't remember what other things determine POD-ness.  I think
private/public may also.

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]