Understanding the classical model for linking: You can override an LIB with another LIB, and a LIB with an OBJ, but you can't override an OBJ

re: Understanding the classical model for linking: You can override an LIB with another LIB, and a LIB with an OBJ, but you can't override an OBJ

Neil — Thu, 10 Jan 2013 10:35:31 GMT

Sorry if I've misremembered this.

In printf.c, declare extern (*printf__fp)();

In fltused.c, define printf__fp.

Then when printf wants to print a floating-point number it just invokes printf__fp and you crash if you didn't trigger the include of the floating-point library.

Better still would be a weak symbol if that's supported.

re: Understanding the classical model for linking: You can override an LIB with another LIB, and a LIB with an OBJ, but you can't override an OBJ

Marcel — Thu, 10 Jan 2013 10:21:06 GMT

Well, in the case of my microcontroller compiler (avrgcc) there is no magic going on, you have to tell the linker explicitly which version you want. The default version doesn't include floating point. If I really want that, I have to include the "printf_flt" library. There's even a third, minimalistic version that supports even less options than the standard one, called printf_min.

re: Understanding the classical model for linking: You can override an LIB with another LIB, and a LIB with an OBJ, but you can't override an OBJ

Matt — Thu, 10 Jan 2013 10:04:51 GMT

///

/// printf.c provides "printf, dummy_printf_do_f_impl, printf_do_f_fp"

///

void dummy_printf_do_f_impl()

{

printf("Uh oh - you used %%f but didn't use the float keyword anywhere!!"); abort();

// alternatively, you could dynamically load the floating point library here, for example to handle the case where the main program's "printf" has been passed a float from a plugin.

}

extern FARPROC printf_do_f_fp = &dummy_printf_do_f_impl;

... printf(...)

{

case "f": printf_do_f_fp();

}

///

/// flt.lib provides __fltused, requires _printf_fp_impl

///

int __fltused;

void* force_load_printf_fp = &actual_printf_do_f_impl;

///

/// printf_fp.c in printf_fp.lib (provides _printf_fp_impl)

///

printf_do_f.c requires __fltused

FARPROC printf_do_f = NULL;

void actual_printf_do_f_impl()

{

printf("Here's your float: ", ...etc...);

}

extern

class InitMagicNumber

{

InitMagicNumber()

{

printf_do_f = &actual_printf_do_f_impl;

}

_printf_fp_impl;

// Now follow through the compilation of main.c (main() { printf("This should return an error: %f"); }

main.c requires printf, provided by printf.lib. printf.lib doesn't require any printf_fp stuff, so that's not loaded. Now when printf is called, it does normal printf behaviour until it hits %f, when it then calls printf_do_f_fp, which is a symbol in printf.lib defined to point to dummy_printf_do_f_impl, which triggers an error.

// Now follow through the compilation of main_fp.c (main() { printf("This should work: %f", 0.0f); }

main_fp.c uses floating point, so automatically requires __fltinit. It calls printf, so we load printf.lib. printf.lib doesn't use printf_fp, so that doesn't automatically trigger a load there, but we're now left with one unresolved symbol: __fltinit. __fltinit is defined in flt.lib, which requires the symbol _printf_fp_impl, defined in printf_fp.lib. This requires the printf_do_f_fp symbol which resolves to the definition in printf.lib. printf_fp.lib also has a "magic" variable and the linker will add its constructor to the list of CRT initialization functions.

Now when main_fp.c runs, the CRT will call all of the constructors in turn, including the InitMagicNumber magic class, which sets printf_do_f (from printf.lib) to point to actual_printf_do_f_impl. The CRT eventually calls main who calls printf, who eventually calls the deref of printf_do_f_fp, which now takes it to actual_printf_do_f_impl.

Result: printf floating point code is only brought along for the ride if you actually use floating point (or are dumb enough to include an extern int __fltused) somewhere in your code. Otherwise, a dummy implementation of printf will handle the case where %f is used on a non-floating-point program, which can either load the expensive fp library, or can explode, or can return "0.0" or whatever.

re: Understanding the classical model for linking: You can override an LIB with another LIB, and a LIB with an OBJ, but you can't override an OBJ

DS — Wed, 09 Jan 2013 23:53:58 GMT

I think I'd go with Peter's approach, as corrected by Raymond (entry point pointing to dummy function and corrected by FP library's init code to point to FP argument handler). Anonymous123's approach would require coding a special case into the compiler (remember, when float or double is used, as it must be to implement %f, the compiler always generates _fltused) or coding %f etc. support in assembler (well, maybe that's what CRT does, but I actually tend to doubt it).

re: Understanding the classical model for linking: You can override an LIB with another LIB, and a LIB with an OBJ, but you can't override an OBJ

Silly — Wed, 09 Jan 2013 23:44:24 GMT

[This requires that the FP library be linked ahead of the static CRT. This is the sort of mistake most people will never figure out.]

Surely not in ye olde classical linker days? But from what I recall, the math libary usually went at the end of the library arg list since it had no dependencies, which is sort of the opposite of this FP library idea.

Wasn't the DOS era floating point emulation stuff either done via an explicit linker option (offloading the choice to the developer), or by the user choosing to run an enumation tsr or having an emu387.exe to be loaded by runtime if needed (maybe triggered by a hardware fault)? I think developers would have cracked the s*ts back in the day if they had to endure a lookup + indirect function call to handle every %f printf argument encounter.

Delay load functionality could also be an option if a time machine is allowed.

re: Understanding the classical model for linking: You can override an LIB with another LIB, and a LIB with an OBJ, but you can't override an OBJ

ipoverscsi — Wed, 09 Jan 2013 22:08:37 GMT

[What if the format string is generated at run time? -Raymond]

I didn't think of that one. Hmm.

Well, you stumped me, Raymond. I can't think of a way to determine which version of printf to use at link-time. I can see how to do it at runtime with DLLs, overlays, or some other dynamic code loading, but not at link time.

I eagerly await the answer.

re: Understanding the classical model for linking: You can override an LIB with another LIB, and a LIB with an OBJ, but you can't override an OBJ

Maurits [MSFT] — Wed, 09 Jan 2013 21:54:08 GMT

One way to resolve this is to create an (awesome) namespace.

re: Understanding the classical model for linking: You can override an LIB with another LIB, and a LIB with an OBJ, but you can't override an OBJ

Joshua — Wed, 09 Jan 2013 19:46:08 GMT

I think Anonymous123 found it. by knocking out the reference to _fltused in vfprintf's .OBJ (all other *printf call this one), the floating point library is not called in unless used elsewhere. This assumes that vfprintf's %e, %f, and %g are fully inlined. You end up with maybe .5k of unreachable garbage if not used. No special cases in the linker required.

re: Understanding the classical model for linking: You can override an LIB with another LIB, and a LIB with an OBJ, but you can't override an OBJ

Anonymous123 — Wed, 09 Jan 2013 19:27:19 GMT

For the printf issue - printf OBJ should not include _fltused. Yes if the app uses %f and does not use floating point the app will crash, but any app that uses floating formats will itself include _fltused so this symbol is not needed by printf

re: Understanding the classical model for linking: You can override an LIB with another LIB, and a LIB with an OBJ, but you can't override an OBJ

ipoverscsi — Wed, 09 Jan 2013 19:25:16 GMT

@Brian_EE:

True. But unless you preprocess the printf format string you won't know until runtime whether an attempt will be made to format a floating point value. If we assume that we're only doing static linking (no DLLs) then I can't think of any other way to know at link time if you need to floating point library.