Quantcast

LibC++ v4.0 testing and exceptions

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

LibC++ v4.0 testing and exceptions

Asiri Rathnayake via cfe-dev

I have started testing our LibC++ v4.0 implementation, and I am seeing a very large number of tests failing because the test uses ‘try’ or some other EH related feature.  However, my platform does not (and cannot) support Exception Handling.  Previous releases used ‘_LIBCPP_NO_EXCEPTIONS’ in the tests to determine if the implementation supported EH or not, but this seems not to be the case for the most recent v4.0 RC1 release.

 

At the moment this appears to be the cause of 309 regressions I am seeing.  Has LibC++ dropped support for platforms that do not support EH?

 

Thanks,

 

            MartinO

 

 


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

Re: LibC++ v4.0 testing and exceptions

Asiri Rathnayake via cfe-dev

Others are failing because of ‘align_val_t’ - it looks to be like these are C++17 tests, but the tests are not being disabled when I use ‘-std=c++14’.  My target it cross-compiled and out-of-tree, so the CMake based configuration for the tests is not useful.  Previously the tests automatically excluded themselves based on the STDC++ version chosen, is this intended for the current tests?

 

Thanks,

 

            MartinO

 

From: Martin J. O'Riordan [mailto:[hidden email]]
Sent: 31 January 2017 17:48
To: 'cfe-dev' <[hidden email]>
Subject: LibC++ v4.0 testing and exceptions

 

I have started testing our LibC++ v4.0 implementation, and I am seeing a very large number of tests failing because the test uses ‘try’ or some other EH related feature.  However, my platform does not (and cannot) support Exception Handling.  Previous releases used ‘_LIBCPP_NO_EXCEPTIONS’ in the tests to determine if the implementation supported EH or not, but this seems not to be the case for the most recent v4.0 RC1 release.

 

At the moment this appears to be the cause of 309 regressions I am seeing.  Has LibC++ dropped support for platforms that do not support EH?

 

Thanks,

 

            MartinO

 

 


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

Re: LibC++ v4.0 testing and exceptions

Asiri Rathnayake via cfe-dev
In reply to this post by Asiri Rathnayake via cfe-dev


On Tue, Jan 31, 2017 at 10:48 AM, Martin J. O'Riordan via cfe-dev <[hidden email]> wrote:

I have started testing our LibC++ v4.0 implementation, and I am seeing a very large number of tests failing because the test uses ‘try’ or some other EH related feature.  However, my platform does not (and cannot) support Exception Handling.  Previous releases used ‘_LIBCPP_NO_EXCEPTIONS’ in the tests to determine if the implementation supported EH or not, but this seems not to be the case for the most recent v4.0 RC1 release.

 

At the moment this appears to be the cause of 309 regressions I am seeing.  Has LibC++ dropped support for platforms that do not support EH?


No, Libc++ has not dropped support for compiling without exceptions. Did you provide `-DLIBCXX_ENABLE_EXCEPTIONS=OFF` when configuring libc++?  


Others are failing because of ‘align_val_t’ - it looks to be like these are C++17 tests, but the tests are not being disabled when I use ‘-std=c++14’.  
 
How are you running the tests and how are you passing -std=c++14 to them? Libc++ has buildbots for all C++ dialects and -fno-exceptions mode and they are currently

/Eric

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

Re: LibC++ v4.0 testing and exceptions

Asiri Rathnayake via cfe-dev

Hi Eric,

 

I eventually found the problem.  We are not able to test LibC++ using the usual approach because the complexity of building runnable programs for our platform is quite complicated and involves several steps after compilation.  As a result we have to use our own test-runner with mimics the intention of the official version, but I missed processing the ‘UNSUPPORTED:’ meta-data in the test-source comments, and these files ended up failing when they should have been excluded.

 

Not a LibC++ problem, just an unfortunate consequence of not having our LibC++ built and tested in the usual way for In-Tree targets.

 

However, I know that a lot of changes have been made with the intention of supporting non-mainstream targets in a cross-compiler context, for both building and testing LibC++, and sometime I will have to find time to explore adapting this to our needs so that I can dispense with the non-standard alternative we use.

 

For the record, we have made all the appropriate adjustments, and things are looking generally good now.  We are in sync with #294006 of the v4.0 branch, and I intend to bring us up to date with RC2 very soon.

 

Thanks and all the best,

 

            MartinO

 

From: Eric Fiselier [mailto:[hidden email]]
Sent: 04 February 2017 20:20
To: Martin J. O'Riordan <[hidden email]>
Cc: cfe-dev <[hidden email]>
Subject: Re: [cfe-dev] LibC++ v4.0 testing and exceptions

 

 

 

On Tue, Jan 31, 2017 at 10:48 AM, Martin J. O'Riordan via cfe-dev <[hidden email]> wrote:

I have started testing our LibC++ v4.0 implementation, and I am seeing a very large number of tests failing because the test uses ‘try’ or some other EH related feature.  However, my platform does not (and cannot) support Exception Handling.  Previous releases used ‘_LIBCPP_NO_EXCEPTIONS’ in the tests to determine if the implementation supported EH or not, but this seems not to be the case for the most recent v4.0 RC1 release.

 

At the moment this appears to be the cause of 309 regressions I am seeing.  Has LibC++ dropped support for platforms that do not support EH?

 

