[Bug sanitizer/64670] New: -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[Bug sanitizer/64670] New: -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[burnus at gcc dot gnu.org]

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

            Bug ID: 64670
           Summary: -fsanitize=vptr leads to "undefined reference to
                    `typeinfo for class'"
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

I have a class of the form
  class name {
    virtual ~name() {};
    virtual void func() = 0;
  };

Using -fsanitize=vptr leads to an "undefined reference to `typeinfo for name'".

I'll try to come up with a test case.

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Created attachment 34487
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34487&action=edit
test_case.ii - compile with g++ -fsanitize=vptr; gives bogus "undefined
reference to `typeinfo for LogListener'"

The attached file shows with "g++ -fsanitize=vptr" (among others):

   undefined reference to `typeinfo for LogListener'

without "-fsanitize=vptr" only the expected undefined references appear.

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[mpolacek at gcc dot gnu.org]

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

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

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

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I think that's because of the #pragma interface.

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems clang++ -fsanitize=vptr -O0 emits the _ZTI11LogListener object in the
assembly, while without -fsanitize=vptr it does not.  g++ doesn't emit the
definition of it in either case, but with -fsanitize=vptr emits a use.  Jason,
what do you think about this?  Shall we force emission of the _ZTI11LogListener
despire #pragma implementation, or don't instrument, something else?

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> ---
This seems like a bug in the user's code, not the compiler.  If the class is
defined in a header with #pragma interface, there needs to be a matching
#pragma implementation somewhere to cause the typeinfo and such to be emitted.

clang doesn't run into this because it just ignores #pragma interface.

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Created attachment 34628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34628&action=edit
Updated test case (part 2/2): [aux file]

Updated test case. The first file matches what the original source code had:

  #pragma interface
in the header and
  #pragma implementation "file.h"

in the implementation. However, "class LogListener" is only forward declared in
the header file - and in the actual implementation also includes
"LogListener.h", which also has "#pragma interface".


The LogListener.cc file includes LogListener.h and has "#pragma
implementation".

For my "aux file", no symbol is generated at all. For the real-world
LogListener.cc, a "V typeinfo for LogListener" is created and "W
LogListener::LogListener()". (In the original file, a class inheriting from
LogListener is declared (.h) and implemented (.cc).)

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #6)
> Created attachment 34628 [details]
> Updated test case (part 2/2): [aux file]

Missed to state:

This file 'implements' the "class LogListener" - however, the generated .o file
contains no symbols.

Using an explicit.
  #pragma implementation
doesn't change the result.

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #5)
> Updated test case (part 1/2): [main file] compile with g++ -fsanitize=vptr

In this test case you have

> #pragma implementation "test.h"

followed by

> # 1 "test2.h" 1
> #pragma interface

so the #pragma implementation doesn't match.  If I change it to be "test2.h" I
get the typeinfo for LogListener.

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #8)
> (In reply to Tobias Burnus from comment #5)
> > Updated test case (part 1/2): [main file] compile with g++ -fsanitize=vptr
> so the #pragma implementation doesn't match.  If I change it to be "test2.h"
> I get the typeinfo for LogListener.

I have to admit that I am lost - is there a good explanation of #pragma
implementation/interface somewhere?


In the real code, one has something like the following, which I tried to mimic
in the test case. If I understood your comment correctly, I should use in
"log.c" not only 'implementation "log.h"' but additionally(?) 'implementation
"LogListener.h"' - i.e. using 'pragma implementation' for LogListener.h's
classes only in LogListener.h is not sufficient?


----- LogListener.h ------
// Complete file except for "..." bits and #include lines.
#pragma interface
class LogListener
{
 public:
  virtual ~LogListener() {}
  virtual void listen( const Cstring& input) = 0;
  // virtual ... = 0;  // some more
}
class AccumulatingLogListener : public LogListener {...};


----- LogListener.cc ------
// matches approx. attachment 34628
// As it is short, that's really the complete file
#pragma implementation

#include "LogListener.h"
void AccumulatingLogListener::listen( const Cstring& input) {
  m_buffer += input;
}


----- log.h ------
#pragma interface

class LogListener;
class Log_Handler {....};


----- log.c ------
// matches approx. attachment 34627
#pragma implementation "log.h"
#include "log.h"
#include "LogListener.h"

// implementation of Log_Handler, which causes -fsanitize=vptr to access
// "typeinfo for name LogListener", which is "U".

----------------------------------------------------


The real-world LogListener.o has (full output as it is short):
000000000000006d t
_GLOBAL__sub_D_00099_0__ZN23AccumulatingLogListener6listenERK7Cstring
0000000000000082 t
_GLOBAL__sub_I_00099_1__ZN23AccumulatingLogListener6listenERK7Cstring
0000000000000000 W LogListener::LogListener()
0000000000000000 W LogListener::LogListener()
0000000000000000 W LogListener::~LogListener()
0000000000000000 W LogListener::~LogListener()
0000000000000000 W LogListener::~LogListener()
0000000000000000 T AccumulatingLogListener::listen(Cstring const&)
0000000000000000 W AccumulatingLogListener::AccumulatingLogListener(int)
0000000000000000 W AccumulatingLogListener::AccumulatingLogListener(int)
0000000000000000 W AccumulatingLogListener::~AccumulatingLogListener()
0000000000000000 W AccumulatingLogListener::~AccumulatingLogListener()
0000000000000000 W AccumulatingLogListener::~AccumulatingLogListener()
0000000000000000 W AccumulatingLogListener::getContent() const
0000000000000000 W AccumulatingLogListener::eatsMessages() const
0000000000000000 W AccumulatingLogListener::isAccumulatingLogListerner() const
0000000000000000 V typeinfo for LogListener
0000000000000000 V typeinfo for AccumulatingLogListener
0000000000000000 V typeinfo name for LogListener
0000000000000000 V typeinfo name for AccumulatingLogListener
0000000000000000 V vtable for LogListener
0000000000000000 V vtable for AccumulatingLogListener

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #9)
> In the real code, one has something like the following, which I tried to
> mimic in the test case. If I understood your comment correctly, I should use
> in "log.c" not only 'implementation "log.h"' but additionally(?)
> 'implementation "LogListener.h"' - i.e. using 'pragma implementation' for
> LogListener.h's classes only in LogListener.h is not sufficient?

Having #pragma implementation in LogListener.cc is sufficient:

> The real-world LogListener.o has (full output as it is short):
...
> 0000000000000000 V typeinfo for LogListener

So why are you getting an undefined reference?

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[burnus at gcc dot gnu.org]

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

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #10)
> Having #pragma implementation in LogListener.cc is sufficient:
> > The real-world LogListener.o has (full output as it is short):
> ...
> > 0000000000000000 V typeinfo for LogListener
> So why are you getting an undefined reference?

Because log.o has due to the vptr sanitizer:
                 U typeinfo for LogListener

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #11)
> Because log.o has due to the vptr sanitizer:
>                  U typeinfo for LogListener

And why isn't that reference satisfied by the definition in LogListener.o?

[Bug sanitizer/64670] -fsanitize=vptr leads to "undefined reference to `typeinfo for class'"

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #13 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Close as INVALID.

The LogListener.o was missing for one make target - and I kept looking at the
wrong one. Misreading the description of "V" also didn't help ("[...] When a
weak undefined symbol is linked and the symbol is not defined, the value of the
weak symbol becomes zero with no error.")


Sorry for wasting everyone's time :-(