[cfe-users] Clang7 UBSan + -fvisibility-hidden
Dear all,
We are currently investigating a possible undefined behaviour in our
program that is flagged by clang7 UBSan in combination with
boost::program_option from boost 1.69.0. We have created the following
working example that can we compiled and run with clang++ -std=c++17
-fsanitize=undefined -fno-omit-frame-pointer -lboost_program_options
debug.cpp && UBSAN_OPTIONS=print_stacktrace=1 ./a.out
#include
#include
namespace po = boost::program_options;
int main() {
std::string test_string = "";
po::options_description desc("test");
desc.add_options()
("string", po::value(&test_string))
;
constexpr char *argv[] = {"test", "--string", "test"};
constexpr int argc = sizeof(argv) / sizeof(char*);
po::variables_map vm;
po::store(po::parse_command_line(argc, argv, desc), vm);
std::cerr << "Before notify" << std::endl;
po::notify(vm);
std::cout << "string -> " << test_string << std::endl;
}
We get the following output:
/usr/include/boost/any.hpp:249:17: runtime error: downcast of address
0x5638e42892e0 which does not point to an object of type
'any::holder,
allocator > >::type>' (aka
'holder,
std::allocator > >')
0x5638e42892e0: note: object is of type
'boost::any::holder, std::allocator > >'
00 00 00 00 00 55 f9 63 28 7f 00 00 f8 92 28 e4 38 56 00 00 04 00 00
00 00 00 00 00 74 65 73 74
^~~
vptr for
'boost::any::holder, std::allocator > >'
#0 0x5638e1b06d6e in std::__cxx11::basic_string, std::allocator >*
boost::any_cast,
std::allocator > >(boost::any*)
(/home/gereon/carl/src/tests/carl-settings/a.out+0x4cd6e)
#1 0x5638e1b0672c in std::__cxx11::basic_string, std::allocator > const*
boost::any_cast,
std::allocator > >(boost::any const*)
(/home/gereon/carl/src/tests/carl-settings/a.out+0x4c72c)
#2 0x5638e1b03625 in
boost::program_options::typed_value, std::allocator >, char>::notify(boost::any
const&) const (/home/gereon/carl/src/tests/carl-settings/a.out+0x49625)
#3 0x7f2863f6a71e in boost::program_options::variables_map::notify()
(/usr/lib/libboost_program_options.so.1.69.0+0x5771e)
#4 0x5638e1afa2ae in main
(/home/gereon/carl/src/tests/carl-settings/a.out+0x402ae)
#5 0x7f2863a13222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
#6 0x5638e1ad33ad in _start
(/home/gereon/carl/src/tests/carl-settings/a.out+0x193ad)
/usr/include/boost/any.hpp:249:114: runtime error: member access within
address 0x5638e42892e0 which does not point to an object of type
'any::holder,
allocator > >::type>' (aka
'holder,
std::allocator > >')
0x5638e42892e0: note: object is of type
'boost::any::holder, std::allocator > >'
00 00 00 00 00 55 f9 63 28 7f 00 00 f8 92 28 e4 38 56 00 00 04 00 00
00 00 00 00 00 74 65 73 74
^~~
vptr for
'boost::any::holder, std::allocator > >'
#0 0x5638e1b06e36 in std::__cxx11::basic_string, std::allocator >*
boost::any_cast,
std::allocator > >(boost::any*)
(/home/gereon/carl/src/tests/carl-settings/a.out+0x4ce36)
#1 0x5638e1b0672c in std::__cxx11::basic_string, std::allocator > const*
boost::any_cast,
std::allocator > >(boost::any const*)
(/home/gereon/carl/src/tests/carl-settings/a.out+0x4c72c)
#2 0x5638e1b03625 in
boost::program_options::typed_value, std::allocator >, char>::notify(boost::any
const&) const (/home/gereon/carl/src/tests/carl-settings/a.out+0x49625)
#3 0x7f2863f6a71e in boost::program_options::variables_map::notify()
(/usr/lib/libboost_program_options.so.1.69.0+0x5771e)
#4 0x5638e1afa2ae in main
(/home/gereon/carl/src/tests/carl-settings/a.out+0x402ae)
#5 0x7f2863a13222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
#6 0x5638e1ad33ad in _start
(/home/gereon/carl/src/tests/carl-settings/a.out+0x193ad)
string -> test
As we can see it runs fine (test_string has the correct value
afterwards). We have investigated into boost::program_options and
boost::any and found the following: In
program_options::typed_value::notify() (#2) we get a boost::any and cast
it to the type it is supposed to be by calling boost::any_cast().
Considering clang's output (downcast of address 0x5638e42892e0 which
does not point to an object of type 'any::holder, allocator >
>::type>' (aka 'holder, std::allocator > >') and object is of type
'boost::any::holder, std::allocator > >') we can only conclude
that this boost::any instance in fact holds the correct member... in
which case the downcast should be legal.
UBSan however states that no false positives are to be expected.
Interestingly we are not able to reproduce this error without
program_options in the mix:
#include
#include
void any_cast(const boost::any& a) {
const std::string* t2 = boost::any_cast(&a);
std::cout << *t2 << std::endl;
}
int main() {
boost::any a;
a = std::string("test");
any_cast(a);
}
Hence we suspect that (the precompiled) program_options may somehow mess
with the std::string type.
By the w
[cfe-users] Linking error and memory bloating for .so file creation
Hi Team, During the linking stage for an “.so” file creation, an error message is being flagged by clang. *ld: error: dummy.so: write: Function not implemented* I'm not able to make a sense out of this message as it seems different from an "undefined reference" error. There are multiple occurrence of this message during the linking process. Also the linking doesn’t complete and the output “.so” keeps on bloating reaching size upto 1TB or 100s of GB. Manual termination is required to stop this process. Any leads would be appreciated. -- Thanks and Regards Ankush ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
[cfe-users] Manipulating the DeclContext
Hello! I'm looking for some help in understanding how a DeclContext is created within Clang. More specifically, I'm curious to know how and when a DeclContext's members are added so that I can safely manipulate their order. If I understand it correctly, this order is based on a linked list which is iterated over when it's time to construct the layout. The first member of the linked list being FirstDecl: https://clang.llvm.org/doxygen/classclang_1_1DeclContext.html#a6c8abf07fec5ca0ea9473e4df302191f The linked list being generated with BuildDeclChain: https://clang.llvm.org/doxygen/classclang_1_1DeclContext.html#aeed74fdf591aa2cbf15c4170499b64da And of course, iterating the fields with the begin and end iterators: https://clang.llvm.org/doxygen/classclang_1_1RecordDecl.html#afc36412f0657ec2e9810e6f9d321b29a I'm trying to rearrange the order of fields within a RecordDecl before the record layout is finalized in lib/AST/RecordLayoutBuilder.cpp in which the record builder implementations do all of the low-level offset calculations based on the traversal of that linked list. I'm avoiding providing an ExternalASTSource that overrides the structure layout on the virtue that the only thing here that's changing is the order of the fields and it seems wasteful to re-implement the RecordLayoutBuilders' battle-hardened code in the ExternalASTSource to calculate the offsets. I've got a basic version of this "working" for simple projects where fields are reordered as I want them to. However, I know there's a lot of machinery in the compiler and _I also don't know what I don't know_. Compiling more complicated projects, like the Linux kernel, results in a seg-faulting compiler when it comes to code generation on a call to "clang::TagType::getDecl()", and this is where my question stems from. The current approach involves modifying BuildDeclChain to set a tail pointer: https://github.com/clang-randstruct/llvm-project/commit/3b49de55975539e72279c7c45a4679c57aceea2a Followed by invoking it with a new order of the FieldDecls: https://github.com/clang-randstruct/llvm-project/commit/af8ec9eafa1379a89a73183b88a46fb047c97d99#diff-88e7d1cb846dd215c4ab0a4fc7b5b57eR55 (Though I believe the boolean argument in that method call is wrong) I think I'm compromising the integrity of the DeclContext somehow and am hoping for some guidance on mending it. Any advice or further questions are greatly appreciated. Thank you. Connor___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] How do I make CMake use LLD
I was just setting the flag for the C++ compiler wrapper, but doing the same for the C compiler seems to work (on ppc64le linking with LLD fails though). On Tue, Mar 5, 2019 at 12:07 AM David Blaikie wrote: > Generally the linker is invoked via the compiler wrapper (eg: "clang x.o > y.o" to produce a.out), so you can add to your linker flags "-fuse-ld=lld" > to tell the compiler wrapper to lld. > > On Mon, Mar 4, 2019 at 7:06 AM Itaru Kitayama via cfe-users < > cfe-users@lists.llvm.org> wrote: > >> Hi, >> Keeping the system linker as GNU ld, how do I make CMake use LLD >> at configure time? alias ld='lld' does not seem to work. >> ___ >> cfe-users mailing list >> cfe-users@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users >> > ___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Linking error and memory bloating for .so file creation
> On Mar 7, 2019, at 00:24, Ankush Sharma via cfe-users > wrote: > > Hi Team, > > During the linking stage for an “.so” file creation, an error message is > being flagged by clang. > ld: error: dummy.so: write: Function not implemented > > I'm not able to make a sense out of this message as it seems different from > an "undefined reference" error. There are multiple occurrence of this message > during the linking process. > Also the linking doesn’t complete and the output “.so” keeps on bloating > reaching size upto 1TB or 100s of GB. Manual termination is required to stop > this process. > > Any leads would be appreciated. Just a guess, but perhaps this is not a linking error at all. This looks to me like ld calling write() and the call itself returning ENOSYS. Is there something unusual about the filesystem you’re writing dummy.so to? If the write fails but the file size also increases, I wonder if what you’re seeing is some sort of I/O error. Anything exciting in dmesg and friends?___ cfe-users mailing list cfe-users@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