No, Libc++ has not dropped support for compiling without exceptions. Did you provide `-DLIBCXX_ENABLE_EXCEPTIONS=OFF` when configuring libc++?  

 

 

Others are failing because of ‘align_val_t’ - it looks to be like these are C++17 tests, but the tests are not being disabled when I use ‘-std=c++14’.  

 

How are you running the tests and how are you passing -std=c++14 to them? Libc++ has buildbots for all C++ dialects and -fno-exceptions mode and they are currently

 

/Eric


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

Re: LibC++ v4.0 testing and exceptions

Asiri Rathnayake via cfe-dev
On 9 February 2017 at 01:25, Martin J. O'Riordan via cfe-dev
<[hidden email]> wrote:
> I eventually found the problem.  We are not able to test LibC++ using the
> usual approach because the complexity of building runnable programs for our
> platform is quite complicated and involves several steps after compilation.

If you're on Linux, I've had success with adding a binfmt_misc entry
pointing the kernel at a wrapper for non-native binaries. It lets me
just run "ninja check" on a cross-compiled AArch64 toolchain. Not
tried it with libc++ specifically though.

Cheers.

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

Re: LibC++ v4.0 testing and exceptions

Asiri Rathnayake via cfe-dev
Thanks Tim, can you send me more info about how to do this? off list if not generally useful?  I test under Linux (Centos 6 - our reference platform) and also on Windows (7, 8, 8.1 and 10) from both a native Windows CMD.EXE environment, and from a Cygwin environment which mostly mimics the Linux environment.

Our problem is that because the target is a heterogeneous multicore platform, the conventional steps of "compile -> link -> run" are nowhere near as simplistic; one of the joys of a deeply-embedded cross-compilation environment ;-)

Also, if I do find a way of integrating building LibC++ with the recommended approach, and testing, I will be certain to share my feedback to the community on how I resolved this with a fairly exotic cross-compilation system, and perhaps this could percolate into the generic framework so that other out-of-tree targets could be accommodated.

All the best,

        MartinO

-----Original Message-----
From: Tim Northover [mailto:[hidden email]]
Sent: 09 February 2017 15:32
To: Martin J. O'Riordan <[hidden email]>
Cc: Eric Fiselier <[hidden email]>; cfe-dev <[hidden email]>
Subject: Re: [cfe-dev] LibC++ v4.0 testing and exceptions

On 9 February 2017 at 01:25, Martin J. O'Riordan via cfe-dev <[hidden email]> wrote:
> I eventually found the problem.  We are not able to test LibC++ using
> the usual approach because the complexity of building runnable
> programs for our platform is quite complicated and involves several steps after compilation.

If you're on Linux, I've had success with adding a binfmt_misc entry pointing the kernel at a wrapper for non-native binaries. It lets me just run "ninja check" on a cross-compiled AArch64 toolchain. Not tried it with libc++ specifically though.

Cheers.

Tim.

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

Re: LibC++ v4.0 testing and exceptions

Asiri Rathnayake via cfe-dev
On 9 February 2017 at 09:21, Martin J. O'Riordan
<[hidden email]> wrote:
> Thanks Tim, can you send me more info about how to do this?

Sure. Basically, binfmt_misc is a facility provided by the Linux
kernel. It lets you say something along the lines of "if I tell you to
run a program and the file has bytes X Y Z at offset N, run this
wrapper with the binary as an argument instead". I think the original
intent was to allow userland extension of the binary formats supported
(Java .jar files was the first time I heard of it), but it turns out
to be very useful for running non-native binaries if shenanigans are
needed.

There's a rough description of the syntax at
https://en.wikipedia.org/wiki/Binfmt_misc. The command I use for
AArch64 ELF is:

echo ':aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\x
ff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/home/tim/bin/qemu-aarch64-wrapper:'
> /proc/sys/fs/binfmt_misc/register

The weird bytes just happen to be enough to identify an AArch64 ELF
executable file. The "\xb7\x00" is the EM_AARCH64 encoding which you'd
want to change if you were an otherwise normal 64-bit ELF platform.
Possibly others if you output ELF32 or have other oddities. I'm happy
to help out if you can't work out what you need.

After that, as long as /home/tim/qemu-aarch64-wrapper can produce the
correct stdout/stdin/exitcode/filesystem effects you're good to go.
Mine's pretty trivial, just specifying a fixed sysroot and running
qemu on the given binary, but you could easily run a remote ssh and
gather its results, or run post-link black magic before handing off to
some simulator or hardware-connection.

Other than that, I just run "cmake -DCMAKE_TOOLCHAIN_FILE=Thing ..."
which points $CC at aarch64-linux-gnu-gcc instead of gcc (I've
attached my file here, just in case it's useful). I'm reasonably sure
the llvm-tblgen that gets executed while actually compiling LLVM is an
AArch64 binary, but it runs fine so who cares.

Actually, that last point may be a problem for you if your target
can't access the same filesystem. CMake has some kind of 2-step
TableGen that ought to allow you to build TableGen for the host while
generally cross-compiling everything else, but I've never really
bothered to work out how to use or trigger that I'm afraid.

Let me know if anything's unclear.

Tim.

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

aarch64-toolchain.cmake (940 bytes) Download Attachment
Loading...