How To Write A Program To Convert Structure Member Offsets?

[Randy Yates]

Hi,

I work in an embedded environment in which we often use a mix of C and
assembly code. Thus a recurring requirement is to be able to take a C
header file with structure definitions as input and create an assembly
include file with the structure member offsets defined.

The problem is that the structure offsets are [potentially] a
complicated function of other syntactic elements such as other
structures (I could have a structure as a member of another
structure), #defines (e.g., for array sizes), etc. Does anyone know of
a good way or good program to determine these offsets?
--
Randy Yates
Sony Ericsson Mobile Communications
Research Triangle Park, NC, USA
ra*********@sonyericsson.com, 919-472-1124

[Gordon Burditt]

>I work in an embedded environment in which we often use a mix of C and

assembly code. Thus a recurring requirement is to be able to take a C
header file with structure definitions as input and create an assembly
include file with the structure member offsets defined.

The problem is that the structure offsets are [potentially] a
complicated function of other syntactic elements such as other
structures (I could have a structure as a member of another
structure), #defines (e.g., for array sizes), etc. Does anyone know of
a good way or good program to determine these offsets?

Can you parse a structure definition to get the names of all the
members in it?

Write a program to write a program to write the assembly-language
include file.

The first program parses the structure definition and makes a table
of the member name and the offset (using offsetof()), along with
any necessary code.

The second program (which includes the C header file and the table)
you compile and run, and the compiler (same one you use for compiling
the stuff that uses the C header) fills in all the offsetof() stuff.
Knowing the offsets, it spits out an assembly-language include file
with the right stuff in it.

Gordon L. Burditt

[Randy Yates]

go***********@burditt.org (Gordon Burditt) writes:

I work in an embedded environment in which we often use a mix of C and
assembly code. Thus a recurring requirement is to be able to take a C
header file with structure definitions as input and create an assembly
include file with the structure member offsets defined.

The problem is that the structure offsets are [potentially] a
complicated function of other syntactic elements such as other
structures (I could have a structure as a member of another
structure), #defines (e.g., for array sizes), etc. Does anyone know of
a good way or good program to determine these offsets?

Can you parse a structure definition to get the names of all the
members in it?

Write a program to write a program to write the assembly-language
include file.

The first program parses the structure definition and makes a table
of the member name and the offset (using offsetof()), along with
any necessary code.

The second program (which includes the C header file and the table)
you compile and run, and the compiler (same one you use for compiling
the stuff that uses the C header) fills in all the offsetof() stuff.
Knowing the offsets, it spits out an assembly-language include file
with the right stuff in it.

