[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO

From: address@hidden
Subject: Re: Autoconf tests, libtool symlist files, undefined behavior, and LTO
Date: Thu, 23 Sep 2010 11:01:31 +1000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100914 Thunderbird/3.0.8

Hello all,
I don't know if my problem suites this description.
On 31/03/2010 6:52 AM, Ralf Wildenhues wrote:
Hello gcc and libtool lists,

Summary: both Autoconf-generated configure tests as well as some Libtool
construct invoke undefined behavior.  Question is how to deal with it,
and whether GCC, as QoI, may want to define behavior in these cases.
Currently installed libtool on this system is, (GNU libtool) 2.2.6b

I recently tested the LTO feature of GCC (targeting windows) and I found it was unable to link due to the presence of duplicating lines of *crt* without compiling with -flto there were not such issues.

It seems that libtool is emitting dllcrt2, crtbegin, crtend all over again after the first crtend. In the following line. g++ lib64/dllcrt2.o lib64/crtbegin.o ... _alot_of_other_link_arguments_ ... lib64/crtend.o lib64/dllcrt2.o lib64/crtbegin.o lib64/crtend.o
These last three duplicating .o arguments are causing errors.
lib64/dllcrt2.o:crtdll.c:(.text+0x50): multiple definition of `_CRT_INIT'
lib64/dllcrt2.o:crtdll.c:(.text+0x50): first defined here
Is this a know issue?

1) Autoconf-generated configure tests often fake the prototype of some
function; e.g., AC_CHECK_FUNC([func]) uses
   char func();

and tries to link that.  Using this is undefined according to C99, if
func has a different actual prototype, and when all system libraries are
LTO'ed, gcc -flto may even detect this kind of inconsistency and could
act accordingly (nasal demons and such).

2) libtool has a feature that makes it extract symbol lists from
objects and turn them into fake declarations and function/object
pointers: fake static preloaded modules.

It currently works by running nm or a similar tool over the object, then
converting the output with a couple of sed script or so
(global_symbol_pipe, global_symbol_to_cdecl, and a couple more) to a
synthesized extra source file that then contains code like this:

extern int func();
extern char variable;

typedef struct {
   const char *name;
   void *address;
} lt_dlsymlist;

extern const lt_dlsymlist
const lt_dlsymlist
lt__PROGRAM__LTX_preloaded_symbols[] =
{  { "@PROGRAM@", (void *) 0 },
   {"func", (void *)&func},
   {"variable", (void *)&variable},
   {0, (void *) 0}

This is invoking undefined behavior in a couple of respects:

a) Pointers to functions are stored in pointer-to-void variables.
This could be fixed with an incompatible API change to using a union of
object and function pointer, I guess.

b) The symbols 'func' and 'variable' likely have the wrong prototypes,
i.e., elsewhere, they might be declared as

   void func(int, double);
   double variable[42];

instead.  I haven't come across any actual issues with this yet, except
now LTO may rightfully complain about it.

Question is, what can we do about this?  We could ensure to never pass
-flto or -fwhopr to the compilation of the libtool symfile object, and
remove it from some or all link tests done in configure.  That's ugly.
Would that even be sufficient though?  Conversely, would GCC developers
be willing to agree that, when GCC detects such inconsistencies, it
wouldn't take adverse advantage of it (e.g., by turning off LTO in this
case, or similar)?

Other possibilities for Autoconf would be to work toward a new set of
checking macros (or extensions of current one) where the
author passes a full prototype for each function to check (Autoconf
could keep a list of known prototypes for often-checked functions).
I'm not sure how to fix the libtool symfile in a C99-conforming way.

Thanks for reading this far.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]