Here's what I'm trying to do. I have a program that needs to have a data area as part of the actual program file (what would be the .exe file in windows). That data area needs to be a) accessible from within the program itself and b) modified by another program. The second program will NOT modify the data area while the first program is running. My question is simple - how to do this? I would hope to find a solution where the data area is "created" with default values as part of the compile / link process.

Think of it this way. There is program A. A runs in a default mode for most installations. There are a few installations that will run differently if the data is not the default. For version control reasons, the same copy of A is copied onto all installations. Program B runs just once when the system is installed and modifies the data area of A's file on disk for those few installations that get to run differently.

The windows version of this program stores the data area in a RCDATA section in the program's resource area, where both programs can get to it using the XxxResources API calls.

Version control is just one of multiple reasons for the "integrated" data area. These reason are not negotiable. Please don't give possibilities that involve a separate data file. This requirement cannot be changed.

Target Platform - Ubuntu Feisty
Language - C / C++

Thanks,
Judy

I strongly doubt this, but I will appease the request .

Under normal circumstances, global variables in C (even those with file scope) and function variables declared with static are put in the .data section the executable unless they are uninitialized (if they are uninitialized, they are put in the .bss section. The problem is that once program execution begins, it is not necessarily true that changes to the file will reflect changes in the program image. So this gives you some place within a file to store the data, but you should not use the symbol(s) there from within your program (since the changes will not be written to the file after exiting).

So in order to account for this, you need to have some way of finding your static variable data in an open file descriptor of the executable from within the program. Obviously, this depends on the executable format (of which linux supports a few). I will assume that you are dealing with ELF files in particular. In this case, you might use libelf or libbfd to find the offset and size of a symbol in the file. Once you find this information, you could mmap it to a struct or something (in both programs, using MAP_SHARED).

You can use file locking to ensure that the two processes don’t open the same file for reading and writing at the same time.

You don't know the person this came from. Trust me on this - the requirement isn't changing.

I'm thinking I didn't explain this well. You warn about changes to the file not affecting a running program and having to do some locking to prevent both programs from modifying the file at the same time.

This will not happen. The "real" program A will never be running when the "modifying" program B is running. A is placed (i.e. copied) onto the hard drive of a system. In a very few cases, B is now run on the system and should modify a data area in A's disk file. Some time later, when the system is actually in use, A is executed and needs to access the data contained in the data area. A's actions will depend on whether the data is the default data that was originally placed in the data area when A was compiled / linked or if it is the new data. A will never modify this data.

Your idea of finding the .data segment is one I will investigate . If program B can find it and change the locations within the file, this should work. A will execute and "poof" ... the data is there in the global var defined in the .data seg.

Thanks!!
Judy

Well, that greatly simplifies things from how I read it before (the idea now seems a lot less harebrained). You no longer need to indirectly access the symbols in program A through mmaping, you can use them directly as variables.

Also, let me clarify something from my other post: from the ELF headers, you should be able to find the offset of a symbol in the .data section. The size of your data (whatever it happens to be) should be known by program B ahead of time. My advice is to use a struct, and give explicit alignment directives to gcc to control the size yourself. You can always use the result of a sizeof from program A as the actual size as well.