Can I link unresolved reference to abort?

Question

I'm trying to write some small tests for a fairly small part of a fairly large project. Attempting to link this beast is unfortunately fairly impossible without linking the entire project together, which I don't want to do (it's a pretty complex system for finding all the dependencies and stuff, and I perfer not to meddle with it).

Now, I know for certain that the functions that the referenced functions won't be called during my test, the just happen to be part of functions which share file with stuff that I do test.

Is there any way to simply link these unresolved references to, let's say, abort, or something? Or is there a tool which creates the appropriate stub object file where all calls result in abort, given the set of object files that I have?

I use gcc (g++) for compiling/linking, version 3.4.4. Platform is unix (solaris/sparc if that's important).

Answer 1

Well one way I can think of is to first compile the .o files for you library.

Then use a tool like nm (common on *nix systems) to get all of the symbols, in nm, all "external" (aka ones which are not found in this .o) are of type U (it may be different for non-GNU versions of nm see your documentation).

If your library is all one source file, then it is simple, pretty much all symbols of type U will be either a function found in another library or will be unresolved at link time. It is slightly more complicated if your library is going to be more than one source file since you will have inter-source file dependencies.

So now you have a a means to create a potential list of unresolved externals, then you can create a "test_stub.c" which has a stub symbols for each one, which you could fill with something like this:

void some_func() { abort(); }

where some_func is a would be unresolved external. Compile and link this with your library and all calls should result in an abort.

Answer 2

Trying to compile the following program

#include <iostream>

extern int bar();

int foo()
{
  return bar() + 3;
}

int main()
{
  std::cout << "Hello, world!" << std::endl;
  // std::cout << foo() << std::endl;

  return 0;
}

results in

$ g++ -o main main.cc
/tmp/ccyvuYPK.o: In function `foo()':
main.cc:(.text+0x5): undefined reference to `bar()'
collect2: ld returned 1 exit status

But we can tell the linker to ignore unresolved symbols and run it just fine:

$ g++ -Wl,--unresolved-symbols=ignore-all -o main main.cc
$ ./main
Hello, world!

Say some unresolved function is called by your test harness (simulate this by uncommenting the call to foo), it will compile and link fine, but you'll get a segfault when you execute the program. Be sure to ulimit -c unlimited so you get a core.

Answer 3

You can just tell linker to ignore unresolved symbols. I couldn't find option that links them to abort or something like that.

The policy to ignore unresolved symbols in object files only is the most natural, I suppose:

gcc -Wl,--unresolved-symbols=ignore-in-object-files  obj.o another.o etc.o

Other options include (quoting man ld):

   --unresolved-symbols=method
       Determine how to handle unresolved symbols.  There are four possi-
       ble values for method:

       ignore-all
           Do not report any unresolved symbols.

       report-all
           Report all unresolved symbols.  This is the default.

       ignore-in-object-files
           Report  unresolved  symbols  that  are  contained  in   shared
           libraries,  but  ignore  them if they come from regular object
           files.

       ignore-in-shared-libs
           Report unresolved symbols that come from regular object files,
           but  ignore them if they come from shared libraries.  This can
           be useful when creating a dynamic binary and it is known  that
           all  the  shared  libraries  that it should be referencing are
           included on the linker's command line.

       The behaviour for shared libraries on their own can also  be  con-
       trolled by the --[no-]allow-shlib-undefined option.

       Normally  the  linker  will  generate  an  error  message for each
       reported unresolved symbol but the  option  --warn-unresolved-sym-
       bols can change this to a warning.

On my Linux system attempts to call the unresolved function result in "Segmentation fault".

Answer 4

Try GCC alias attribute:

/* cannot directly alias to yet undefined symbols,
 * so need an intermediate function.
 */
static void do_abort() { abort(); }

void func0() __attribute__ ((weak, alias ("do_abort")));
void func1() __attribute__ ((weak, alias ("do_abort")));
...