Disallow rtti

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Disallow rtti

Eric Fiselier via cfe-dev
I am currently starting implementing a new toolchain and want to disable rtti there.
Now saw CalculateRTTIMode in lib/Driver/ToolChain.cpp. Now I would like to warn the user that rtti is actually no supported on that platform (for -frtti). Currently it seems like all rtti handling in Toolchain is hard coded.
What is the best way to indicate missing rtti on a platform?

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Disallow rtti

Eric Fiselier via cfe-dev

> On Oct 24, 2017, at 9:28 AM, Andreas Bergmeier via cfe-dev <[hidden email]> wrote:
>
> I am currently starting implementing a new toolchain and want to disable rtti there.
> Now saw CalculateRTTIMode in lib/Driver/ToolChain.cpp. Now I would like to warn the user that rtti is actually no supported on that platform (for -frtti). Currently it seems like all rtti handling in Toolchain is hard coded.
> What is the best way to indicate missing rtti on a platform?

How is it "missing"?  You just want to have a policy that those language features don't work on your target?  We don't have any existing targets that do that, so it's not surprising that you might need to provide some customization hook for it.

John.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Disallow rtti

Eric Fiselier via cfe-dev
Darn - email lost the 'cfe-dev'

-----Original Message-----
From: Martin J. O'Riordan [mailto:[hidden email]]
Sent: 24 October 2017 18:47
To: 'John McCall' <[hidden email]>; 'Andreas Bergmeier' <[hidden email]>
Subject: RE: [cfe-dev] Disallow rtti

Hi Andreas,

I have not found the overhead of RTTI to be a significant burden (even for embedded with a 128KB memory size constraint), but even so I have defaulted to '-fno-rtti' just in case it is an issue for my users.  I handled this in 'AddMyTargetTargetArgs()' by looking for the last of the options '-frtti' or '-fno-rtti' (using 'getLastArg()'), and if neither was found, passing '-fno-rtti' by default to LLVM (overriding LLVM's normal defaults, but in a target specific way).

You could similarly intercept if the last argument passed was '-frtti' and emit a diagnostic to say that it is not supported, but always pass '-fno-rtti' onto LLVM.

For EH I was a lot more strict.  We do not (and cannot reasonably) support EH in the context of our embedded target, so I simply changed:

    include/c++/__config

from LibC++ to include the following check (I predefine '__mytarget__'):

    #ifdef __mytarget__
    // MYTARGET does not support exception handling
    # if (__has_feature(cxx_exceptions))
    #  error Exception handling is not supported on MYTARGET
    # endif
    #endif

This way, if the programmer uses EH they get a hard and meaningful compile time error that informs them what is going on.

You could do something similar for RTTI.

I chose to use '__config' because only the most trivial/contrived programs do not include at least one C++ header, and '__config' is included by them all ;-)

It is worth noting that LibC++ states that while it supports programs using LibC++ without RTTI, it does not support building LibC++ with RTTI disabled, so you would probably have to qualify your RTTI feature check with a test to see if '_LIBCPP_BUILDING_LIBRARY' is defined or not.

All the best,

        MartinO

-----Original Message-----
From: cfe-dev [mailto:[hidden email]] On Behalf Of John McCall via cfe-dev
Sent: 24 October 2017 18:21
To: Andreas Bergmeier <[hidden email]>
Cc: [hidden email]
Subject: Re: [cfe-dev] Disallow rtti


> On Oct 24, 2017, at 9:28 AM, Andreas Bergmeier via cfe-dev <[hidden email]> wrote:
>
> I am currently starting implementing a new toolchain and want to disable rtti there.
> Now saw CalculateRTTIMode in lib/Driver/ToolChain.cpp. Now I would like to warn the user that rtti is actually no supported on that platform (for -frtti). Currently it seems like all rtti handling in Toolchain is hard coded.
> What is the best way to indicate missing rtti on a platform?

How is it "missing"?  You just want to have a policy that those language features don't work on your target?  We don't have any existing targets that do that, so it's not surprising that you might need to provide some customization hook for it.

John.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Disallow rtti

Eric Fiselier via cfe-dev
On 24 Oct 2017, at 18:48, Martin J. O'Riordan via cfe-dev <[hidden email]> wrote:
>
> I have not found the overhead of RTTI to be a significant burden (even for embedded with a 128KB memory size constraint)

With only 128KB of ROM, you’re going to find it hard to fit a C++ runtime library (though if you rip out the demangler you’ll save quite a lot), so even if you compile with RTTI, you won’t be able to use it or throw exceptions.  A stack unwinder plus the C++ personality function can easily add up to more than the ROM on such devices.  It’s possible to fit just enough support for dynamic_cast on such a system, but it’s somewhat awkward to have dynamic_cast working but exceptions not working.

David

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Disallow rtti

Eric Fiselier via cfe-dev
Exactly that.
So will have no RTTI, no dynamic_cast, no thread_local, no exceptions, no new, no libc++
Just a very stripped down version of C++ (is there any other similar, stripped down toolchain!?).
Still trying to find, how I can have the code fail when attempting rtti. Seems like there is no such capability via the Driver interface.

On Wed, Oct 25, 2017 at 10:25 AM David Chisnall via cfe-dev <[hidden email]> wrote:
On 24 Oct 2017, at 18:48, Martin J. O'Riordan via cfe-dev <[hidden email]> wrote:
>
> I have not found the overhead of RTTI to be a significant burden (even for embedded with a 128KB memory size constraint)

With only 128KB of ROM, you’re going to find it hard to fit a C++ runtime library (though if you rip out the demangler you’ll save quite a lot), so even if you compile with RTTI, you won’t be able to use it or throw exceptions.  A stack unwinder plus the C++ personality function can easily add up to more than the ROM on such devices.  It’s possible to fit just enough support for dynamic_cast on such a system, but it’s somewhat awkward to have dynamic_cast working but exceptions not working.

David

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev