abi

问题 From a discussion somewhere else: C++ has no standard ABI But neither does C, right? On any given platform it pretty much does. It wouldn\'t be useful as the lingua franca for inter-language communication if it lacked one. What\'s your take on this? 回答1: C defines no ABI. In fact, it bends over backwards to avoid defining an ABI. Those people, who like me, who have spent most of their programming lives programming in C on 16/32/64 bit architectures with 8 bit bytes, 2's complement arithmetic

问题 In the assembly of the C++ source below. Why is RAX pushed to the stack? RAX, as I understand it from the ABI could contain anything from the calling function. But we save it here, and then later move the stack back by 8 bytes. So the RAX on the stack is, I think only relevant for the std::__throw_bad_function_call() operation ... ? The code:- #include <functional> void f(std::function<void()> a) { a(); } Output, from gcc.godbolt.org , using Clang 3.7.1 -O3: f(std::function<void ()>): # @f

问题 I can understand this requirement for the old PPC RISC systems and even for x86-64, but for the old tried-and-true x86? In this case, the stack needs to be aligned on 4 byte boundaries only. Yes, some of the MMX/SSE instructions require 16byte alignments, but if that is a requirement of the callee, then it should ensure the alignments are correct. Why burden every caller with this extra requirement? This can actually cause some drops in performance because every call-site must manage this

问题 Anyone have a reference for the representation of va_list in the x86_64 ABI (the one used on Linux)? I\'m trying to debug some code where the stack or arguments seem corrupt and it would really help to understand what I\'m supposed to be seeing... 回答1: I made my comment into an answer. This may help. It's a reference, albeit lightweight ( EDIT : original link dead; replaced Wayback Machine-preserved link). The Variable Argument List reference starts on page 50, then it goes on, page 52-53

问题 I know that an \"undefined behaviour\" in C++ can pretty much allow the compiler to do anything it wants. However, I had a crash that surprised me, as I assumed that the code was safe enough. In this case, the real problem happened only on a specific platform using a specific compiler, and only if optimization was enabled. I tried several things in order to reproduce the problem and simplify it to the maximum. Here\'s an extract of a function called Serialize , that would take a bool

问题 Suppose I have three compiled objects, all produced by the same compiler/version : A was compiled with the C++11 standard B was compiled with the C++14 standard C was compiled with the C++17 standard For simplicity, let\'s assume all headers were written in C++11, using only constructs whose semantics haven\'t changed between all three standard versions , and so any interdependencies were correctly expressed with header inclusion and the compiler did not object. Which combinations of these

问题 I\'ve read in different places that it is done for \"performance reasons\", but I still wonder what are the particular cases where performance get improved by this 16-byte alignment. Or, in any case, what were the reasons why this was chosen. edit : I\'m thinking I wrote the question in a misleading way. I wasn\'t asking about why the processor does things faster with 16-byte aligned memory, this is explained everywhere in the docs. What I wanted to know instead, is how the enforced 16-byte

问题 From wiki Executable and Linkable Format: The segments contain information that is necessary for runtime execution of the file, while sections contain important data for linking and relocation. Any byte in the entire file can be owned by at most one section, and there can be orphan bytes which are not owned by any section. But what\'s difference between section and segment? In an executable ELF file, does a segment contain one or more sections? 回答1: But what's difference between section and

问题 Summary: I was looking at assembly code to guide my optimizations and see lots of sign or zero extensions when adding int32 to a pointer. void Test(int *out, int offset) { out[offset] = 1; } ------------------------------------- movslq %esi, %rsi movl $1, (%rdi,%rsi,4) ret At first, I thought my compiler was challenged at adding 32bit to 64bit integers, but I\'ve confirmed this behavior with Intel ICC 11, ICC 14, and GCC 5.3. This thread confirms my findings, but it\'s not clear if the sign

问题 I believe I understand how the linux x86-64 ABI uses registers and stack to pass parameters to a function (cf. previous ABI discussion). What I\'m confused about is if/what registers are expected to be preserved across a function call. That is, what registers are guarenteed not to get clobbered? 回答1: Here's the complete table of registers and their use from the documentation [PDF Link]: r12 , r13 , r14 , r15 , rbx , rsp , rbp are the callee-saved registers - they have a "Yes" in the