abi

Where exactly is the red zone on x86-64?

血红的双手。 提交于 2019-11-27 06:35:45
问题 From Wikipedia: In computing, a red zone is a fixed-size area in a function's stack frame beyond the return address which is not preserved by that function. The callee function may use the red zone for storing local variables without the extra overhead of modifying the stack pointer. This region of memory is not to be modified by interrupt/exception/signal handlers. The x86-64 ABI used by System V mandates a 128-byte red zone, which begins directly after the return address and includes the

Why can't kernel code use a Red Zone

笑着哭i 提交于 2019-11-27 05:01:39
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? 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 this area for temporary data that is not needed across function calls. In particular, leaf functions may use

How to avoid STT_GNU_IFUNC symbols in your binary?

允我心安 提交于 2019-11-27 02:14:51
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" type on my binary but found none. I ask this because some of my other binaries as well as some 3rd party

Using Scala 2.12 with Spark 2.x

|▌冷眼眸甩不掉的悲伤 提交于 2019-11-27 02:06:15
问题 At the Spark 2.1 docs it's mentioned that Spark runs on Java 7+, Python 2.6+/3.4+ and R 3.1+. For the Scala API, Spark 2.1.0 uses Scala 2.11. You will need to use a compatible Scala version (2.11.x). at the Scala 2.12 release news it's also mentioned that: Although Scala 2.11 and 2.12 are mostly source compatible to facilitate cross-building, they are not binary compatible. This allows us to keep improving the Scala compiler and standard library. But when I build an uber jar (using Scala 2.12

glibc: elf file OS ABI invalid

◇◆丶佛笑我妖孽 提交于 2019-11-27 01:49:20
问题 downloaded and compiled glibc-2.13. when i try to run a sample C program which does a malloc(). I get following error elf file OS ABI invalid Can anybody please pass my any pointer helpful in resolving this issue.Please note that my kernel version is linux-2.6.35.9 回答1: It's not your kernel version that's the problem. The loader on your system does not support the new Linux ABI. Until relatively recently, Linux ELF binaries used the System V ABI. Recently, in support of STT_GNU_IFUNC, the

g++ always backward-compatible with “older” static libraries?

南楼画角 提交于 2019-11-27 01:27:41
问题 I have a few static libraries, which I'm not the owner of, compiled with an old version of g++ 4.3.2 (c++11/c++0x not activated). When I compile my code with g++ 4.6 (no c++11) and link it using g++ 4.6 with these static libraries, it links fine and I do not seem to get any issues at runtime (not tested everything though). I'm tempted to think that forward compatibility is OK. Now I'd like to compile my code with gcc 4.8 with c++11 and still link it with those same, not recompiled static

Difference between API and ABI

与世无争的帅哥 提交于 2019-11-26 23:45:30
问题 I am new to linux system programming and I came across API and ABI while reading Linux System Programming . Definition of API : An API defines the interfaces by which one piece of software communicates with another at the source level. Definition of ABI : Whereas an API defines a source interface, an ABI defines the low-level binary interface between two or more pieces of software on a particular architecture. It defines how an application interacts with itself, how an application interacts

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

落花浮王杯 提交于 2019-11-26 23:24:37
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 reasons for or against this? Since it might not be obvious to everyone what I'm talking about here, I'll

i386 vs. AMD64 ABI Differences

眉间皱痕 提交于 2019-11-26 21:52:38
问题 Where can I find all the differences in data types between the i386 & AMD64 Application Binary Interface(ABI)s ? I know that the long type is 32-bit in i386 ABI & 64-bit in AMD64. Is this correct? 回答1: I suggest you download Dr Agner Fog's optimization manuals. He has a manual specifically about ABIs and their differences. For differences in the instruction set between 32-bit mode and 64-bit mode, both Intel and AMD's instruction manuals should cover this in the introductory volume or the

Is it safe to link C++17, C++14, and C++11 objects

对着背影说爱祢 提交于 2019-11-26 21:37:48
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 objects is it and isn't it safe to link into a single binary? Why? EDIT: answers covering major compilers