libtool-patches
[Top][All Lists]
Advanced

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

[RFC] Fix libltdl preloader issues with MSVC


From: Peter Rosin
Subject: [RFC] Fix libltdl preloader issues with MSVC
Date: Fri, 19 Oct 2012 23:06:28 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1

Hi!

With the latest dumpbin work in place, libtool starts to add
symbols from import libraries to the generated fooS.c files
in func_generate_dlsyms, as needed by the preloader. And then
the next problem naturally rears its head. This time it is
the age-old data exports problem responsible for code such
as this (in demo.at):

         else if (STREQ ("nothing", name))
 #ifndef _WIN32
          /* In an ideal world we could do this... */
          pnothing = (int*)s->address;
 #else /* !_WIN32 */
          /* In an ideal world a shared lib would be able to export data */
          pnothing = (int*)&nothing;
 #endif

I.e., demo.at isn't even trying to use the data symbol from the
preloader, it just picks data up directly using the import
library on Windows. Which is of course cheating and circumvents
the API etc etc. However, MinGW has long supported pseudo-relocs
and anto-import and the "Ideal world" case should work just fine
with gcc even on _WIN32. But not with MSVC, which fails to link
since data symbols from import libraries are not declared
__declspec(dllimport).

Example from demo.at:

helldl.exeS.obj : error LNK2001: unresolved external symbol _nothing

Fixing that, and making data symbols __declspec(dllimport) is
however not the entire solution, as that yields:

helldl.exeS.c(47) : error C2099: initializer is not a constant

during compilation instead.

The underlying problem is that MSVC does not have pseudo-relocs.

So, this patch adds an @INIT@ entry to the preloader symbol
table, with the address of a function that is intended to do the
relocations of data items from user-provided code instead of
relying on the tools. This function is then filled with
relocation code for MSVC, but left empty everywhere else
where it is not needed.

This is clearly not a finalized patch (it's actually pretty
rough), it's just proof of concept. I have e.g. not optimized
it, but it is clearly possibly to set the @INIT@ address to
NULL and don't call @INIT@ at all in non-MSVC cases. It should
also not be necessary to relocate data symbols from static
libraries from user code, and it should be possible to add a
"done" variable to the relocation function, so that it only
does the work once.



What I'm looking for is feedback. Is it acceptable to add a
new virtual @INIT@ entry like this?  I.e. is this approach
workable or should I just drop it?



With the patches, the testsuite runs cleanly with

.../configure \
   CC="/home/peda/automake/lib/compile cl -nologo" \
   CFLAGS="-MD -Zi -EHsc" \
   CXX="/home/peda/automake/lib/compile cl -nologo" \
   CXXFLAGS="-MD -Zi -EHsc" \
   NM="dumpbin -symbols -headers" \
   LD=link \
   STRIP=: \
   AR="/home/peda/automake/lib/ar-lib lib" \
   RANLIB=: \
   F77=no \
   FC=no \
   GCJ=no

(and it is also clean for MinGW and Cygwin with a default
no-args .../configure, and the "Ideal world" branch from
demo.at above works for MSVC as well, not sure about WinCE
though, no access to that.)

For reference, here is how the generated symbol file
ends up for demo.at in a MSVC build:

------------------8<--------------------
/* helldl.exeS.c - symbol resolution table for `helldl.exe' dlsym emulation. */
/* Generated by libtool (GNU libtool) 2.4.2.282-b3e9-dirty */

#ifdef __cplusplus
extern "C" {
#endif

#if defined __GNUC__ && (((__GNUC__ == 4) && (__GNUC_MINOR__ >= 4)) || 
(__GNUC__ > 4))
#pragma GCC diagnostic ignored "-Wstrict-prototypes"
#endif

/* Keep this code in sync between libtool.m4, ltmain, lt_system.h, and tests.  
*/
#if defined _WIN32 || defined __CYGWIN__ || defined _WIN32_WCE
/* DATA imports from DLLs on WIN32 can't be const, because runtime
   relocations are performed -- see ld's documentation on pseudo-relocs.  */
# define LT_DLSYM_CONST
#elif defined __osf__
/* This system does not cope well with relocations in const data.  */
# define LT_DLSYM_CONST
#else
# define LT_DLSYM_CONST const
#endif
#if defined _WIN32 && defined _MSC_VER
#define LT_DLSYM_DATA extern __declspec(dllimport)
#else
#define LT_DLSYM_DATA extern
#endif

/* External symbol declarations for the compiler. */
extern int foo();
extern int hello();
LT_DLSYM_DATA char nothing;

/* The mapping between symbol names and symbols.  */
typedef struct {
  const char *name;
  void *address;
} lt_dlsymlist;
extern LT_DLSYM_CONST lt_dlsymlist
lt__PROGRAM__LTX_preloaded_symbols[];
static void lt_syminit(void)
{
#if defined _WIN32 && defined _MSC_VER
        LT_DLSYM_CONST lt_dlsymlist *symbol = 
lt__PROGRAM__LTX_preloaded_symbols;
          for (; symbol->name; ++symbol)
            {
if (!strcmp (symbol->name, "nothing")) symbol->address = (void *) &nothing;
            }
#endif
}
LT_DLSYM_CONST lt_dlsymlist
lt__PROGRAM__LTX_preloaded_symbols[] =
{ {"@PROGRAM@", (void *) 0},
  {"@INIT@", (void *) &lt_syminit},
  {"hello-2.dll", (void *) 0},
  {"foo", (void *) &foo},
  {"hello", (void *) &hello},
  {"nothing", (void *) 0},
  {0, (void *) 0}
};

/* This works around a problem in FreeBSD linker */
#ifdef FREEBSD_WORKAROUND
static const void *lt_preloaded_setup() {
  return lt__PROGRAM__LTX_preloaded_symbols;
}
#endif

#ifdef __cplusplus
}
#endif
------------------8<--------------------


Cheers,
Peter

Attachment: 0001-libtool-add-INIT-to-the-preloader-for-data-imports-o.patch
Description: Text Data


reply via email to

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