q: code that generates printf() statement to dump C struct contents

Hi,

I am sure, others also have had a need for this.
I am examining a C API for the first time, writing small test programs
and dumping the contents of C structs.
What I am looking for is a code fragment or tool that will take a C
struct declaration as input, maybe even complete header files with
typedefs and the like and generates a dump_struct function that takes
a pointer to the actual struct as input and then dumps or displays the
structs' contents via printf(), leaving the comments from the header
file intact.

any hints?
Joachim

generated code would be something like:
void dump_struct_xx( struct xx *p )
{
printf("struct xx {\n\\
int xy=%d; /* comment from the header file */\n\\
}", p->xy );
}

[email]joachim.gann@gmail.com[/email] wrote:[color=blue]
> Hi,
>
> I am sure, others also have had a need for this.
> I am examining a C API for the first time, writing small test programs
> and dumping the contents of C structs.[/color]
[color=blue]
> What I am looking for is a code fragment or tool that will take a C
> struct declaration as input, maybe even complete header files with
> typedefs and the like and generates a dump_struct function that takes
> a pointer to the actual struct as input and then dumps or displays the
> structs' contents via printf(), leaving the comments from the header
> file intact.
>[/color]
Why not just use watch points in your debugger?

--
Ian Collins.

[email]joachim.gann@gmail.com[/email] wrote:[color=blue]
> I am sure, others also have had a need for this.
> I am examining a C API for the first time, writing small test programs
> and dumping the contents of C structs.[/color]

I am not really convinced that it would be very useful (at least I
have never seen a case were I would have needed something like this,
usually looking the values up with a debugger or writing a short
function manually did the trick for me;-).
[color=blue]
> What I am looking for is a code fragment or tool that will take a C
> struct declaration as input, maybe even complete header files with
> typedefs and the like and generates a dump_struct function that takes
> a pointer to the actual struct as input and then dumps or displays the
> structs' contents via printf(), leaving the comments from the header
> file intact.[/color]
[color=blue]
> generated code would be something like:
> void dump_struct_xx( struct xx *p )
> {
> printf("struct xx {\n\\
> int xy=%d; /* comment from the header file */\n\\
> }", p->xy );
> }[/color]

This may look simple on a first look but if you get some more
complicated cases it can get rather ugly. Just a rather simple
construct like

struct {
union { double a;
char b } c;
} d;

is probably going to be something you won't be able to handle
at all since you can't, just by inspecting the source code,
determine what to print for the unions' value - that's some-
thing that is only known at runtime. And even if you disregard
such "pathological" cases you probably will end up having to
write a more or less complete parser for C and then go on from
there...
Regards, Jens
--
\ Jens Thoms Toerring ___ [email]jt@toerring.de[/email]
\__________________________ [url]http://toerring.de[/url]

[email]jt@toerring.de[/email] (Jens Thoms Toerring) writes:[color=blue]
>joachim.gann@gmail.com wrote:[color=green]
>> I am sure, others also have had a need for this.
>> I am examining a C API for the first time, writing small test programs
>> and dumping the contents of C structs.[/color]
>
>I am not really convinced that it would be very useful (at least I
>have never seen a case were I would have needed something like this,
>usually looking the values up with a debugger or writing a short
>function manually did the trick for me;-).
>[color=green]
>> What I am looking for is a code fragment or tool that will take a C
>> struct declaration as input, maybe even complete header files with
>> typedefs and the like and generates a dump_struct function that takes
>> a pointer to the actual struct as input and then dumps or displays the
>> structs' contents via printf(), leaving the comments from the header
>> file intact.[/color]
>[color=green]
>> generated code would be something like:
>> void dump_struct_xx( struct xx *p )
>> {
>> printf("struct xx {\n\\
>> int xy=%d; /* comment from the header file */\n\\
>> }", p->xy );
>> }[/color]
>
>This may look simple on a first look but if you get some more
>complicated cases it can get rather ugly. Just a rather simple
>construct like
>
>struct {
> union { double a;
> char b } c;
>} d;
>
>is probably going to be something you won't be able to handle
>at all since you can't, just by inspecting the source code,
>determine what to print for the unions' value - that's some-
>thing that is only known at runtime. And even if you disregard
>such "pathological" cases you probably will end up having to
>write a more or less complete parser for C and then go on from
>there...[/color]

