thr3ads.net - llvm dev - [LLVMdev] RTTI handling [Oct 2011]

If this information is useful, please help other people find it:
Share via:

Somorjai, Akos

2011-Sep-30 23:35 UTC

[LLVMdev] RTTI handling

Thanks, John. I'll experiment with both the warning and the nm-weak external
tool, and let you know the results.

Best, Akos

From: John McCall <rjmccall at apple.com<mailto:rjmccall at
apple.com>>
Date: Fri, 30 Sep 2011 15:24:33 -0700
To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at
graphisoft.com>>
Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>"
<llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>>
Subject: Re: [LLVMdev] RTTI handling

On Sep 30, 2011, at 3:04 PM, Somorjai, Akos wrote:
Thanks! Yes, we are trying to avoid that situation as much as possible.

Is there any compiler/linker/static analyzer option that would point out those
problems (in 13 million lines, large part of that being legacy code)?

There's a -Wweak-vtables which will point out a lot of these cases.  I have
to warn you that in previous releases, it's still pretty experimental;  Doug
Gregor has done a lot of work on it on ToT.

Another option is to run 'nm' on the objects/executables you're
interested in.  For example, this file:

daysthatwere clang$ cat red.cpp
  #include <typeinfo>

  struct A {};
  struct B { virtual ~B(); };
  struct C { virtual ~C(); };
  C::~C() {}

  const std::type_info &test0() { return typeid(const char*); }
  const std::type_info &test1() { return typeid(const char**); }
  const std::type_info &test2() { return typeid(A); }
  const std::type_info &test3() { return typeid(B); }
  const std::type_info &test4() { return typeid(C); }

daysthatwere clang$ clang /tmp/red.cpp -c -o red.o
daysthatwere clang$ nm -m red.o | grep __ZTI | c++filt
0000000000000120 (__DATA,__datacoal_nt) weak external typeinfo for A
                 (undefined) external typeinfo for B
0000000000000150 (__DATA,__const) external typeinfo for C
                 (undefined) external typeinfo for char const*
0000000000000100 (__DATA,__datacoal_nt) weak external typeinfo for char const**

The "external" symbols are strong symbols provided by this object;
these aren't a problem.
The "undefined external" symbols are expected to appear in a different
object; these also aren't a problem.
The "weak external" symbols are the ones with vague linkage that you
care about.

Otherwise, I don't have any magic bullets for you, sorry.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110930/c5af3456/attachment.html>

Somorjai, Akos

2011-Oct-03 11:42 UTC

head link

[LLVMdev] RTTI handling

John,

I'm trying to use this warning to check the vtable problem. Here's an
example

In mem.hpp


class AA {

// Construction / destruction:

protected:

AA ();

AA (const AA&); // Disabled

public:

virtual ~AA ();

};

In mem.cpp


#include "mem.hpp"


AA::~AA()

{

}

And I still get the following warning:

warning: 'AA' has no out-of-line virtual method definitions; its vtable
will be emitted in every translation unit [-Wweak-vtables,3]

What am I doing wrong? Shall I declare the destructor to be pure virtual (then
the warning goes away)? This is not always an option, because not all of these
classes are ABCs.

Thanks,

Akos

From: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at
graphisoft.com>>
Date: Fri, 30 Sep 2011 23:35:32 +0000
To: John McCall <rjmccall at apple.com<mailto:rjmccall at
apple.com>>
Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>"
<llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>>
Subject: Re: [LLVMdev] RTTI handling

Thanks, John. I'll experiment with both the warning and the nm-weak external
tool, and let you know the results.

Best, Akos


From: John McCall <rjmccall at apple.com<mailto:rjmccall at
apple.com>>
Date: Fri, 30 Sep 2011 15:24:33 -0700
To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at
graphisoft.com>>
Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>"
<llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>>
Subject: Re: [LLVMdev] RTTI handling

On Sep 30, 2011, at 3:04 PM, Somorjai, Akos wrote:
Thanks! Yes, we are trying to avoid that situation as much as possible.

Is there any compiler/linker/static analyzer option that would point out those
problems (in 13 million lines, large part of that being legacy code)?

There's a -Wweak-vtables which will point out a lot of these cases.  I have
to warn you that in previous releases, it's still pretty experimental;  Doug
Gregor has done a lot of work on it on ToT.

Another option is to run 'nm' on the objects/executables you're
interested in.  For example, this file:

daysthatwere clang$ cat red.cpp
  #include <typeinfo>

  struct A {};
  struct B { virtual ~B(); };
  struct C { virtual ~C(); };
  C::~C() {}

  const std::type_info &test0() { return typeid(const char*); }
  const std::type_info &test1() { return typeid(const char**); }
  const std::type_info &test2() { return typeid(A); }
  const std::type_info &test3() { return typeid(B); }
  const std::type_info &test4() { return typeid(C); }

daysthatwere clang$ clang /tmp/red.cpp -c -o red.o
daysthatwere clang$ nm -m red.o | grep __ZTI | c++filt
0000000000000120 (__DATA,__datacoal_nt) weak external typeinfo for A
                 (undefined) external typeinfo for B
0000000000000150 (__DATA,__const) external typeinfo for C
                 (undefined) external typeinfo for char const*
0000000000000100 (__DATA,__datacoal_nt) weak external typeinfo for char const**

The "external" symbols are strong symbols provided by this object;
these aren't a problem.
The "undefined external" symbols are expected to appear in a different
object; these also aren't a problem.
The "weak external" symbols are the ones with vague linkage that you
care about.

Otherwise, I don't have any magic bullets for you, sorry.

John.
_______________________________________________ LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>
http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111003/849d6447/attachment.html>

John McCall

2011-Oct-03 17:19 UTC

head link

[LLVMdev] RTTI handling

On Oct 3, 2011, at 4:42 AM, Somorjai, Akos wrote:> I'm trying to use this warning to check the vtable problem. Here's
an example
> 
> In mem.hpp 
> 
> class
> AA {
> // Construction / destruction:
> protected:
> AA ();
> AA (const AA&); // Disabled
> public:
> virtual ~AA ();
> };
> 
> In mem.cpp
> 
> #include "mem.hpp"
> 
> AA::~AA()
> {
> }
> 
> And I still get the following warning:
> 
> warning: 'AA' has no out-of-line virtual method definitions; its
vtable will be emitted in every translation unit [-Wweak-vtables,3]
Which version of Clang are you using?  Like I said, this warning was still
experimental even a few months ago, and it's gotten a lot of attention on
ToT.  In particular, this case no longer warns.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111003/6f3e7d10/attachment.html>

Apparently Analagous Threads

Search for more possibly parallel threads

llvm dev - Oct 2011 - [LLVMdev] RTTI handling

[LLVMdev] RTTI handling

[LLVMdev] RTTI handling

[LLVMdev] RTTI handling

Apparently Analagous Threads