similar to: [LLVMdev] [lld] Relocation sections format: .rela / .rel

I think the linking context should decide whether to use rel (or) rela. This is also needed if --emit-relocations option is chosen (or) -r option is used. Thoughts ? Sent from my iPhone > On Jan 19, 2014, at 15:01, Simon Atanasyan <simon at atanasyan.com> wrote: > > Hi, > > Now lld writes relocations to the ".rela" sections only. Mips requires > to use the

Hi Rui, Shankar, Do we really need empty TargetLayout class? No we have the following hierarchy: Layout <- DefaultLayout<> <- TargetLayout<> <- xxxTargetLayout<> I suggest to remove TargetLayout and rename DefaultLayout to TargetLayout. Thoughts? -- Simon Atanasyan

Good point. But I suggest to do that by two steps. First, remove TargetLayout and rename DefaultLayout to TargetLayout. Second, merge TargetLayout and Layout. The first step is easy, the second step generates large diff, requires reviewing etc. On Fri, Apr 3, 2015 at 10:40 PM, Rui Ueyama <ruiu at google.com> wrote: > I'm wondering if we even need TargetLayout. > > DefaultLayout

Hi, Thanks a lot for your answer. It seems lld is still the best solution, even if it does not work "right out of the box" for us today. We already have a solution for the "objcopy" part (added the required output format to llvm-objdump). The ScriptLayout class seems to be empty for now (on the master branch at least), but we do not need linker scripts today. All that is

Hi, We are currently developing an LLVM-based compilation toolchain for a micro-controller, but would need some advice about whether we should use lld as linker. So far we managed to write a basic target handler to read ELF files generated by llc and link them (and relocations seem to be applied correctly). But we have target-specific requirements: - the program will be loaded into memory as-is,

Create a configurable hole in the linear address space at the top of memory. A more advanced interface is needed to negotiate how much space the hypervisor is allowed to steal, but in the end, it seems most likely that a fixed constant size will be chosen for the compiled kernel, potentially propagated to an information page used by paravirtual initialization to determine interface compatibility.

Create a configurable hole in the linear address space at the top of memory. A more advanced interface is needed to negotiate how much space the hypervisor is allowed to steal, but in the end, it seems most likely that a fixed constant size will be chosen for the compiled kernel, potentially propagated to an information page used by paravirtual initialization to determine interface compatibility.

Debug info linking is currently broken due to how we handle reading and laying out non SHF_ALLOC sections. I posted a patch that partially fixes this, but it's both the wrong approach and doesn't handle multiple input files with debug info (wrong relocation values). The first issue is representing non SHF_ALLOC atoms in the Atom model. We currently don't have a type for this, and

Hi Michael, On 9/16/2013 7:23 PM, Michael Spencer wrote: > Debug info linking is currently broken due to how we handle reading and > laying out non SHF_ALLOC sections. I posted a patch that partially fixes > this, but it's both the wrong approach and doesn't handle multiple input > files with debug info (wrong relocation values). > > The first issue is representing non

On Mon, Sep 16, 2013 at 6:48 PM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi Michael, > > > On 9/16/2013 7:23 PM, Michael Spencer wrote: > >> Debug info linking is currently broken due to how we handle reading and >> laying out non SHF_ALLOC sections. I posted a patch that partially fixes >> this, but it's both the wrong approach and

Hi Andi, Here's a couple of patches to fix up COMPAT_VDSO: The first is a straightforward implementation of Jan's original idea of relocating the VDSO to match its mapped location. Unlike Jan and Zach's version, I changed it to relocate based on the phdrs rather than the sections; the result is pleasantly compact. The second patch takes advantage of the fact that all the

Hi Andi, Here's a couple of patches to fix up COMPAT_VDSO: The first is a straightforward implementation of Jan's original idea of relocating the VDSO to match its mapped location. Unlike Jan and Zach's version, I changed it to relocate based on the phdrs rather than the sections; the result is pleasantly compact. The second patch takes advantage of the fact that all the

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

Hi Andi, Four patches: - clean up asm/bugs.h, by moving all the C code into its own C file - split identify_cpu() into boot and secondary variants, so that boot-time setup functions can be marked __init - repost of the COMPAT_VDSO patches with a bit more robustness from unknown DT_tags, and functions marked __init, since all this is boot-time only setup. Thanks, J --

The goal of this proposal is to introduce a new type of YAML section for yaml2obj that allows the population of ELF .dynamic entries via a list of tag and value pairs. These entries are interpreted (and potentially validated) before being written to the .dynamic section. The simplest way to satisfy this requirement is for all dynamic entry values to be numeric values. Unfortunately, this

Hola a tod@s Estoy trabajando con el paquete rela para analizar una muestra de 263 individuos. La idea es ver las posibilidades de hacer un análisis factorial y despues utilizar los factores para un análisis posterior. He obtenido, los valores del KMO, Barlett, alpha pero no acabo de obtener lo siguiente: - información sobre los autovalores y la varianza explicada de cada factor - el valor del

Hola, Justo, el paquete rela es específico para análisis de items. Para análisis factorial un paquete recomendable es psych http://cran.r-project.org/web/packages/psych/index.html En concreto fa. En el pdf tienes todos los detalles para esta función, así como alternativas -análisis factorial es un mundo. En la task view Psychometrics tienes un porrón de librerías relacionadas. Saludos! Pedro El

Hi Shankar, > Does LLVM emit rel/rela relocations with ARM ? I believe we emit .rel for (32-bit) ARM. Hard-coded in ARMELFObjectWriter.cpp (“HasRelocationAddend”). It seems to be what most toolchains have settled on. AArch64 is .rela always in LLVM, in case it matters. > Any tests ? Well there are tests of what we do, but obviously not of the full scope of functionality permitted by the

On Mon, Nov 4, 2013 at 11:05 AM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi, > > I was looking at the ARM ABI docs(http://infocenter.arm. > com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf) and they mention. > > "A binary file may use REL or RELA relocations or a mixture of the two > (but multiple relocations for the same > address must use

On 11/4/2013 1:40 PM, Jack Carter wrote: > On 11/04/2013 11:15 AM, Eric Christopher wrote: >> >> >> >> On Mon, Nov 4, 2013 at 11:05 AM, Shankar Easwaran >> <shankare at codeaurora.org <mailto:shankare at codeaurora.org>> wrote: >> >> Hi, >> >> I was looking at the ARM ABI >>