search for: elfv2

Hi all, I'm trying to understand which ABIs are supported in the PowerPC backend and I'm getting a bit confused. Here's what I've gathered so far alongside with some questions. - In PPCSubtarget.h there's DarwinABI, SVR4ABI and ELFv2ABI. - The CodeGenerator documentation claims that the AIX PowerPC ABI is followed (with some deviations). Is this refering to the DarwinABI? - In a recent commit a TargetABI value and enumeration was added to PPCSubtarget which contains PPC_ABI_UNKNOWN, PPC_ABI_ELFv1 and PPC_ABI_ELFv2. For 64-bit n...

...ide with some questions. > > Sorry for the confusion, this all should probably be cleaned up a > bit. > In general, LLVM today supports the following ABIs: > - The Darwin ABI (32-bit and 64-bit flavors) > - The 32-bit SVR4 ABI > - Two variants of the 64-bit SVR4 ABI: ELFv1 and ELFv2 > > The ELFv1 ABI is used on 64-bit big-endian Linux and AIX. > The ELFv2 ABI is used on 64-bit little-endian Linux. > > Unfortunately, the term "SVR4" is quite overloaded, and applies > both to the 32-bit and the 64-bit ABIs, even though they are > quite different....

...klibc.git;a=commit;h=6e2976b9d103fb37a6a06e5bccb323fa5ab1c53b Author: Mauricio Faria de Oliveira <mauricfo at linux.vnet.ibm.com> AuthorDate: Wed, 6 Jan 2016 00:43:10 +0000 Committer: H. Peter Anvin <hpa at linux.intel.com> CommitDate: Tue, 5 Jan 2016 17:45:31 -0800 [klibc] ppc64: ELFv2: Load TOC value in system call stub This fixes a segmentation fault in the system call's error handling path with dynamically-linked binaries on PowerPC64 little endian. The system call stub wasn't loading up r2 with the appropriate TOC value in its global entry point. The r2 setup code...

...alongside with some questions. > > Sorry for the confusion, this all should probably be cleaned up a bit. > In general, LLVM today supports the following ABIs: > - The Darwin ABI (32-bit and 64-bit flavors) > - The 32-bit SVR4 ABI > - Two variants of the 64-bit SVR4 ABI: ELFv1 and ELFv2 > > The ELFv1 ABI is used on 64-bit big-endian Linux and AIX. > The ELFv2 ABI is used on 64-bit little-endian Linux. > > Unfortunately, the term "SVR4" is quite overloaded, and applies > both to the 32-bit and the 64-bit ABIs, even though they are > quite different....

...ly-linked binaries on PowerPC64 little endian. The system call stub wasn't loading up r2 with the appropriate TOC value in its global entry point. The r2 setup code comes from the FUNC_START macro in gcc [1] and an equivalent one can also be found in the LOCALENTRY macro in glibc [2]. On the ELFv2 ABI (see [1]): - The global entry point is expected to load up r2 with the appropriate TOC value for this function. - The local entry point expects r2 to be set up to the current TOC. The problem happened with dynamically-linked binaries because: - the system call is an indirect call (via gl...

.... Ben. Aurelien Jarno (1): ppc64: fix struct stat Ben Hutchings (2): MIPS: Update archfcntl.h syscalls: Override detection of direct socket syscalls on i386, m68k, s390 Helge Deller (1): Add pread and pwrite 32bit syscall wrappers for parisc Mauricio Faria de Oliveira (1): ppc64: ELFv2: Load TOC value in system call stub usr/include/arch/i386/klibc/archconfig.h | 3 +++ usr/include/arch/m68k/klibc/archconfig.h | 3 +++ usr/include/arch/mips/klibc/archfcntl.h | 22 +++++++++++++++++++++- usr/include/arch/ppc64/klibc/archstat.h | 1 + usr/include/arch/s390/klibc/archconfig.h...

...mp [klibc] mips64: remove __unused from __jmp_buf Jay Vosburgh (1): [klibc] ipconfig: handle multiple interfaces correctly Mathieu Trudel-Lapierre (1): [klibc] ipconfig: Set broadcast when sending DHCPREQUEST and DHCPDISCOVER Mauricio Faria de Oliveira (1): [klibc] ppc64: ELFv2: Load TOC value in system call stub -- Ben Hutchings Hoare's Law of Large Problems: Inside every large problem is a small problem struggling to get out. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size:...

On 30 Jul 2014, at 21:29, Ulrich Weigand wrote: > The ELFv1 ABI is used on 64-bit big-endian Linux and AIX. There's one small difference between the two: with the 64 bit ELFv1/ SVR4 ABI, tail padding for structs passed by value is only performed in case the struct is larger than 8 bytes, while for AIX 64 bit it's always done. As an aside, on Darwin/ppc64 it's done if the

> On Jun 2, 2020, at 4:21 PM, comex via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > While this is a different area of the codebase, another thing that > would benefit greatly from being moved out of Clang is function call > ABI handling. Currently, that handling is split awkwardly between > Clang and LLVM proper, forcing frontends that implement C FFI to > either

...aggregate that comes from a method argument based on the format of the aggregate (Here, { i64, i32, i32 } instead of [2 x i64]). I have submitted a work-in-progress patch in Phabricator ( https://reviews.llvm.org/D32998 ). This optimization depends on the ABI, so I enabled this only for ppc64 with ELFv2 ABI so far. I truly appreciate any advices and comments. Best regards, Hiroshi ----- Hiroshi Inoue <inouehrs at jp.ibm.com> IBM Research - Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170509/...

...reflecting the extra information that the ABI rules require the > backend to > know about the type. E.g., for X86_64, clang needs to inform LLVM of > the > classification for each parameter's type into MEMORY, INTEGER, SSE, > SSEUP, > X87, X87UP, COMPLEX_X87. Or, for PPC64 elfv2, Clang needs to inform > LLVM > when a structure should be treated as a "homogenous aggregate" of > floating-point or vector type. (In both cases, that information cannot > correctly be extracted from the LLVM IR struct type, only from the C > type > system.) These at...

Hey all, I volunteered to put together a proposal regard complex in LLVM. Consider the following to be a strawman meant to spark discussion. It's based on real-world experience with complex but is not expected to cover all use-cases. Proposal to Support Complex Operations in LLVM ---------------------------------------------- Abstract Several vendors and individuals have proposed