bug-libtool
[Top][All Lists]
Advanced

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

Libtool 2.2 ABI issue


From: Yoann Vandoorselaere
Subject: Libtool 2.2 ABI issue
Date: Tue, 04 Nov 2008 16:16:47 +0100

[Please CC me on reply since I'm not subscribed to the list]

Hi,

We are experiencing an issue following the libtool/libltdl 2.2 release
due to the way we use the system in Prelude.

The Prelude library (libprelude), provide a plugin API using
libtool/libltdl, and try to hide most of the details to the application
implementing plugin support through libprelude (for one, application
don't have to use libltdl directly).

In order to support dlpreopening, libprelude used to provide the
following support code in prelude-plugin.h:

extern const void *lt_preloaded_symbols[];

#define PRELUDE_PLUGIN_SET_PRELOADED_SYMBOLS()                     \
        prelude_plugin_set_preloaded_symbols(lt_preloaded_symbols)



A libprelude application implementing plugin, and wanting support for
dlpreopening would then simply call:

PRELUDE_PLUGIN_SET_PRELOADED_SYMBOLS();


This used to work fines with libtool 1.5, but we are now facing two
problem:

There is an ABI compatibility issue when libprelude is compiled with
libtool/libltdl 2.2 but programs using it generated the dlpreopening
table through libtool 1.5.

The program will crash when trying to load plugins, since the
lt_preloaded_symbols table content is different depending on the libtool
version used to generate it:

Under libtool 1.5, the table would contain:
{ "symbol", &symbol_address },
{ NULL, NULL }

An empty table could have no symbol at all, and would only contain the
{ NULL, NULL } entry.


Under libtool 2.2, the table (even empty) always provide a top entry
containing { "@PROGNAME@", (void *) 0 }:

{ "@PROGNAME@", (void *) 0 },
{ "symbol", &symbol_address },
{ NULL, NULL }

Problem arise with empty table generated by libtool 1.5, and passed to
libltdl 2.2: since libltdl 2.2 expect the table first entry to start
with a non NULL string, the program will crash due to a NULL pointer
dereference.

I found a partial solution to this problem by rewriting the table if its
first symbol is NULL or doesn't contain @address@hidden However, I find this
solution less than ideal, so any comment on this solution will be
welcome. 

void prelude_plugin_set_preloaded_symbols(void *symlist)
{
        size_t len;
        lt_dlsymlist *s = symlist;
        static lt_dlsymlist rpl_sym[65535] = {
                { "@PROGNAME@", NULL },
                { NULL, NULL         }
        };

        if ( s[0].name == NULL || strcmp(s[0].name, "@PROGNAME@") != 0 )
{
                for ( len = 0; s[len].name != NULL; len++ );

                if ( len + 1 >= sizeof(rpl_sym) / sizeof(*rpl_sym) ) {
                        prelude_log(PRELUDE_LOG_CRIT, "replacement
symlist is not large enough (%lu entry).\n", len);
                        len = (sizeof(rpl_sym) / sizeof(*rpl_sym)) - 1;
                }

                /*
                 * Copy as much symbols as possible, and set the last
entry to NULL.
                 */
                memcpy(&rpl_sym[1], s, len * sizeof(*rpl_sym));
                rpl_sym[len].name = NULL;

                s = rpl_sym;
        }

        lt_dlpreload_default(s);
}



The second problem is due to libtool 2.2 renaming the symbol table from
lt_preloaded_symbols to lt__PROGRAM__LTX_preloaded_symbols.

A fixe for this issue would be to be able to determine the libtool
version being used at compile time. I would then be able to do something
like:

#ifdef PROGRAM_INCLUDING_THIS_HEADER_IS_USING_LIBTOOL_1_5

extern const void *lt_preloaded_symbols[];

# define PRELUDE_PLUGIN_SET_PRELOADED_SYMBOLS()                     \
         prelude_plugin_set_preloaded_symbols(lt_preloaded_symbols)
#else

extern const void *lt__PROGRAM__LTX_preloaded_symbols[];

# define PRELUDE_PLUGIN_SET_PRELOADED_SYMBOLS()                     \

prelude_plugin_set_preloaded_symbols(lt__PROGRAM__LTX_preloaded_symbols)
#endif



Any help on the above issue will be more than welcome,
Regards,


-- 
Yoann Vandoorselaere <address@hidden>





reply via email to

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