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

I am not sure this is the best group, but it might be close enough. In our current project we use PSoC controllers from Cypress and we access our application by reading and writing variables (by address). To do so we parse the map file on the host to figure out the address of a variable and then send the address to the PSoC.

Over time our host code (in Python) became more complex and would like to access some information that is in preprocessor definitions on the target. But how do I get gcc to report the value of a preprocessor definition in the map file. I do not care how the output looks like, I can adapt my map file parser.

For instance, I would like the date and time (which are available in the preprocessor as __DATE__ and __TIME__ in the map file. When we use PSoC 3 we use the Keil compiler and it has a date/time stamp. Of course we could get the file creation date if we make sure it is maintained when copying/emailing/version-controlling the file. But there is other information, e.g. assignment of resources by the Cypress fitter.


Reply to
Loading thread data ...

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


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.


Tauno Voipio
Reply to
Tauno Voipio

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.

Reply to
Hans-Bernhard Bröker

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.

Reply to
David Brown

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.)


Reply to
Wouter van Ooijen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.