From: Paul Bolle <pebolle@tiscali.nl>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org, Daniel Jacobowitz <dan@codesourcery.com>
Subject: Re: [PATCH] [RFC] python: gdb.Type: strip typedefs past pointers too
Date: Mon, 20 Sep 2010 16:25:00 -0000 [thread overview]
Message-ID: <1284979636.1857.47.camel@localhost.localdomain> (raw)
In-Reply-To: <20100920100417.GA5751@host1.dyn.jankratochvil.net>
On Mon, 2010-09-20 at 12:04 +0200, Jan Kratochvil wrote:
> On Fri, 17 Sep 2010 21:55:56 +0200, Paul Bolle wrote:
> > 1) I drafted a patch (pasted below this message) that works around this
> > limitation:
> >
> > (gdb) ptype wchar_t
> > type = long int
> > (gdb) ptype wchar_t *
> > type = long int *
>
> What is the goal of this patch? strip_typedefs I understand to be the Python
> interface to check_typedef.
Basically I tried to emulate the current behavior of the ptype command,
which goes past pointers to look whether their target is typedef'd too
(see the second example above). Daniel explained that this seems to be a
bug in the ptype command.
> The strip_typedefs description should be fixed anyway as the text is now
> ambiguous.
Do you mean that the current text is ambiguous? In the commit message of
my draft patch I noted that strip_typedefs() "doesn't really behave as
advertised (well, as I understand the advertisement)". I understood that
text to mean that behavior similar to that of the ptype command was
intended.
Paul Bolle
WARNING: multiple messages have this Message-ID
From: Paul Bolle <pebolle@tiscali.nl>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org, Daniel Jacobowitz <dan@codesourcery.com>
Subject: Re: [PATCH] [RFC] python: gdb.Type: strip typedefs past pointers too
Date: Mon, 20 Sep 2010 13:59:00 -0000 [thread overview]
Message-ID: <1284979636.1857.47.camel@localhost.localdomain> (raw)
Message-ID: <20100920135900.lj1_YOTf85WJQPt00GWAdHgmTpWfEYdUE4dJ5pEOZqI@z> (raw)
In-Reply-To: <20100920100417.GA5751@host1.dyn.jankratochvil.net>
On Mon, 2010-09-20 at 12:04 +0200, Jan Kratochvil wrote:
> On Fri, 17 Sep 2010 21:55:56 +0200, Paul Bolle wrote:
> > 1) I drafted a patch (pasted below this message) that works around this
> > limitation:
> >
> > (gdb) ptype wchar_t
> > type = long int
> > (gdb) ptype wchar_t *
> > type = long int *
>
> What is the goal of this patch? strip_typedefs I understand to be the Python
> interface to check_typedef.
Basically I tried to emulate the current behavior of the ptype command,
which goes past pointers to look whether their target is typedef'd too
(see the second example above). Daniel explained that this seems to be a
bug in the ptype command.
> The strip_typedefs description should be fixed anyway as the text is now
> ambiguous.
Do you mean that the current text is ambiguous? In the commit message of
my draft patch I noted that strip_typedefs() "doesn't really behave as
advertised (well, as I understand the advertisement)". I understood that
text to mean that behavior similar to that of the ptype command was
intended.
Paul Bolle
WARNING: multiple messages have this Message-ID
From: Paul Bolle <pebolle@tiscali.nl>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org, Daniel Jacobowitz <dan@codesourcery.com>
Subject: Re: [PATCH] [RFC] python: gdb.Type: strip typedefs past pointers too
Date: Mon, 20 Sep 2010 16:08:00 -0000 [thread overview]
Message-ID: <1284979636.1857.47.camel@localhost.localdomain> (raw)
Message-ID: <20100920160800.NnaMF5WqE8VhF2EAMbs1dTtENzPrUXr9yrJqpb8YB7Q@z> (raw)
In-Reply-To: <20100920100417.GA5751@host1.dyn.jankratochvil.net>
On Mon, 2010-09-20 at 12:04 +0200, Jan Kratochvil wrote:
> On Fri, 17 Sep 2010 21:55:56 +0200, Paul Bolle wrote:
> > 1) I drafted a patch (pasted below this message) that works around this
> > limitation:
> >
> > (gdb) ptype wchar_t
> > type = long int
> > (gdb) ptype wchar_t *
> > type = long int *
>
> What is the goal of this patch? strip_typedefs I understand to be the Python
> interface to check_typedef.
Basically I tried to emulate the current behavior of the ptype command,
which goes past pointers to look whether their target is typedef'd too
(see the second example above). Daniel explained that this seems to be a
bug in the ptype command.
> The strip_typedefs description should be fixed anyway as the text is now
> ambiguous.
Do you mean that the current text is ambiguous? In the commit message of
my draft patch I noted that strip_typedefs() "doesn't really behave as
advertised (well, as I understand the advertisement)". I understood that
text to mean that behavior similar to that of the ptype command was
intended.
Paul Bolle
next prev parent reply other threads:[~2010-09-20 11:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-18 14:12 Paul Bolle
2010-09-19 16:35 ` Joel Brobecker
2010-09-19 17:56 ` Paul Bolle
2010-09-20 9:32 ` Daniel Jacobowitz
2010-09-20 9:48 ` Paul Bolle
2010-09-20 10:04 ` Daniel Jacobowitz
2010-09-20 10:15 ` Phil Muldoon
2010-09-20 10:53 ` Paul Bolle
2010-09-20 12:02 ` Jan Kratochvil
2010-09-20 16:25 ` Paul Bolle [this message]
2010-09-20 13:59 ` Paul Bolle
2010-09-20 16:08 ` Paul Bolle
2010-09-21 12:39 ` Jan Kratochvil
2010-09-20 13:14 ` André Pönitz
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=1284979636.1857.47.camel@localhost.localdomain \
--to=pebolle@tiscali.nl \
--cc=dan@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/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