6

Is there a way with gcc and GNU binutils to mark some functions such that they will generate an error at link-time if used? My situation is that I have some library functions which I am not removing for the sake of compatibility with existing binaries, but I want to ensure that no newly-compiled binary tries to make use of the functions. I can't just use compile-time gcc attributes because the offending code is ignoring my headers and detecting the presence of the functions with a configure script and prototyping them itself. My goal is to generate a link-time error for the bad configure scripts so that they stop detecting the existence of the functions.

Edit: An idea.. would using assembly to specify the wrong .type for the entry points be compatible with the dynamic linker but generate link errors when trying to link new programs?

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711

3 Answers3

2

FreeBSD 9.x does something very close to what you want with the ttyslot() function. This function is meaningless with utmpx. The trick is that there are only non-default versions of this symbol. Therefore, ld will not find it, but rtld will find the versioned definition when an old binary is run. I don't know what happens if an old binary has an unversioned reference, but it is probably sensible if there is only one definition.

For example,

__asm__(".symver hidden_badfunc, badfunc@MYLIB_1.0");

Normally, there would also be a default version, like

__asm__(".symver new_badfunc, badfunc@@MYLIB_1.1");

or via a Solaris-compatible version script, but the trick is not to add one.

Typically, the asm directive is wrapped into a macro.

The trick depends on the GNU extensions to define symbol versions with the .symver assembler directive, so it will probably only work on Linux and FreeBSD. The Solaris-compatible version scripts can only express one definition per symbol.

More information: .symver directive in info gas, Ulrich Drepper's "How to write shared libraries", the commit that deprecated ttyslot() at http://gitorious.org/freebsd/freebsd/commit/3f59ed0d571ac62355fc2bde3edbfe9a4e722845

jilles
  • 10,509
  • 2
  • 26
  • 39
0

The best way to generate a link-time error for deprecated functions that you do not want people to use is to make sure the deprecated functions are not present in the libraries - which makes them one stage beyond 'deprecated'.

Maybe you can provide an auxilliary library with the deprecated function in it; the reprobates who won't pay attention can link with the auxilliary library, but people in the mainstream won't use the auxilliary library and therefore won't use the functions. However, it is still taking it beyond the 'deprecated' stage.

Getting a link-time warning is tricky. Clearly, GCC does that for some function (mktemp() et al), and Apple has GCC warn if you run a program that uses gets(). I don't know what they do to make that happen.

In the light of the comments, I think you need to head the problem off at compile time, rather than waiting until link time or run time.

The GCC attributes include (from the GCC 4.4.1 manual):

error ("message")

If this attribute is used on a function declaration and a call to such a function is not eliminated through dead code elimination or other optimizations, an error which will include message will be diagnosed. This is useful for compile time checking, especially together with __builtin_constant_p and inline functions where checking the inline function arguments is not possible through extern char [(condition) ? 1 : -1]; tricks. While it is possible to leave the function undefined and thus invoke a link failure, when using this attribute the problem will be diagnosed earlier and with exact location of the call even in presence of inline functions or when not emitting debugging information.

warning ("message")

If this attribute is used on a function declaration and a call to such a function is not eliminated through dead code elimination or other optimizations, a warning which will include message will be diagnosed. This is useful for compile time checking, especially together with __builtin_constant_p and inline functions. While it is possible to define the function with a message in .gnu.warning* section, when using this attribute the problem will be diagnosed earlier and with exact location of the call even in presence of inline functions or when not emitting debugging information.

If the configuration programs ignore the errors, they're simply broken. This means that new code could not be compiled using the functions, but the existing code can continue to use the deprecated functions in the libraries (up until it needs to be recompiled).

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • The warnings can be done with the `.gnu.warning` note, but I don't know an equivalent for generating errors. Unfortunately, while your solution is the best, it doesn't meet my needs of matching both a deprecated ABI and linking new applications. – R.. GitHub STOP HELPING ICE Jan 14 '11 at 20:09
  • @R..: Fair enough. Is it fair to say that you want one copy of the libraries installed; you want pre-compiled apps (which may be using the deprecated interface) to continue to run; you want newly compiled apps that use the deprecated interface to fail to link? If so, and if the configuration-detectors will spot the deprecated functions, how do you plan to have people fix things so that the code ends up linking with the modern (non-deprecated) interfaces? – Jonathan Leffler Jan 14 '11 at 20:15
  • There is no new replacement interface; trying to use these deprecated interfaces is just harmful, and the correct behavior is not to use them at all. Unfortunately I don't have control over the broken software that's trying to use them, and while I could probably get the maintainers to fix new versions, users might still be trying to compile old versions for a good while. – R.. GitHub STOP HELPING ICE Jan 14 '11 at 20:29
0

One idea could be to generate a stub library that has these symbols but with unexpected properties.

  • perhaps create objects that have the name of the functions, so the linker in the configuration phase might complain that the symbols are not compatible
  • create functions that have a dependency "dont_use_symbol_XXX" that is never resolved
  • or fake a .a file with a global index that would have your functions but where the .o members in the archive have the wrong format
Jens Gustedt
  • 76,821
  • 6
  • 102
  • 177