makefile - How to Link to a stubbed function

[XtremeCold]

Hi all,
I am developing the Test Engine for an aviation application.

The application has a file a.c that is calling an external function CREATE_SAMPLING_PORT().
My Test Engine has a file b.c that is calling CREATE_SAMPLING_PORT() as well.

Each file is in different folder and has its own makefile. This CREATE_SAMPLING_PORT() is defined in the target library.

The problem is that I want to stub CREATE_SAMPLING_PORT() so that only a.c will call my function, STUB_CREATE_SAMPLING_PORT(), instead of the original function. b.c should call the original function CREATE_SAMPLING_PORT().

Is this possible to somehow link CREATE_SAMPLING_PORT() in a.c to my function? If not, is there a solution?

[gerard4143]

Huh? Is this supposed to make sense?

Also, why are you using caps for your function? Is it a macro?

[XtremeCold]

Well, it is because I want to test the application in my test environment and CREATE_SAMPLING_PORT() is a function of the hardware target.

It is caps because it is an API function.

This seems to be a tough problem as the other engineers in my company gave up.

[nezachem]

I don't think the link time solution is simple (if possible at all, depending of your build process). On the other hand, adding

static inline CREATE_SAMPLING_PORT()
{
    STUB_CREATE_SAMPLING_PORT()
}

to your a.c will do what you want.

[XtremeCold]

The problem is that I must not modify the application code (a.c) when I do black-box testing. This rule is required for all testing of avionics application. This is the Power Communication System for the B787.

So the wrapper you suggested is not allowed.

I am able to see the address of that API in the library's object file. So I was thinking about hard-coding that function address to my (b.c). However, when we compile it, the dynamic linker will load the function to the memory of the hosted app, which means the address will not be constant if we make any change to the code.

Btw, I appreciate your effort in helping people.

[nezachem]

In that case I need more details on your link process and the build environment. In any case, the idea is to undefine the symbol after it had been resolved for a.o object. If you are using gcc, the following link line may help:

gcc a.o stub.o -u _CREATE_SAMPLING_PORT b.o ...

where stub.c contains your stub implementation; make sure the stub function is called CREATE_SAMPLING_PORT (without the STUB_ prefix). You have to force this particular order of files and options in the link command line.

[XtremeCold]

Thanks nezachem.

Your ideas all make sense. It turns out that the makefile in the application is much more complicated than I thought. All the c files are compiled to *.o file, then linked to an executable. This executable will then be linked with the library to become an image to load into the hardware target.
Thus the environment requires that there must be no functions with the same name even though they are defined in 2 separate files.
I guess this is not possible.