[Bug c++/97908] New: Should _ZTI and _ZTS symbols be marked GNU_UNIQUE

[Bug c++/97908] New: Should _ZTI and _ZTS symbols be marked GNU_UNIQUE

[jengelh at inai dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97908

            Bug ID: 97908
           Summary: Should _ZTI and _ZTS symbols be marked GNU_UNIQUE
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jengelh at inai dot de
  Target Milestone: ---

» cat libx.cpp
#include <typeinfo>
class Foobar {};
extern "C" { const char *makename(); }
const char *makename() { Foobar f; return typeid(f).name(); }
» cat m.cpp
#include <cstdio>
#include <dlfcn.h>
int main()
{
        auto hnd = dlopen("./libx.so", RTLD_NOW);
        auto f = reinterpret_cast<const char *(*)()>(dlsym(hnd, "makename"));
        auto name = f();
        printf("%s\n", name);
        dlclose(hnd);
        printf("%s\n", name);
}
» g++-11 libx.cpp -shared -fPIC -ggdb3 -o libx.so; g++ m.cpp -fPIC -ggdb3 -Wall
-ldl
» ./a.out 
6Foobar
Segmentation fault (core dumped)
» g++-11 -v
gcc version 11.0.0 20201112 (experimental) [revision
876b45db81a708616d70b1ab66b71bd503809c21] (SUSE Linux) 


I do not know if this is even supposed to work. dlopen/dlclose is outside the
scope of the C++ standard, and POSIX (where dlopen comes from) does not mention
C++ during dlopen. However, this _alternate_ libx.cpp makes the program work:

#include <typeinfo>
struct Foobar { static constexpr char __tag[sizeof(std::type_info)] = { }; };
extern "C" { const char *makename(); }
const char *makename() { Foobar f; return typeid(f).name(); }
const char *helperfunc() { Foobar f; return f.__tag; }

__tag is emitted into the object file as a STB_GNU_UNIQUE symbol, which happens
to implicate RTLD_NODELETE for dlopen.

So, if __tag is getting the "unique" treatment to fulfill some guarantee,
should typeinfo variables (_ZTS* and _ZTI*) not get the same treatment, for the
same reasons?

[Bug c++/97908] Should _ZTI and _ZTS symbols be marked GNU_UNIQUE

[jengelh at inai dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97908

--- Comment #1 from Jan Engelhardt <jengelh at inai dot de> ---
On second thought, this is practically the same issue as functions going away
(like example below), so wontfix seems appropriate.

-- main
#include <dlfcn.h>
struct base { virtual ~base() {}; };
int main()
{
        auto hnd = dlopen("./libx.so", RTLD_NOW);
        auto f = reinterpret_cast<base *(*)()>(dlsym(hnd, "makederiv"));
        auto deriv = f();
        dlclose(hnd);
        delete deriv;
}
-- libx
#include <typeinfo>
struct base { virtual ~base() {}; }
struct deriv : base { virtual ~deriv() {}; }
extern "C" { base *makederiv(); }
base *makederiv() { return new deriv; }

[Bug c++/97908] Should _ZTI and _ZTS symbols be marked GNU_UNIQUE

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97908

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jan Engelhardt from comment #0)
>         dlclose(hnd);
>         printf("%s\n", name);

This is just a user bug, don't dlclose a library when you are using anything
from it.

[Bug c++/97908] Should _ZTI and _ZTS symbols be marked GNU_UNIQUE

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97908

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Looks invalid.

[Bug c++/97908] Should _ZTI and _ZTS symbols be marked GNU_UNIQUE

[jengelh at inai dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97908

--- Comment #4 from Jan Engelhardt <jengelh at inai dot de> ---
>don't dlclose a library when you are using anything from it.

That's easier said then done when using C++, as (inline) functions and static
objects can potentially be instantiated in any object file. A shared library
using typeid(T) could be getting the typeinfo either from a possible copy in
the main program, or from the copy inside any loaded shared library.