similar to: [LLVMdev] MIPs backend generates wrong reloc info for static data

Dear all, I don't get how llvm handles functions with __attribute__((noreturn)). It seems that LR register is backed up on the stack whilst it will never be used to return from a 'noreturn' function. I have this problem with a home-made backend but it seems that ARM flavour of clang has same behaviour. By the way, SP is also saved, I don't understand why. Is there a syntax error

Dear all, I have been working on a new LLVM backend. Some instructions, like sub, can take an positive constante, encoded into 5 bits thus lower than 32, and a register, as operands. Unfortunately, DAGCombiner.cpp changes patterns like 'sub x, 5' into 'add x,-5'. Similarly, I found changes in some IR to IR passes, with no clear gain (at least not clear to me), and even penalty

> De : Joerg Sonnenberger [mailto:joerg at britannica.bec.de] > > Well, MCFixup is what a relocation is represented as internally. They get > resolved to a fixed value and replaced, if evaluateAsAbsolute is true. > Hi Joerg, Actually it fails to get resolved to a fixed value. When I compile to .o then objdump it I can see that a symbol holding the constant value was created in

Hi all, I have been developping a out-of-tree backend. I would like to integrate it with clang. Note that my backend is rather simple, generates elf32, and I do not need about linux, libary paths, ... Can someone give me a pointer to a readme, an article, or maybe a good (i.e. simple) example ? Note :on a second step, I would like to support inline assembly in C code.. -- Frederic Heitzmann

Dear LLVM crew, I have been writing a new LLVM backend with a very simple instruction set. moving a constant value to a register is selected as a load of the constant, with a PC-relative positive offset. Thus, the constant should be stored in .text section, after the load instruction, and offset should be computed at compile time (not link time). I struggle to find out : - how llvm handle

Thanks Tom for your help, it as indeed very easy to make the link with the linker (not sick joke). Unfortunately, clang generates object files for target x86_64, even though I try --target --triple, --arch, ... What is the trick to tell him which target to use ? -- Fred ps: not looked yet at inline assembly 2015-07-09 18:40 GMT+02:00 Tom Stellard <tom at stellard.net>: > On Thu, Jul

2015-07-08 17:58 GMT+02:00 escha <escha at apple.com>: > [...] > > If you want to “revert" this sort of thing, you can do it at Select() time > or PreprocessISelDAG(), which is what I did on an out-of-tree backend to > turn add X, -C into sub X, C on selection time. This still lets all the > intermediate optimizations take advantage of the canonicalization. > >

> De : Joerg Sonnenberger [mailto:joerg at britannica.bec.de] > > The basic idea is to still create a relocation on the MC level, but fix it up later. > You didn't say if your ISA is fixed or variable length, the former, can simplify > this quite bit. The constant island pass generally tries to address two issues: > (1) Merging of identical constants. > (2) Splitting the

Hi all, I work on an embedded target, in which function assert is an infinite while(1) loop. It is a common technique to set a breakpoint in the loop, in case some error occurs while debugging. It looks like clang simply *removes* any call to assert when compiling with -O1 (not -O0). note 1 : the name 'assert' is not the problem. note 2 : if the while(1) loop has some side effect,

Pinging this thread to see if anyone else has opinions or objections -- if not I plan to go ahead with stepping towards compatibility with readelf vs llvm-readelf in https://reviews.llvm.org/D54124 on Monday. On Tue, Nov 6, 2018 at 9:52 AM Jordan Rupprecht <rupprecht at google.com> wrote: > Hi James, > > I also wanted to work on this discrepancy, but I just sent a patch instead

Hi, We are trying to use LLVM API to programmatically obtain a list of relocations in an ELF file. The way we are doing this is exactly as llvm-objdump does it: we are iterating through sections and in each section we are iterating over relocations (see PrintRelocations() function at https://llvm.org/svn/llvm-project/llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp). However, it does not give us

Hi all, A broad goal of many of the LLVM binary tools, such as llvm-objcopy and llvm-objdump is to provide an alternative to the GNU equivalent, and as such, these tools have been developed to be command-line compatible. One tool where this hasn’t been the case up to now is llvm-readobj (aka llvm-readelf). There was some discussion in https://reviews.llvm.org/D33872 about the purpose of

Hi all, llvm-readelf is an alias for llvm-readobj which aims for GNU compatibility and is likely the tool that most people migrating to the LLVM binutils will adopt instead of llvm-readobj. Because it is just an alias, it has inherited the functionality provided by llvm-readobj, including for non-ELF targets, with Mach-O and COFF-specific switches available in its interface. People migrating from

Add a simple test which uses scanelf or readelf to detect whether the supermin executable is really not executable. Kind of followup of commit c9f7a7998021e1cbe22a8ec325d43e2bdc3eff5a. --- tests/Makefile.am | 1 + tests/test-execstack.sh | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 33 insertions(+) create mode 100755 tests/test-execstack.sh diff --git a/tests/Makefile.am

Hi, I've tracked down what I believe is a bug in lld's relocation processing for R_X86_64_PC32 REL relocations. I'm producing the object file in a slightly unusual way: I'm using objcopy on a relocatable i386 ELF object file to convert it to x86_64 which transforms a R_386_PC32 into a R_X86_64_PC32. Steps to reproduce: 1. Assemble the attached bug.asm using nasm and note the

Geting a seg fault. Have not investigted the cause. rkotler at mipsswbrd002:~/richard$ tar vfxz ~/Downloads/ellcc-mips-linux-2014-Mar-24-07-32-26.tgz rkotler at mipsswbrd002:~/richard/ellcc/bin$ gdb ./ecc GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are

Hello all, The lld linker appears to generate extra ELF program headers and thus causes file sizes to be significantly larger than what would get with ld.gold or ld.bfd. # readelf -l test.bfd Elf file type is EXEC (Executable file) Entry point 0x4000b0 There are 2 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr

My personal preference is that llvm-readelf only show the elf related options with -help and show all with -help-hidden. There is support for this in CommandLine.h, but I don't know how tricky it gets when we don't want them to be hidden for llvm-readobj. I haven't looked into this fully. For some reference, I have compiled how the other alias tools are handled. Many of these are

Thanks James it seems worked for me :) I am facing some issues in login into bugs.llvm.org, I will file once I get access. Pls feel free if you have login :) Thank you again. From: James Henderson <jh7370.2008 at my.bristol.ac.uk> Sent: Wednesday, July 8, 2020 1:58 PM To: Oza, Hiral <Hiral.Oza at netapp.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] llvm-objdump print

Hi Michael, Does ELF support aliasing ? How is the relationship captured in ELF symbol table, that one symbol is a alias of another symbol ? > Note that __stdout_used is the last symbol in the .rodata section. > This means that the reader assigns the data (16 bytes of 0) to > __stdout_used. Because dummy_file and the other __stdx_used symbols > come before it, they end up in the