GCC: how to a pre-processor definition into the map file

What you have in the map file are in principle absolute memory addresses.

I could dream of an assembler module with pre-processing (.S file, note capital S). To be transferable, you need to encode the data into 32 bits (assuming a 32 bit linker). I'm using this technique to send the I/O base addresses of ARM processors to the linker, actually not for the map, but for GDB.

Something like this, defines.S:

#define MY_DEFINE 0x12345678

.globl my_define

my_define = MY_DEFINE

.end

Feed it into the GCC compile, the gcc driver knows to ship it to the assembler after pre-processing, and feed the resulting object file to the linker together with the other modules.

Am 09.02.2015 um 15:27 schrieb acd:

You don't. Sorry.

Those #defined numbers don't even make it past the preprocessing stage. There's simply no way they can show up again in the linker output. The map holds information about what named object is where in memory. But a preprocessor constant _is_ in no particular place in memory. You might as well ask for the map file to tell you where every use of the integer 4231 in your final executable is.

The last file along the processing chain that information can possibly be in is (the debug information section of) the ELF file. And even that's a rather slim chance.

So if you want that information visible in the map, you'll have to get the compiler to store it at an actual address. Suffice it to say that's a seriously cumbersome and wasteful approach.

So my advice to you is: forget about this. Find other ways to organize your "peek-into-the-running-program" thingy.

Such direct addressing often sounds nice at the start of a project - as things progress, you realise how terrible a plan it was. The sooner you change this, the better. (I could go into reasons why direct access to internal data variables is a bad idea, but I'm sure you can think of enough reasons yourself.)

Also, you are thinking about this backwards. Don't use Python to interpret files from the compiler - use Python to generate files /for/ the compiler.

How about this for a plan:

Create a text file containing a list of the data you are interested in, including types, names, size of array, comments, etc. It should also contain a version number, date, etc.

Write a Python script that parses this file and creates a C header file defining a struct with the data and #define's for version numbers, etc., and a Python file containing a list (or class, or whatever) of the data items and their offsets in the struct.

The C code includes that header file, the Python code uses the Python module. All access to data on the board is done through that struct using offsets instead of absolute addresses.

The way to do this, I think, would be to make extern variables with names generated from the macros - then look at the variable names in the map file. But as noted above, I wouldn't do it that way.

The __DATE__ and __TIME__ macros are evil - don't use them. You want to be able to generate /exactly/ the same binary from the same source code, regardless of the time of compilation and the computer used to compile it. Put your version numbers explicitly in a source file, and update them when the version changes.

acd schreef op 09-Feb-15 om 3:27 PM:

The map file data are all addresses, so you can't easily get something more complicated like a string from a MAP file.

But why the trouble? If you want __DATE__ and __TIME__, just write as small application that runs on your host and prints the __DATE__ and __TIME__. (Note that __TIME__ is 'fixed' at compilation, so might not be the same for all compilation units in your application.)

Wouter