abi | 易学教程

Why does the Mac ABI require 16-byte stack alignment for x86-32?

阅读更多关于 Why does the Mac ABI require 16-byte stack alignment for x86-32?

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 requirement. Am I missing something? Update: After some more investigation into this and some consultation

What is the format of the x86_64 va_list structure?

阅读更多关于 What is the format of the x86_64 va_list structure?

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... Skurmedel 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 documents va_list : The va_list Type The va_list type is an array containing a single element of one

What could C/C++ “lose” if they defined a standard ABI?

阅读更多关于 What could C/C++ “lose” if they defined a standard ABI?

问题 The title says everything. I am talking about C/C++ specifically, because both consider this as "implementation issue". I think, defining a standard interface can ease building a module system on top of it, and many other good things. What could C/C++ "lose" if they defined a standard ABI? 回答1: The freedom to implement things in the most natural way on each processor. I imagine that c in particular has conforming implementations on more different architectures than any other language. Abiding

Why does System V / AMD64 ABI mandate a 16 byte stack alignment?

阅读更多关于 Why does System V / AMD64 ABI mandate a 16 byte stack alignment?

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 alignment is better than just letting the programmers align the stack themselves when needed. I'm asking this

How do C compilers implement functions that return large structures?

阅读更多关于 How do C compilers implement functions that return large structures?

问题 The return value of a function is usually stored on the stack or in a register. But for a large structure, it has to be on the stack. How much copying has to happen in a real compiler for this code? Or is it optimized away? For example: struct Data { unsigned values[256]; }; Data createData() { Data data; // initialize data values... return data; } (Assuming the function cannot be inlined..) 回答1: None; no copies are done. The address of the caller's Data return value is actually passed as a

How to avoid STT_GNU_IFUNC symbols in your binary?

阅读更多关于 How to avoid STT_GNU_IFUNC symbols in your binary?

问题 I need to deploy to a Red Hat 4.1.2 box (which has gcc 4.1.2). I use GCC 4.6.1 on Ubuntu 11.10 for development. Unfortunately some of the binaries that my build process creates are not usable on the RedHat machine. The reason seems to be an ABI change, which according to another Stackoverflow question resulted from the introduction of STT_GNU_IFUNC symbols. Is there a way to prevent exporting any such symbols so that my binary can use the old ABI? I used nm to look for any symbols of \"i\"

Are there any downsides to passing structs by value in C, rather than passing a pointer?

阅读更多关于 Are there any downsides to passing structs by value in C, rather than passing a pointer?

问题 Are there any downsides to passing structs by value in C, rather than passing a pointer? If the struct is large, there is obviously the performancd aspect of copying lots of data, but for a smaller struct, it should basically be the same as passing several values to a function. It is maybe even more interesting when used as return values. C only has single return values from functions, but you often need several. So a simple solution is to put them in a struct and return that. Are there any

【转】关于Android的.so文件你所需要知道的(二)

阅读更多关于【转】关于Android的.so文件你所需要知道的(二)

Androidndk开发打包时我们应该如何注意平台的兼容（x86,arm,arm-v7a）很多朋友在开发Android JNI的的时候，会遇到findlibrary returned null的错误，因为某种原因，so没有打包到apk中。下面浅析下引起该错误的原因以及平台兼容性问题。一、没有将so打包到apk中的原因。当你发现到findlibrary returned null的错误时，其实最直接的解决办法就是解压apk，看看apk中的x86、armeabi、armeabi-v7a文件夹中是否有对应的so，此时你可能在对应的文件夹下发现少了so，然后再去查原因即可。一般有两方面的原因: 1.apk中有对应平台的文件夹，但是文件夹里却没有对应的so。举个例子，apk中lib下面一旦出现x86文件夹，程序运行的时候就会去加载x86对应的库，但是如果此时x86文件夹没有将so放进来，则会遇到报错。 2.第三方对平台的兼容策略与自己不一致。可能第三方选择了只支持armeabi（假设某支付sdk），但是我们的游戏在Application.mk中配置了APP_ABI := all，如此，我们的游戏打包出了所有平台的so，但是第三方却只有armeabi文件夹对应的so，造成程序运行异常，这种情况在开发期间最常见，一些小公司由于测试人员不足或者测试设备不足

GCC ABI compatibility

阅读更多关于 GCC ABI compatibility

问题 As far as I\'ve understood, it is not possible to link libraries that use different versions of GCC\'s Application Binary Interface (ABI). Are there ABI changes to every version of GCC? Is it possible to link a library built with 4.3.1 if I use, say, GCC 4.3.2? Is there a matrix of some sort that lists all the ways I can combine GCC versions? 回答1: The official ABI page points to an ABIcheck. This tool may do, what you want. 回答2: Since gcc-3.4.0, the ABI is forward compatible. I.E. a library

Why can't kernel code use a Red Zone

阅读更多关于 Why can't kernel code use a Red Zone

问题 It is highly recommended when creating a 64-bit kernel (for x86_64 platform), to instruct the compiler not to use the 128-byte Red Zone that the user-space ABI does. (For GCC the compiler flag is -mno-red-zone ). The kernel would not be interrupt-safe if it is enabled. But why is that? 回答1: Quoting from the AMD64 ABI: The 128-byte area beyond the location pointed to by %rsp is considered to be reserved and shall not be modified by signal or interrupt handlers. Therefore, functions may use