GNOME Bugzilla – Bug 354522
Small problem with PLT hiding 6 symbols
Last modified: 2007-07-09 05:26:57 UTC
Some of the symbols in glib are generating PLT entries: [behdad@home .libs]$ eu-readelf -r libglib-2.0.so | grep JMP_SLOT | grep g_ 0x0009d20c 386_JMP_SLOT 0x0004d80d g_memdup 0x0009d26c 386_JMP_SLOT 0x0004f589 g_string_insert_c 0x0009d320 386_JMP_SLOT 0x00036818 g_malloc 0x0009d340 386_JMP_SLOT 0x00036660 g_realloc 0x0009d368 386_JMP_SLOT 0x0002da2c g_get_current_time 0x0009d3e8 386_JMP_SLOT 0x0005c1e7 g_get_prgname 0x0009d3fc 386_JMP_SLOT 0x000365d2 g_free 0x0009d400 386_JMP_SLOT 0x0005c7cd g_parse_debug_string 0x0009d410 386_JMP_SLOT 0x000378b3 g_return_if_fail_warning Not quite sure what the reason is. Also, g_return_if_fail_warning is public but not listed in any header file.
There are some in gthread and gobject too.
g_return_if_fail_warning needs to be public, since it is used in public macros. It _is_ included in gmessages.h
(In reply to comment #2) > g_return_if_fail_warning needs to be public, since it is used in public > macros. It _is_ included in gmessages.h My bad.
I have no idea why these PLY entries are generated.
Created attachment 72522 [details] [review] Fix Some were coming from misplaced includes. Others from gnulib/ not including galias.h, and finally one I couldn't fix, g_string_insert_c is used in g_string_append_c_inline unaliased. I just ignore that one in pltcheck.sh.
#define G_IMPLEMENT_INTERFACE(TYPE_IFACE, iface_init) { \ - static const GInterfaceInfo g_implement_interface_info = { \ + const GInterfaceInfo g_implement_interface_info = { \ Oops. This belongs to another bug.
Thanks, committed
I wouldn't be so sure that memory functions should not have local PLT entries, as this will likely mean that these can't be replaced via LD_PRELOAD or similar means for the internal uses - as such application code starts to use the different definition of the memory function from LD_PRELOAD, but internal allocation still the implementation provided by glib. These can mix (glib hands an allocated structure that user has to deallocate himself) and hence cause havoc. I conclude this from the notes from Ulrich Dreppers DSO Howto papers section 2.2.7.
(In reply to comment #8) > I wouldn't be so sure that memory functions should not have local PLT entries, > as this will likely mean that these can't be replaced via LD_PRELOAD or similar > means for the internal uses - as such application code starts to use the > different definition of the memory function from LD_PRELOAD, but internal > allocation still the implementation provided by glib. These can mix (glib hands > an allocated structure that user has to deallocate himself) and hence cause > havoc. I don't think we support such a thing. Note that this is not system malloc/free, but g_malloc/g_realloc/g_free. Users can replace them using g_mem_set_vtable(). > I conclude this from the notes from Ulrich Dreppers DSO Howto papers section > 2.2.7.
Created attachment 74837 [details] [review] patch to shut up pltcheck.sh when G_ATOMIC_OP_MEMORY_BARRIER_NEEDED is set On powerpc, pltcheck.sh complains about g_atomic_int_get, g_atomic_int_set, g_atomic_pointer_get, and g_atomic_pointer_set. The patch fixes that by adding these functions to galias.h and galiasdef.c when G_ATOMIC_OP_MEMORY_BARRIER_NEEDED is true.
(In reply to comment #10) > Created an attachment (id=74837) [edit] > patch to shut up pltcheck.sh when G_ATOMIC_OP_MEMORY_BARRIER_NEEDED is set > > On powerpc, pltcheck.sh complains about g_atomic_int_get, g_atomic_int_set, > g_atomic_pointer_get, and g_atomic_pointer_set. The patch fixes that by adding > these functions to galias.h and galiasdef.c when > G_ATOMIC_OP_MEMORY_BARRIER_NEEDED is true. Thanks for the patch; I'm reopening this bug as I would like someone to review and merge this patch as it would fix the testsuite on multiple Debian architectures: Alpha: http://buildd.debian.org/fetch.cgi?pkg=glib2.0&arch=alpha&ver=2.12.12-1&stamp=1178571792 Checking .libs/libglib-2.0.so for local PLT entries 0000000ccf48 00d10000001a R_ALPHA_JMP_SLOT 00000000000125f0 g_atomic_int_get + 0 0000000ccf80 03c80000001a R_ALPHA_JMP_SLOT 0000000000012600 g_atomic_int_set + 0 0000000cd030 00ac0000001a R_ALPHA_JMP_SLOT 0000000000012610 g_atomic_pointer_get + 0 0000000cd058 039d0000001a R_ALPHA_JMP_SLOT 0000000000012620 g_atomic_pointer_set + 0 FAIL: pltcheck.sh Arm: http://buildd.debian.org/fetch.cgi?pkg=glib2.0&arch=arm&ver=2.12.12-1&stamp=1178471559 Checking .libs/libglib-2.0.so for local PLT entries 0009f19c 00005e16 R_ARM_JUMP_SLOT 0000f830 g_atomic_pointer_get 0009f2a8 00025416 R_ARM_JUMP_SLOT 0000f7a0 g_atomic_int_set 0009f370 0003f816 R_ARM_JUMP_SLOT 0000f8ac g_atomic_pointer_set 0009f37c 00042616 R_ARM_JUMP_SLOT 0000f724 g_atomic_int_get FAIL: pltcheck.sh Powerpc: http://buildd.debian.org/fetch.cgi?pkg=glib2.0&arch=powerpc&ver=2.12.12-1&stamp=1178556716 Checking .libs/libglib-2.0.so for local PLT entries 000be328 00041715 R_PPC_JMP_SLOT 00015bf0 g_atomic_int_get + 0 000be33c 00012015 R_PPC_JMP_SLOT 00015c10 g_atomic_int_set + 0 000be380 00043f15 R_PPC_JMP_SLOT 00015c30 g_atomic_pointer_get + 0 000be398 00014515 R_PPC_JMP_SLOT 00015c50 g_atomic_pointer_set + 0 FAIL: pltcheck.sh Sparc: http://buildd.debian.org/fetch.cgi?pkg=glib2.0&arch=sparc&ver=2.12.12-1&stamp=1178463710 Checking .libs/libglib-2.0.so for local PLT entries 000b64b4 00041815 R_SPARC_JMP_SLOT 00015384 g_atomic_int_get + 0 000b64f0 00012115 R_SPARC_JMP_SLOT 00015404 g_atomic_int_set + 0 000b65bc 00044015 R_SPARC_JMP_SLOT 00015490 g_atomic_pointer_get + 0 000b6604 00014615 R_SPARC_JMP_SLOT 00015510 g_atomic_pointer_set + 0 FAIL: pltcheck.sh Proposed patch is likely to fix these; is it mergeable?
Next time please open a new bug. The fix was different, but it should be all good now. I'm not sure why, but the comment in glib.symbols says that we don't want to alias them, so I just whitelisted them. 2007-06-13 Behdad Esfahbod <behdad@gnome.org> * glib/pltcheck.sh: Whitelist g_atomic_{int,pointer}_[gs]et() as we don't alias them intentionally.
Nothing left to do here, from what I can see ?