Yes, great idea Gordon. I actually thought of this but since the target
code is not native (i.e., it's cross-compiled) I didn't see an immediate
way to run it, but on second thought I think I can run it in the simulator.
(FYI, this is a CEVA Teak DSP.) Thanks for getting me through my mental
block!
--
% Randy Yates % "Bird, on the wing,
%% Fuquay-Varina, NC % goes floating by
%%% 919-577-9882 % but there's a teardrop in his eye..."
%%%% <ya***@ieee.org> % 'One Summer Dream', *Face The Music*, ELO
http://home.earthlink.net/~yatescr

[SM Ryan]

# I work in an embedded environment in which we often use a mix of C and
# assembly code. Thus a recurring requirement is to be able to take a C
# header file with structure definitions as input and create an assembly
# include file with the structure member offsets defined.

One possibility is don't use an explicit struct. Use #defines that expand into
the struct perhaps like

struct-defines.h:
#undef STRUCTanon
#undef STRUCTname
#undef FIELD
#undef FIELDwidth
#undef andFIELD

#define STRUCTanon(fields) struct {fields};
#define STRUCTname(name,fields) struct name {fields};
#define FIELD(type,name) type name;
#define FIELDwidth(name,width) int name: width;
#define andFIELD

list-struct.h
STRUCTname(List,
FIELD(struct List*,link)
andFIELD
FIELD(int,payload)
)

list.h
#include "struct-defines.h"
#include "list-struct.h"

You can create alternative defines in other header files. By including the
something-else-defines.h and then list-struct.h, you can have structure expand
into something quite different; perhaps a size of, or a function to serialise
or unserialise the struct; perhaps they become assembly statements.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
You face forward, or you face the possibility of shock and damage.

[Chris Croughton]

On 13 May 2005 18:16:25 -0400, Randy Yates
<ra*********@sonyericsson.com> wrote:

I work in an embedded environment in which we often use a mix of C and
assembly code. Thus a recurring requirement is to be able to take a C
header file with structure definitions as input and create an assembly
include file with the structure member offsets defined.

The problem is that the structure offsets are [potentially] a
complicated function of other syntactic elements such as other
structures (I could have a structure as a member of another
structure), #defines (e.g., for array sizes), etc. Does anyone know of
a good way or good program to determine these offsets?

Your compiler <g>. Seriously, the only thing which knows about how the
structures are laid out in memory is your compiler. If you are lucky,
in debug mode it might actually put that information into the object
file (so that a debugger can allow you to access fields in the
structure); if you're even luckier the object file format might be
documented well enough to allow you to extract the information, and even
have a utility which will do so as text (objdump will do it for ELF
files, as used by gcc).

Otherwise:

You could write a program which parses the heaer files and writes source
to print offsetof for each field in the structure, then compile that
program and use the results. But you'd need to run that program on the
target...

Otherwise:

You could write a utility which does a parse (i.e. a chunk of a C
compiler) and builds the structures, then (using rules you give it, like
"int is 4 bytes aligned on a 2 byte boundary") produces the assembler.
I'd feed the headers through the preprocessor first so you get rid of
all the macros, includes and conditionals and don't have to process
those. At least one company I know uses that method (they have
different 'rules' for each compiler and target), but I'm not allowed to
name them and the code is proprietary. If I were between jobs I'd offer
to write it under contract, it's the sort of thing I've written before,
but unfortunately I don't have time right now...

Chris C

[CBFalconer]

Chris Croughton wrote:

.... snip ...
You could write a program which parses the heaer files and writes
source to print offsetof for each field in the structure, then
compile that program and use the results. But you'd need to run
that program on the target...

Otherwise:

You could write a utility which does a parse (i.e. a chunk of a C
compiler) and builds the structures, then (using rules you give
it, like "int is 4 bytes aligned on a 2 byte boundary") produces
the assembler. I'd feed the headers through the preprocessor
first so you get rid of all the macros, includes and conditionals
and don't have to process those. At least one company I know
uses that method (they have different 'rules' for each compiler
and target), but I'm not allowed to name them and the code is
proprietary. If I were between jobs I'd offer to write it under
contract, it's the sort of thing I've written before, but
unfortunately I don't have time right now...

You can see an example of this sort of thing in the extension and
debugging provisions of my nmalloc package for DJGPP. The internal
structure of the memory arena is private, and can be freely altered
in the package. However a defined type contains the offsets of
various fields, and is returned as a structure by a function call
(the function and structure type are in the implementation
namespace). Using this the debuggery can adapt itself to the
actual malloc package. This makes the whole thing fairly
portable. See:

<http://cbfalconer.home.att.net/download/nmalloc.zip>

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[Christian Bau]

In article <xx*************@usrts005.corpusers.net>,
Randy Yates <ra*********@sonyericsson.com> wrote:

Hi,

I work in an embedded environment in which we often use a mix of C and
assembly code. Thus a recurring requirement is to be able to take a C
header file with structure definitions as input and create an assembly
include file with the structure member offsets defined.

The problem is that the structure offsets are [potentially] a
complicated function of other syntactic elements such as other
structures (I could have a structure as a member of another
structure), #defines (e.g., for array sizes), etc. Does anyone know of
a good way or good program to determine these offsets?

Lots of printf statements? Recompile and run the program for each
architecture.

[Chris Croughton]

On Sat, 14 May 2005 16:22:41 GMT, CBFalconer
<cb********@yahoo.com> wrote:

Using this the debuggery

Freudian slip, typo or intentional? Just curious, I often refer to
"debuggering" programs that someone else has 'buggered' (i.e. put bugs
in through the back door -- without going through change control)...

Chris C