Autogenerated gotcha_map_unifycr_list.h breaks build after adding new wrapper

[CamStan]

Describe the problem you're observing

After adding a new wrapper, there appears to be a Python script in client/check_fns that can/should be used to autogenerate client/src/gotcha_map_unifycr_list.h in order to help streamline the process and ensure GOTCHA finds all wrapped functions.

https://github.com/LLNL/UnifyCR/blob/c73a77b37c520a905b003983fef92b686468ec82/client/src/gotcha_map_unifycr_list.h#L1

This script is meant to go through all the .c files in client/src and grab all the wrapper signatures declared with UNIFYCR_WRAP. It then generates gotcha_map_unifycr_list.h by creating the UNIFYCR_DEF and adding the gotcha_binding to the struct gotcha_binding_t wrap_unifycr_list[] for each wrapper.

Either our code base has changed since this script was last used, or this is still a WIP as the autogenerated version of gotcha_map_unifycr_list.h has a couple subtle changes in it, causing the build to fail.

Describe how to reproduce the problem

The steps taken can be found in client/check_fns/README.md, but it seems to be out of date in parts.

1. Each _wrap signature in the client/src/*.c files needs to be on one line or the grep in step 2 needs to be adjusted. 1a. For example, the grep in step 2 only grabbed line 987 here:

https://github.com/LLNL/UnifyCR/blob/c73a77b37c520a905b003983fef92b686468ec82/client/src/unifycr-sysio.c#L987-L988

2. Run the command grep -h UNIFYCR_WRAP ../src/*.c > unifycr_list.txt to generate unifycr_list.txt for the python script. 2a. The -h option isn't in the README.md but running without it ended up pre-appending the file names. 2b. Lines such as ret = UNIFYCR_WRAP(vfprintf)(stream, format, args); were captured by this grep as well. Had to manually remove them to get the script to work.

3. Run the command python unifycr_translate.py unifycr_list to generate gotcha_map_unifycr_list.h.

4. Then cp the new gotcha_map_unifycr_list.h to client/src to replace the old one.

Ran into this when working on #169 and since the build failed after following this process, the appropriate lines had to be added to gotcha_map_unifycr_list.h manually.

Include any warning or errors or releveant debugging data

In attempting to build, errors similar to the following were produced:

In file included from ../../../client/src/unifycr.c(59):
../../../client/src/gotcha_map_unifycr_list.h(1): error: declaration is incompatible with "FILE *(*__real_fopen)(const char *, const char *)" (declared at line 52 of "../../../client/src/unifycr-stdio.h")
  UNIFYCR_DEF(fopen, FILE, (const char *path, const char *mode));

These errors appear to have occurred for two reasons:

1. A _wrap signature was on two lines and was truncated by the grep.

or

2. The grep appears to have altered the formatting of pointers, i.e.,

FILE* UNIFYCR_WRAP(fopen)(const char *path, const char *mode) became FILE *UNIFYCR_WRAP(fopen)(const char *path, const char *mode).

This resulted in the unifycr_translate.py script interpreting them differently and thus,

UNIFYCR_DEF(fopen, FILE *, (const char *path, const char *mode)); became UNIFYCR_DEF(fopen, FILE, (const char *path, const char *mode));.

To fix this (and the issues in step 2 of reproducing the problem), two potential options could be to write a more complicated grep and/or to update the unifycr_translate.py script to accommodate for these cases.

Note: This might change significantly when we switch to the latest version of GOTCHA (#151).

Note: This issue involves the same topic as enhancement #70.

[dsikich]

@CamStan I want to comment on the python script that generates client/src/gotcha_map_unifycr_list.h. I modified that python script to generate that file because when I added our support for Gotcha there were 45+ wrappers that needed to be added to the header file (which included a function prototype and adding to the iofuncs gotcha struct for each wrapper added). Therefore, it is not necessary to run this script to add a new wrapper. You can manually just add the wrapper to the header file directly (client/src/gotcha_map_unifycr_list.h.). If you are only adding one or two wrappers this will simplify the process greatly.

[CamStan]

I agree. This process is probably not necessary as it might overcomplicate the process of adding one wrapper. A script like this could serve as a nice check though that makes sure we've added all our wrappers to gotcha.

I believe you mentioned adding debugging checks to check what gotcha is using as another solution.

Once a procedure for adding wrappers is established, it should be then reflected in our wrapper guide.

[adammoody]

I think the wrapper names for the non-gotcha case also requires the symbol name to be added to the configure.ac file:

https://github.com/LLNL/UnifyCR/blob/f951e13a2446f04db6b5349a49e51e3123594b5b/configure.ac#L156

[dsikich]

@adammoody @CamStan Yeah, there are really two distinct phases to adding the wrapper. There is adding it to UnifyCR, and if you plan to use Gotcha you have to add it through their API as well ( client/src/gotcha_map_unifycr_list.h).