Understanding the classical model for linking: Taking symbols along for the ride

re: Understanding the classical model for linking: Taking symbols along for the ride

Gregory — Thu, 10 Jan 2013 22:51:29 GMT

Can someone come up with a more concrete scenario then?

[See the entire printf discussion. -Raymond]

re: Understanding the classical model for linking: Taking symbols along for the ride

Brian_EE — Thu, 10 Jan 2013 13:59:40 GMT

@Gregory: Um, simply because it is a contrived example used to describe the issue in general terms maybe?

re: Understanding the classical model for linking: Taking symbols along for the ride

Gregory — Wed, 09 Jan 2013 23:23:09 GMT

Why do we want magicNumber initialization to happen through g_InitMagicNumber exactly?

re: Understanding the classical model for linking: Taking symbols along for the ride

Mark — Wed, 09 Jan 2013 20:09:50 GMT

I don't get why you need __fltused. I thought that something like 1.2 + 3.4 gets compiled into something like __fltadd(1.2, 3.4). Then you can resolve __fltadd instead of a bogus symbol like __fltused.

re: Understanding the classical model for linking: Taking symbols along for the ride

Evan — Wed, 09 Jan 2013 16:37:38 GMT

I suspect the use of "magic" to describe the operating of constructors and destructors is because by my understanding if you went back to, I dunno, 1980 runtimes, they wouldn't get run. The g_InitMagicNumber symbol would be present, but wouldn't do anything. (1980 is arbitrary. Maybe it'd have to be 1975 or something.)

As Raymond's latest response (to Brian_EE) suggests, even something like __fltused fits into the classical model of linking, and you'd be able to pull that trick with 1980 linkers.

[They get run even under the classical model, but by a technique not described in this series of articles (but described by Larry). -Raymond]

re: Understanding the classical model for linking: Taking symbols along for the ride

Brian_EE — Wed, 09 Jan 2013 14:48:28 GMT

@Myria:

I understand how that works. I was questioning why Raymond considered it to be "magic".

And in DSP-land the section is called .init_array and is called in c_int00.

[It's even more magical than the __fltused magic, since it employs a trick beyond merely resolving symbols. -Raymond]

re: Understanding the classical model for linking: Taking symbols along for the ride

Neil — Wed, 09 Jan 2013 11:23:59 GMT

Another version of the trick is when you have a dllexport symbol in a library; a fake reference to the symbol in an unused function in an explicit object file will cause the exported symbol to get resolved. Firefox used to do this but now they just skip the intermediate library step and simply link all their bazillion object files together.

re: Understanding the classical model for linking: Taking symbols along for the ride

Neil — Wed, 09 Jan 2013 11:19:56 GMT

Thus the note in *printf pointing out that you couldn't use any of the floating-point formats unless you actually did some floating-point operation that caused the floating-point library to get linked in.

re: Understanding the classical model for linking: Taking symbols along for the ride

Myria — Wed, 09 Jan 2013 03:39:26 GMT

@alegr1:

It's sad that MASM doesn't have a way to declare COMDATs. If you use /Gy /Fa on cl.exe's command line to generate function COMDATs and output assembly source, the COMDAT flag is only a comment. If you were to assemble the output file, it wouldn't have COMDATs.

@Brian_EE:

Global constructors work in Visual C++ by the compiler putting a pointer to the constructor into a specifically-named .obj section. Part of the msvcrt startup code goes through the list of pointers in this section and calls each function; in Visual Studio 2010, that's the function _initterm in crt0dat.c. See also crt0init.c.

re: Understanding the classical model for linking: Taking symbols along for the ride

Joshua — Tue, 08 Jan 2013 22:35:55 GMT

[The magic is how the constructor manages to run when there is no explicit caller. -Raymond]

Maybe I should show Raymond how to make code run without an implicit caller either.