public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/97908] New: Should _ZTI and _ZTS symbols be marked GNU_UNIQUE
@ 2020-11-19 14:38 jengelh at inai dot de
2020-11-19 15:18 ` [Bug c++/97908] " jengelh at inai dot de
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: jengelh at inai dot de @ 2020-11-19 14:38 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/97908] Should _ZTI and _ZTS symbols be marked GNU_UNIQUE
2020-11-19 14:38 [Bug c++/97908] New: Should _ZTI and _ZTS symbols be marked GNU_UNIQUE jengelh at inai dot de
@ 2020-11-19 15:18 ` jengelh at inai dot de
2020-11-19 16:46 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: jengelh at inai dot de @ 2020-11-19 15:18 UTC (permalink / raw)
To: gcc-bugs
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; }
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/97908] Should _ZTI and _ZTS symbols be marked GNU_UNIQUE
2020-11-19 14:38 [Bug c++/97908] New: Should _ZTI and _ZTS symbols be marked GNU_UNIQUE jengelh at inai dot de
2020-11-19 15:18 ` [Bug c++/97908] " jengelh at inai dot de
@ 2020-11-19 16:46 ` jakub at gcc dot gnu.org
2020-11-19 18:20 ` mpolacek at gcc dot gnu.org
2020-11-19 20:04 ` jengelh at inai dot de
3 siblings, 0 replies; 5+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-19 16:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/97908] Should _ZTI and _ZTS symbols be marked GNU_UNIQUE
2020-11-19 14:38 [Bug c++/97908] New: Should _ZTI and _ZTS symbols be marked GNU_UNIQUE jengelh at inai dot de
2020-11-19 15:18 ` [Bug c++/97908] " jengelh at inai dot de
2020-11-19 16:46 ` jakub at gcc dot gnu.org
@ 2020-11-19 18:20 ` mpolacek at gcc dot gnu.org
2020-11-19 20:04 ` jengelh at inai dot de
3 siblings, 0 replies; 5+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2020-11-19 18:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug c++/97908] Should _ZTI and _ZTS symbols be marked GNU_UNIQUE
2020-11-19 14:38 [Bug c++/97908] New: Should _ZTI and _ZTS symbols be marked GNU_UNIQUE jengelh at inai dot de
` (2 preceding siblings ...)
2020-11-19 18:20 ` mpolacek at gcc dot gnu.org
@ 2020-11-19 20:04 ` jengelh at inai dot de
3 siblings, 0 replies; 5+ messages in thread
From: jengelh at inai dot de @ 2020-11-19 20:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-11-19 20:04 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-19 14:38 [Bug c++/97908] New: Should _ZTI and _ZTS symbols be marked GNU_UNIQUE jengelh at inai dot de
2020-11-19 15:18 ` [Bug c++/97908] " jengelh at inai dot de
2020-11-19 16:46 ` jakub at gcc dot gnu.org
2020-11-19 18:20 ` mpolacek at gcc dot gnu.org
2020-11-19 20:04 ` jengelh at inai dot de
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).