* Proposal: offset based member name (or type) lookup
@ 2004-01-04 17:09 Christoph Jaeschke
2004-01-04 17:25 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Christoph Jaeschke @ 2004-01-04 17:09 UTC (permalink / raw)
To: gdb
Hi,
I would like to propose a offset based member name lookup of
structs/classes. Assume:
struct X {
int a;
int b;
};
struct Y {
struct X x[4];
int c;
};
struct Z {
Y y;
};
If you apply a patch for gdb 6.0 I've prepared, you can ask gdb by
ptype Z + 28
about Z's relative name at offset 28
.y.x[3].b
using
ptype Z+28, typechain
gdb will append also the typechain
.y.x[3].b, typechain = ::Y::X[4]::int
There may be a better suited command than 'ptype' for it, it was choosen
just because it was the simplest way to add it.
The patch contains also a caching mechanism, speeding up a lot if you do
many lookups in big nested structures. It has a minimal memory
requirement and will not hurt for single lookups.
The patch can be send if you are interested in.
Christoph Jaeschke
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Proposal: offset based member name (or type) lookup
2004-01-04 17:09 Proposal: offset based member name (or type) lookup Christoph Jaeschke
@ 2004-01-04 17:25 ` Daniel Jacobowitz
2004-01-04 17:30 ` Daniel Jacobowitz
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Jacobowitz @ 2004-01-04 17:25 UTC (permalink / raw)
To: gdb
On Sun, Jan 04, 2004 at 06:56:05PM +0100, Christoph Jaeschke wrote:
> Hi,
>
> I would like to propose a offset based member name lookup of
> structs/classes. Assume:
>
> struct X {
> int a;
> int b;
> };
>
> struct Y {
> struct X x[4];
> int c;
> };
>
> struct Z {
> Y y;
> };
>
> If you apply a patch for gdb 6.0 I've prepared, you can ask gdb by
>
> ptype Z + 28
>
> about Z's relative name at offset 28
>
> .y.x[3].b
>
> using
>
> ptype Z+28, typechain
>
> gdb will append also the typechain
>
> .y.x[3].b, typechain = ::Y::X[4]::int
>
>
> There may be a better suited command than 'ptype' for it, it was choosen
> just because it was the simplest way to add it.
>
> The patch contains also a caching mechanism, speeding up a lot if you do
> many lookups in big nested structures. It has a minimal memory
> requirement and will not hurt for single lookups.
>
> The patch can be send if you are interested in.
Well, I don't like the syntax, but I think this is a wonderful idea.
The other feature I've been meaning to add since forever is a variant
of ptype which shows byte offsets for every field.
The problem with using ptype is that "Z+28" already has a meaning; gdb
will try to add the two, or call an overloaded + operator in C++, et
cetera. This should probably be a new command; that'll be more useful
for MI anyway.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Proposal: offset based member name (or type) lookup
2004-01-04 17:25 ` Daniel Jacobowitz
@ 2004-01-04 17:30 ` Daniel Jacobowitz
2004-01-04 19:10 ` Christoph Jaeschke
2004-01-08 1:28 ` Andrew Cagney
0 siblings, 2 replies; 6+ messages in thread
From: Daniel Jacobowitz @ 2004-01-04 17:30 UTC (permalink / raw)
To: gdb, Christoph Jaeschke
On Sun, Jan 04, 2004 at 12:25:37PM -0500, Daniel Jacobowitz wrote:
> On Sun, Jan 04, 2004 at 06:56:05PM +0100, Christoph Jaeschke wrote:
> > Hi,
> >
> > I would like to propose a offset based member name lookup of
> > structs/classes. Assume:
> >
> > struct X {
> > int a;
> > int b;
> > };
> >
> > struct Y {
> > struct X x[4];
> > int c;
> > };
> >
> > struct Z {
> > Y y;
> > };
> >
> > If you apply a patch for gdb 6.0 I've prepared, you can ask gdb by
> >
> > ptype Z + 28
> >
> > about Z's relative name at offset 28
> >
> > .y.x[3].b
> >
> > using
> >
> > ptype Z+28, typechain
> >
> > gdb will append also the typechain
> >
> > .y.x[3].b, typechain = ::Y::X[4]::int
> >
> >
> > There may be a better suited command than 'ptype' for it, it was choosen
> > just because it was the simplest way to add it.
> >
> > The patch contains also a caching mechanism, speeding up a lot if you do
> > many lookups in big nested structures. It has a minimal memory
> > requirement and will not hurt for single lookups.
> >
> > The patch can be send if you are interested in.
>
> Well, I don't like the syntax, but I think this is a wonderful idea.
> The other feature I've been meaning to add since forever is a variant
> of ptype which shows byte offsets for every field.
>
> The problem with using ptype is that "Z+28" already has a meaning; gdb
> will try to add the two, or call an overloaded + operator in C++, et
> cetera. This should probably be a new command; that'll be more useful
> for MI anyway.
Oh, and I forgot the obligatory followup to this: if you are
interested in contributing this patch, and I hope you are, then please
file an FSF copyright assignment. Jim or Andrew can send you the
appropriate forms to get the process started.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Proposal: offset based member name (or type) lookup
2004-01-04 17:30 ` Daniel Jacobowitz
@ 2004-01-04 19:10 ` Christoph Jaeschke
2004-01-08 1:28 ` Andrew Cagney
1 sibling, 0 replies; 6+ messages in thread
From: Christoph Jaeschke @ 2004-01-04 19:10 UTC (permalink / raw)
To: Daniel Jacobowitz, gdb
Daniel Jacobowitz wrote:
> On Sun, Jan 04, 2004 at 12:25:37PM -0500, Daniel Jacobowitz wrote:
>
>>On Sun, Jan 04, 2004 at 06:56:05PM +0100, Christoph Jaeschke wrote:
>>
>>>Hi,
>>>
>>>I would like to propose a offset based member name lookup of
>>>structs/classes. Assume:
>>>
>>> struct X {
>>> int a;
>>> int b;
>>> };
>>>
>>> struct Y {
>>> struct X x[4];
>>> int c;
>>> };
>>>
>>> struct Z {
>>> Y y;
>>> };
>>>
>>>If you apply a patch for gdb 6.0 I've prepared, you can ask gdb by
>>>
>>> ptype Z + 28
>>>
>>>about Z's relative name at offset 28
>>>
>>> .y.x[3].b
>>>
>>>using
>>>
>>> ptype Z+28, typechain
>>>
>>>gdb will append also the typechain
>>>
>>> .y.x[3].b, typechain = ::Y::X[4]::int
>>>
>>>
>>>There may be a better suited command than 'ptype' for it, it was choosen
>>>just because it was the simplest way to add it.
>>>
>>>The patch contains also a caching mechanism, speeding up a lot if you do
>>>many lookups in big nested structures. It has a minimal memory
>>>requirement and will not hurt for single lookups.
>>>
>>>The patch can be send if you are interested in.
>>
>>Well, I don't like the syntax, but I think this is a wonderful idea.
>>The other feature I've been meaning to add since forever is a variant
>>of ptype which shows byte offsets for every field.
>>
>>The problem with using ptype is that "Z+28" already has a meaning; gdb
>>will try to add the two, or call an overloaded + operator in C++, et
>>cetera. This should probably be a new command; that'll be more useful
>>for MI anyway.
>
>
> Oh, and I forgot the obligatory followup to this: if you are
> interested in contributing this patch, and I hope you are, then please
> file an FSF copyright assignment. Jim or Andrew can send you the
> appropriate forms to get the process started.
>
Sure, I'm interested in contributing. But, because I'm not very familiar
with the command interface (that's why ptype was re-used), I would be
happy if someone else create a new command and just call the processing
func.
If Jim or Andrew send me the forms, you will get the patch.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Proposal: offset based member name (or type) lookup
2004-01-04 17:30 ` Daniel Jacobowitz
2004-01-04 19:10 ` Christoph Jaeschke
@ 2004-01-08 1:28 ` Andrew Cagney
1 sibling, 0 replies; 6+ messages in thread
From: Andrew Cagney @ 2004-01-08 1:28 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb, Christoph Jaeschke
>
> Oh, and I forgot the obligatory followup to this: if you are
> interested in contributing this patch, and I hope you are, then please
> file an FSF copyright assignment. Jim or Andrew can send you the
> appropriate forms to get the process started.
I've sent the form.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Proposal: offset based member name (or type) lookup
@ 2004-02-27 21:09 Christoph Jaeschke
0 siblings, 0 replies; 6+ messages in thread
From: Christoph Jaeschke @ 2004-02-27 21:09 UTC (permalink / raw)
To: gdb
On Sun, Jan 04, 2004 at 12:25:37PM -0500, Daniel Jacobowitz wrote:
> On Sun, Jan 04, 2004 at 06:56:05PM +0100, Christoph Jaeschke wrote:
> > Hi,
> >
> > I would like to propose a offset based member name lookup of
> > structs/classes. Assume:
> >
> > struct X {
> > int a;
> > int b;
> > };
> >
> > struct Y {
> > struct X x[4];
> > int c;
> > };
> >
> > struct Z {
> > Y y;
> > };
> >
> > If you apply a patch for gdb 6.0 I've prepared, you can ask gdb by
> >
> > ptype Z + 28
> >
> > about Z's relative name at offset 28
> >
> > .y.x[3].b
> >
> > using
> >
> > ptype Z+28, typechain
> >
> > gdb will append also the typechain
> >
> > .y.x[3].b, typechain = ::Y::X[4]::int
> >
> >
> > There may be a better suited command than 'ptype' for it, it was choosen
> > just because it was the simplest way to add it.
> >
> > The patch contains also a caching mechanism, speeding up a lot if you do
> > many lookups in big nested structures. It has a minimal memory
> > requirement and will not hurt for single lookups.
> >
> > The patch can be send if you are interested in.
>
> Well, I don't like the syntax, but I think this is a wonderful idea.
> The other feature I've been meaning to add since forever is a variant
> of ptype which shows byte offsets for every field.
>
> The problem with using ptype is that "Z+28" already has a meaning; gdb
> will try to add the two, or call an overloaded + operator in C++, et
> cetera. This should probably be a new command; that'll be more useful
> for MI anyway.
I did filed a copyright assignment form now.
The patch can be send, no problem, but perhaps there should be consensus about the user interface.
Should a new command name be created? Is the typechain print ok?
Christoph Jaeschke
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-02-27 21:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-04 17:09 Proposal: offset based member name (or type) lookup Christoph Jaeschke
2004-01-04 17:25 ` Daniel Jacobowitz
2004-01-04 17:30 ` Daniel Jacobowitz
2004-01-04 19:10 ` Christoph Jaeschke
2004-01-08 1:28 ` Andrew Cagney
2004-02-27 21:09 Christoph Jaeschke
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox