recent change broke -fcatch-undefined-behavior

Hi all,

I see that there have been recent changes wrt -fcatch-undefined-behavior, and within the last week or so something changed such that my own build of clang (built with CMake on OS X) is unable to build simple programs that use -fcatch-undefined-behavior, I get link errors like:

  "___ubsan_handle_divrem_overflow", referenced from:
      _main in test-OSZvjm.o
  "___ubsan_handle_type_mismatch", referenced from:
      _main in test-OSZvjm.o

Any ideas why?

Cheers,

This is a new feature. Instead of generating traps, -fcatch-undefined-behavior generates library calls that make it easier to find what is wrong (each undefined behavior calls a different function).

This functions are provided by the ubsan library that is part of compiler-rt. But I'm not sure the integration to the Makefile build system is done yet.

-- Jean-Daniel

You mean with the CMake build system? Perhaps if I build using autotools it will work? Or do you mean it works nowhere yet?

Cheers,

I see that there have been recent changes wrt -fcatch-undefined-

behavior, and within the last week or so something changed such that my
own build of clang (built with CMake on OS X) is unable to build simple
programs that use -fcatch-undefined-behavior, I get link errors like:

"___ubsan_handle_divrem_overflow", referenced from:
     _main in test-OSZvjm.o
"___ubsan_handle_type_mismatch", referenced from:
     _main in test-OSZvjm.o

Any ideas why?

This is a new feature. Instead of generating traps, -fcatch-undefined-
behavior generates library calls that make it easier to find what is
wrong (each undefined behavior calls a different function).

This functions are provided by the ubsan library that is part of
compiler-rt. But I'm not sure the integration to the Makefile build
system is done yet.

You mean with the CMake build system?

Generally "Makefile build system" describes the configure+make build
system (at least when it's discussed here).

Perhaps if I build using autotools it will work? Or do you mean it works nowhere yet?

I believe the implication is that it works with the CMake build
system. But you will need to checkout the compiler-rt LLVM project
into llvm/projects to build it along with clang. (& I assume you'll
need to install compiler-rt alongside clang as well, but hopefully the
install target does that)

- David

As I said in my original post, I am using CMake (not autotools aka configure+make). I do have llvm/projects.

My full little 'build everything' script is:

Yep, it looks like the driver integration for the darwin toolchain is missing too.

The ubsan library should probably be append to the link flags somewhere in Toolchains.cpp:DarwinClang::AddLinkRuntimeLibArgs(), but I don't see it anywhere.

-- Jean-Daniel

I see that there have been recent changes wrt -fcatch-undefined-

behavior, and within the last week or so something changed such that my
own build of clang (built with CMake on OS X) is unable to build simple
programs that use -fcatch-undefined-behavior, I get link errors like:

“___ubsan_handle_divrem_overflow”, referenced from:
_main in test-OSZvjm.o
“___ubsan_handle_type_mismatch”, referenced from:
_main in test-OSZvjm.o

Any ideas why?

This is a new feature. Instead of generating traps, -fcatch-undefined-
behavior generates library calls that make it easier to find what is
wrong (each undefined behavior calls a different function).

This functions are provided by the ubsan library that is part of
compiler-rt. But I’m not sure the integration to the Makefile build
system is done yet.

You mean with the CMake build system?

Generally “Makefile build system” describes the configure+make build
system (at least when it’s discussed here).

Perhaps if I build using autotools it will work? Or do you mean it

works nowhere yet?

I believe the implication is that it works with the CMake build
system. But you will need to checkout the compiler-rt LLVM project
into llvm/projects to build it along with clang. (& I assume you’ll
need to install compiler-rt alongside clang as well, but hopefully the
install target does that)

As I said in my original post, I am using CMake (not autotools aka configure+make). I do have llvm/projects.

My full little ‘build everything’ script is:


(cd ~/llvm/llvm/; svn up)
(cd ~/llvm/llvm/tools/clang; svn up)
(cd ~/llvm/llvm/projects/compiler-rt; svn up)

mkdir -p ~/llvm/llvm-rel-bin
rm -rf ~/llvm/llvm-rel-bin/*

mkdir -p ~/llvm/llvm-rel-install
rm -rf ~/llvm/llvm-rel-install/*

cd ~/llvm/llvm-rel-bin
CC="$(xcrun --find cc)" CXX="$(xcrun --find c++)" cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=OFF -DCMAKE_INSTALL_PREFIX=~/llvm/llvm-rel-install …/llvm
make -j16 install

Yep, it looks like the driver integration for the darwin toolchain is missing too.

The ubsan library should probably be append to the link flags somewhere in Toolchains.cpp:DarwinClang::AddLinkRuntimeLibArgs(), but I don’t see it anywhere.

Digging a little further, I found this in ubsan_value.h.

// For now, only support linux. Other platforms should be easy to add, and
// probably work as-is.
#if !defined(linux)

#error “UBSan not supported for this platform!”
#endif

– Jean-Daniel


cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

– Jean-Daniel

I see that there have been recent changes wrt -fcatch-undefined-

behavior, and within the last week or so something changed such that my
own build of clang (built with CMake on OS X) is unable to build simple
programs that use -fcatch-undefined-behavior, I get link errors like:

“___ubsan_handle_divrem_overflow”, referenced from:
_main in test-OSZvjm.o
“___ubsan_handle_type_mismatch”, referenced from:
_main in test-OSZvjm.o

Any ideas why?

This is a new feature. Instead of generating traps, -fcatch-undefined-
behavior generates library calls that make it easier to find what is
wrong (each undefined behavior calls a different function).

This functions are provided by the ubsan library that is part of
compiler-rt. But I’m not sure the integration to the Makefile build
system is done yet.

You mean with the CMake build system?

Generally “Makefile build system” describes the configure+make build
system (at least when it’s discussed here).

Perhaps if I build using autotools it will work? Or do you mean it

works nowhere yet?

I believe the implication is that it works with the CMake build
system. But you will need to checkout the compiler-rt LLVM project
into llvm/projects to build it along with clang. (& I assume you’ll
need to install compiler-rt alongside clang as well, but hopefully the
install target does that)

As I said in my original post, I am using CMake (not autotools aka configure+make). I do have llvm/projects.

My full little ‘build everything’ script is:


(cd ~/llvm/llvm/; svn up)
(cd ~/llvm/llvm/tools/clang; svn up)
(cd ~/llvm/llvm/projects/compiler-rt; svn up)

mkdir -p ~/llvm/llvm-rel-bin
rm -rf ~/llvm/llvm-rel-bin/*

mkdir -p ~/llvm/llvm-rel-install
rm -rf ~/llvm/llvm-rel-install/*

cd ~/llvm/llvm-rel-bin
CC="$(xcrun --find cc)" CXX="$(xcrun --find c++)" cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=OFF -DCMAKE_INSTALL_PREFIX=~/llvm/llvm-rel-install …/llvm
make -j16 install

Yep, it looks like the driver integration for the darwin toolchain is missing too.

The ubsan library should probably be append to the link flags somewhere in Toolchains.cpp:DarwinClang::AddLinkRuntimeLibArgs(), but I don’t see it anywhere.

Digging a little further, I found this in ubsan_value.h.

// For now, only support linux. Other platforms should be easy to add, and
// probably work as-is.
#if !defined(linux)

#error “UBSan not supported for this platform!”
#endif

Yes, as I can see ubsan runtime library is currently supported only in CMake build and is built on Linux only.

That’s unfortunate that clang try to emit function calls on platforms that does not support it.

That said, do you need patches for darwin/make integration, or are you already working on it (or planning to do it after usban is done on linux) ?

– Jean-Daniel

I see that there have been recent changes wrt -fcatch-undefined-

behavior, and within the last week or so something changed such that my
own build of clang (built with CMake on OS X) is unable to build simple
programs that use -fcatch-undefined-behavior, I get link errors like:

“___ubsan_handle_divrem_overflow”, referenced from:
_main in test-OSZvjm.o
“___ubsan_handle_type_mismatch”, referenced from:
_main in test-OSZvjm.o

Any ideas why?

This is a new feature. Instead of generating traps, -fcatch-undefined-
behavior generates library calls that make it easier to find what is
wrong (each undefined behavior calls a different function).

This functions are provided by the ubsan library that is part of
compiler-rt. But I’m not sure the integration to the Makefile build
system is done yet.

You mean with the CMake build system?

Generally “Makefile build system” describes the configure+make build
system (at least when it’s discussed here).

Perhaps if I build using autotools it will work? Or do you mean it

works nowhere yet?

I believe the implication is that it works with the CMake build
system. But you will need to checkout the compiler-rt LLVM project
into llvm/projects to build it along with clang. (& I assume you’ll
need to install compiler-rt alongside clang as well, but hopefully the
install target does that)

As I said in my original post, I am using CMake (not autotools aka configure+make). I do have llvm/projects.

My full little ‘build everything’ script is:


(cd ~/llvm/llvm/; svn up)
(cd ~/llvm/llvm/tools/clang; svn up)
(cd ~/llvm/llvm/projects/compiler-rt; svn up)

mkdir -p ~/llvm/llvm-rel-bin
rm -rf ~/llvm/llvm-rel-bin/*

mkdir -p ~/llvm/llvm-rel-install
rm -rf ~/llvm/llvm-rel-install/*

cd ~/llvm/llvm-rel-bin
CC="$(xcrun --find cc)" CXX="$(xcrun --find c++)" cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=OFF -DCMAKE_INSTALL_PREFIX=~/llvm/llvm-rel-install …/llvm
make -j16 install

Yep, it looks like the driver integration for the darwin toolchain is missing too.

The ubsan library should probably be append to the link flags somewhere in Toolchains.cpp:DarwinClang::AddLinkRuntimeLibArgs(), but I don’t see it anywhere.

Digging a little further, I found this in ubsan_value.h.

// For now, only support linux. Other platforms should be easy to add, and
// probably work as-is.
#if !defined(linux)

#error “UBSan not supported for this platform!”
#endif

Yes, as I can see ubsan runtime library is currently supported only in CMake build and is built on Linux only.

That’s unfortunate that clang try to emit function calls on platforms that does not support it.

Right now, we could just emit calls to @llvm.trap on unsupported platforms, but some of the remaining checks actually need runtime library support. I would prefer to get the runtime working on more platforms, rather than working around its absence.

That said, do you need patches for darwin/make integration, or are you already working on it (or planning to do it after usban is done on linux) ?

Patches to support Darwin are very much welcome. I don’t have a Darwin machine, so I’ve not added this support myself.

Thanks to all for the explanations.

I guess I'm playing with fire by using svn trunk, but for me, this is a big regression: -fcatch-undefined-behavior has gone from a imperfect but helpful tool to be totally broken. I do hope it'll work again before 3.2?

Cheers,

Yes, I’ve been promised access to a Mac, and I’ll get it working there, if no-one else gets there first :slight_smile:

I started to work on it by patching the build system (see patches in wait for review on cfe-commits).

I have a question though. Is there anything in the implementation of usban that is OS/ABI specific ?
I had a quick look at the implementation, and didn’t see any obvious reason it should not work on darwin as is.

– Jean-Daniel

Ubsan is a kind of umbrella flag which should, in the long run, encompass Asan and ThreadSanitizer. I suppose that in those latter two there might be OS/platform specific code.

– Matthieu

That’s unfortunate that clang try to emit function calls on platforms that
does not support it.

Right now, we could just emit calls to @llvm.trap on unsupported platforms,
but some of the remaining checks actually need runtime library support. I
would prefer to get the runtime working on more platforms, rather than
working around its absence.

Thanks to all for the explanations.

I guess I’m playing with fire by using svn trunk, but for me, this is a big regression: -fcatch-undefined-behavior has gone from a imperfect but helpful tool to be totally broken. I do hope it’ll work again before 3.2?

Yes, I’ve been promised access to a Mac, and I’ll get it working there, if no-one else gets there first :slight_smile:

I started to work on it by patching the build system (see patches in wait for review on cfe-commits).

I have a question though. Is there anything in the implementation of usban that is OS/ABI specific ?
I had a quick look at the implementation, and didn’t see any obvious reason it should not work on darwin as is.

– Jean-Daniel

Ubsan is a kind of umbrella flag which should, in the long run, encompass Asan and ThreadSanitizer.

asan or tsan, but not both at the same time. At least I don’t know how.

I suppose that in those latter two there might be OS/platform specific code.

Oh yes, quite a bit.

–kcc

Hi,

With 3.2 now in RC phase, I'd thought I'd pester about -fcatch-undefined-behavior on OS X... It worked in 3.1, will it be restored in 3.2? I don't see anything connected to it here:

<http://llvm.org/bugs/show_bug.cgi?id=13893>

Do you need a bug report?

Cheers,

Thanks for the prod, I've checked in some pending patches to add OS X
support, in r167888, r167889, and r167890. If you could build
clang_rt.ubsan_osx and let me know whether everything is working as
intended, that'd be great; we can then ask to get those patches pulled
onto the 3.2 branch.

If nothing is done in the mean time, I will have a look at the actual state of ubsan to see what remain to be done to make it work on OS X tonight (CET), and will post the required patches (for compiler-rt and the clang driver).

-- Jean-Daniel

I've rebuilt clang r167897 and still get link errors, ex:

Undefined symbols for architecture x86_64:
  "___ubsan_handle_shift_out_of_bounds", referenced from:

Cheers,

I don't have a Darwin machine to test against. Does the attached patch help?

driver-ubsan-darwin.diff (2.41 KB)