Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Mark Kettenis <kettenis@chello.nl>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Classify non-POD struct types more or less correctly on AMD64
Date: Sat, 10 Jan 2004 18:36:00 -0000	[thread overview]
Message-ID: <20040110183622.GA8108@nevyn.them.org> (raw)
In-Reply-To: <200401101800.i0AI0Zm6026623@elgar.kettenis.dyndns.org>

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


  reply	other threads:[~2004-01-10 18:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-10 18:00 Mark Kettenis
2004-01-10 18:36 ` Daniel Jacobowitz [this message]
2004-01-10 18:59   ` Mark Kettenis
2004-01-11  4:10     ` Daniel Jacobowitz
2004-01-11 12:38       ` Mark Kettenis
2004-01-11 13:29         ` Jan Hubicka
2004-01-12  5:37           ` Mark Mitchell
2004-01-11 15:05         ` Gabriel Dos Reis
2004-03-19  0:09         ` Daniel Jacobowitz
2004-03-09 15:39           ` Daniel Jacobowitz
2004-03-19  0:09           ` Mark Mitchell
2004-03-10  3:38             ` Mark Mitchell
2004-03-10  4:21             ` Daniel Jacobowitz
2004-03-19  0:09               ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040110183622.GA8108@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kettenis@chello.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox