Reply by Wouter van Ooijen●February 10, 20152015-02-10
acd schreef op 09-Feb-15 om 3:27 PM:
> 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.
>
> Andreas
>
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
Reply by David Brown●February 10, 20152015-02-10
On 09/02/15 15:27, acd wrote:
> 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.
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.
>
> 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.
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.
>
> 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.
>
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 by ●February 9, 20152015-02-09
Am 09.02.2015 um 15:27 schrieb acd:
> But how do I get gcc to report the value of a preprocessor definition
> in the map file.
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 by Tauno Voipio●February 9, 20152015-02-09
On 9.2.15 16:27, acd wrote:
> 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.
>
> Andreas
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.
--
Tauno Voipio
Reply by acd●February 9, 20152015-02-09
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.
Andreas