abi

I'm trying to build a unit test with boost, but the linker complains about a missing function. Take this skeleton code #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_SUITE(TestFuncOps); BOOST_AUTO_TEST_CASE(CopyConstructor) { } BOOST_AUTO_TEST_SUITE_END(); But it fails with Undefined symbols for architecture x86_64: "boost::unit_test::ut_detail::normalize_test_case_name[abi:cxx11](boost::unit_test::basic_cstring<char const>)", referenced from: __GLOBAL__sub_I_funcopstest.cc in funcopstest.o The libboost_unit_test_framework is found by my

The ELF Handling For Thread-Local Storage document gives assembly sequences for the various models (local exec/initial exec/general dynamic) for various architectures. But not ARM -- is there anywhere I can see such code sequences for ARM? I'm working on a compiler and want to generate code that will operate properly with the platform linkers (both program and dynamic). For clarity, let's assume an ARMv7 CPU and a pretty new kernel and glibc (say 3.13+ / 2.19+), but I'd also be interested in what has to change for older hw/sw if that's easy to explain. I don't exactly understand what you want.

I try to use the ubuntu 15.10 repository version of libmuparser (package libmuparser2v5). Compiling with gcc works fine, but not with clang. I dug deeper into this to come up with the following minimal (not) working example and a few questions. Consider a library with a simple class that takes a string and returns a string . testlib.h : #pragma once #include <string> struct Test { std::string str; void set(std::string s); std::string get(); }; testlib.cpp : #include "testlib.h" void Test::set(std::string s) { str = s; } std::string Test::get() { return str; } This is compiled with gcc 5.2.1 as

The x86_64 SysV ABI 's function calling convention defines integer argument #4 to be passed in the rcx register. The Linux kernel syscall ABI, on the other hand, uses r10 for that same purpose. All other arguments are passed in the same registers for both functions and syscalls. This leads to some strange things. Check out, for example, the implementation of mmap in glibc for the x32 platform (for which the same discrepancy exists): 00432ce0 <__mmap>: 432ce0: 49 89 ca mov %rcx,%r10 432ce3: b8 09 00 00 40 mov $0x40000009,%eax 432ce8: 0f 05 syscall So all register are already in place, except we

Is it meant to be guaranteed that same std::type_info::hash_code() values imply same types? Cplusplus.com seems to claim so: This function returns the same value for any two type_info objects that compare equal, and different values for distinct types that do not. [Emphasis mine] Cppreference seems to claim otherwise: Returns an unspecified value, which is identical for objects, referring to the same type. No other guarantees are given , in particular, the value can change between invocations of the same program. [Emphasis mine] The relevant standards paragraphs are: § p18.7.1 p7-8 size_t hash

I read that when a function call is made by a program, the called function must know how to return to its caller. My question is: How does the called function know how to return to its caller? Is there a mechanism working behind the scenes through the compiler? The compiler obeys a particular "calling convention", defined as part of the ABI you're targeting. That calling convention will include a way for the system to know what address to return to. The calling convention usually takes advantage of the hardware's support for procedure calls. On Intel, for example, the return address is pushed

STL Binary Interfaces I'm curious to know if anyone is working on compatible interface layers for STL objects across multiple compilers and platforms for C++. The goal would be to support STL types as first-class or intrinsic data types. Is there some inherent design limitation imposed by templating in general that prevents this? This seems like a major limitation of using the STL for binary distribution. Theory - Perhaps the answer is pragmatic Microsoft has put effort into .NET and doesn't really care about C++ STL support being "first class". Open-source doesn't want to promote binary-only

I recently installed LLVM v8.0.0 (on RHEL 7.4). I am going through the LLVM Kaleidoscope tutorial to learn how to use the system, but am running into an issue linking. Per the tutorial ( end of chapter 2 ), I run: clang++ -g -O3 kld.cpp `llvm-config --cxxflags` -o kld It compiles, but the linker fails on: /tmp/kld-f7264f.o:(.data+0x0): undefined reference to `llvm::EnableABIBreakingChecks' clang-8: error: linker command failed with exit code 1 (use -v to see invocation) I suspected this may have been an issue with llvm-config , so I also tried using the --ldflags and --system-libs flags, but

I'm trying to write a quick-and-dirty demangler for clang. I've found a piece of code that uses abi::__cxa_demangle , but I can't figure out which header it requires. The obvious choice is ABI.h but: demangle.cpp:2:10: fatal error: 'ABI.h' file not found #include <ABI.h> ^ What do I need to use abi::__cxa_demangle ? Include cxxabi.h . In Ubuntu 13 this header is in /usr/include/c++/4.x where x is minor gcc version. Include cxxabi.h, but for clang on Ubuntu you'll need to install the package libc++abi-dev. 来源： https://stackoverflow.com/questions/19329525/how-to-demangle-a-c-name-in-clang-or-gcc