All the needed information is in the DWARF section of the ELF
codefile, assuming -g was used during compilation and linking.

That said, using DWARF is a pain in the posterior.

As for the union case, one should work from the memory layout back to
to one of the union members remembering that the union members share
the same storage (and again, the DWARF information will help here).

scott

Scott Lurndal <scott@slp53.sl.home> wrote:[color=blue]
> [email]jt@toerring.de[/email] (Jens Thoms Toerring) writes:[color=green]
> >This may look simple on a first look but if you get some more
> >complicated cases it can get rather ugly. Just a rather simple
> >construct like
> >
> >struct {
> > union { double a;
> > char b } c;
> >} d;
> >
> >is probably going to be something you won't be able to handle
> >at all since you can't, just by inspecting the source code,
> >determine what to print for the unions' value - that's some-
> >thing that is only known at runtime. And even if you disregard
> >such "pathological" cases you probably will end up having to
> >write a more or less complete parser for C and then go on from
> >there...[/color][/color]
[color=blue]
> All the needed information is in the DWARF section of the ELF
> codefile, assuming -g was used during compilation and linking.[/color]
[color=blue]
> That said, using DWARF is a pain in the posterior.[/color]
[color=blue]
> As for the union case, one should work from the memory layout back to
> to one of the union members remembering that the union members share
> the same storage (and again, the DWARF information will help here).[/color]

Sorry, but as far as I can see nothing will help you there: you
need to know which of the union members was written to last to
be able to determine what to print out. And that depends on the
control flow of the program, not any static information you can
deduce from the program itself (unless the program doesn't take
any external and thus unpredictable input, and even then it might
be an "interesting" problem;-)

Regards, Jens
--
\ Jens Thoms Toerring ___ [email]jt@toerring.de[/email]
\__________________________ [url]http://toerring.de[/url]

[email]jt@toerring.de[/email] (Jens Thoms Toerring) writes:[color=blue]
>Scott Lurndal <scott@slp53.sl.home> wrote:[color=green]
>> [email]jt@toerring.de[/email] (Jens Thoms Toerring) writes:[color=darkred]
>> >This may look simple on a first look but if you get some more
>> >complicated cases it can get rather ugly. Just a rather simple
>> >construct like
>> >
>> >struct {
>> > union { double a;
>> > char b } c;
>> >} d;
>> >
>> >is probably going to be something you won't be able to handle
>> >at all since you can't, just by inspecting the source code,
>> >determine what to print for the unions' value - that's some-
>> >thing that is only known at runtime. And even if you disregard
>> >such "pathological" cases you probably will end up having to
>> >write a more or less complete parser for C and then go on from
>> >there...[/color][/color]
>[color=green]
>> All the needed information is in the DWARF section of the ELF
>> codefile, assuming -g was used during compilation and linking.[/color]
>[color=green]
>> That said, using DWARF is a pain in the posterior.[/color]
>[color=green]
>> As for the union case, one should work from the memory layout back to
>> to one of the union members remembering that the union members share
>> the same storage (and again, the DWARF information will help here).[/color]
>
>Sorry, but as far as I can see nothing will help you there: you
>need to know which of the union members was written to last to
>be able to determine what to print out. And that depends on the
>control flow of the program, not any static information you can
>deduce from the program itself (unless the program doesn't take
>any external and thus unpredictable input, and even then it might
>be an "interesting" problem;-)[/color]

It really doesn't matter which of the union members was written
to last. The storage is all that matters. pIck one of the members
and display the memory contents for that fundamental type, or just
display the contents of memory unattributed to one of the union
members.

Let the user transform between types if necessary.

scott

Good points, everyone.
I want to go further than running the program in a debugger, but for
example include an "expert view option" into my programs, which in
fact dumps the very source of information, the struct. I did this when
writing a ps(1) replacement for aix. It has an option to dump the
complete struct procinfo that has been of good use to me in some cases
(checking the ulimits of running processes and the like).
As for unions displaying both members seems ok to me. Still there are
other cases that can make it complex (nested structs, pointers,
arrays, bitfields, typedefs)
Anyway, I think of a tool that does a first quick shot in generating
the code, so I can adjust the hairy stuff by hand (say, not displaying
numerical values but decoding numerics into symbolic constants, this
would be hard to automate).

still hoping for someone who has this or has seen this already...

Joachim