similar to: [LLVMdev] Request for help: why does the program link correctly?

Jim, I didn’t understood why foo is not marked with type 'FUNC'. At least as per elf standard symbol foo should be marked as 'FUNC' STT_FUNC: The symbol is associated with a function or other executable code. Regards, Ashutosh -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Jim Grosbach Sent: Friday, July

Someone in my team pointed to an open bug about this in gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35514 Would this be applicable to Clang as well? Thanks, Soumitra On 03-Jul-2015 10:53 AM, Tim Northover wrote: > On 2 July 2015 at 21:51, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: >> Jim, I didn’t understood why foo is not marked with type 'FUNC'. > >

CC llvm-dev ---------- Forwarded message ---------- Hello Duncan The size of ARM binaries created by clang has increased after r236642. Would you be able to find some time to look at my findings and share your thoughts about the problem, please? r236642 prevents emitting of temp label names into object files to save memory. This is fine, the label names do not appear in the resulting binaries.

Getting closer... When emitting symbols, how do I set the symbol's value to the address of the current instruction? Do I need to emit a label in the current section and another that uses the former to point to the latter? If possible, a code sample would be very helpful. And probably questions for Tim, are these "section-relative" mapping symbols, as defined in 4.6.5.1 of the

Hi David, On Thu, Jun 7, 2012 at 10:17 AM, Fan Dawei <fandawei.s at gmail.com> wrote: > Could you please tell me more about $a, $t and $d symbols? How these symbols > are used to define different regions? Where I can find this symbols in ELF > object file? At the start of each range of ARM code, an assembler or compiler should produce a "$a" symbol with that address, and

Hi Tim, Thanks a lot for your help! I'm very grateful. libc.so is a prelinked library, I'll build a non-prelinked one and have another try. I'm now at the start of a binary translation project. I want to convert ARM binary code [*] to llvm ir, which is then translated to binary for our mips like architecture. That's why I'm looking for a decoder for ARM binary. The

Hi Jim, Thanks for reply. I'm sorry I didn't make myself clear enough. The MCInst created by MCDisassembler depends on the instructions defined in td files. These instructions do not have a one to one mapping to ARM instructions. There are usually one or more instructions defined in the td file correspond to one actual ARM instruction. Thanks, David On Thu, Jun 7, 2012 at 1:27 PM, Jim

On Jun 7, 2012, at 7:53 AM, Fan Dawei <fandawei.s at gmail.com> wrote: > Hi Tim, > > Thanks a lot for your help! I'm very grateful. > > libc.so is a prelinked library, I'll build a non-prelinked one and have another try. > > I'm now at the start of a binary translation project. I want to convert ARM binary code [*] to llvm ir, which is then translated to

That depends on how you define "one ARM instruction." It's not a clear cut thing. For example, is "add r1, r2, r3" the same ARM instruction as "add r1, r2, #4"? What is a distinct instruction and what's a variant encoding of the same instruction is often entirely a matter of convenience. -Jim On Jun 8, 2012, at 6:40 AM, Fan Dawei <fandawei.s at

On 16 October 2012 03:16, Greg Fitzgerald <garious at gmail.com> wrote: > Lastly, from MCELFStreamer, how do I determine if we generating an ARM or > Thumb ELF? That was the only part I didn't know how to get. Jim should know. > I can catch Thumb from the EmitThumbFunc, but that seems a > little odd. Ignore EmitThumbFunc, it has nothing to do with your change. > $

Great, thanks for your help. I'll take a crack at it and contact Renato if I have questions. -Greg On Wed, Oct 10, 2012 at 1:05 PM, Jim Grosbach <grosbach at apple.com> wrote: > Cool; glad to help. > > When I added the data region bits, I tried to keep the ARM-style annotations in mind a bit, so hopefully things will fit together without too much trouble. > > -Jim >

Hi all, I noticed that the static local variable(internal global in .bc) is not aligned in ARM ELF(use MC(-filetype=obj)). Then I found that the alignment information is lost at: lib/CodeGen/AsmPrinter/AsmPrinter.cpp:316 if (MAI->hasLCOMMDirective()) { // .lcomm _foo, 42 OutStreamer.EmitLocalCommonSymbol(GVSym, Size); return; } MCStreamer::EmitLocalCommonSymbol have

Cool; glad to help. When I added the data region bits, I tried to keep the ARM-style annotations in mind a bit, so hopefully things will fit together without too much trouble. -Jim On Oct 10, 2012, at 12:05 PM, Renato Golin <rengolin at systemcall.org> wrote: > Thanks Jim! > > I have updated the bug with your comments, I think it's a good start. > > Greg, let me know

Hi Tim, Thanks a lot for the reply. I tested libc.so which is a shared library. llvm-objdump also report some disassemble errors. Could you please tell me more about $a, $t and $d symbols? How these symbols are used to define different regions? Where I can find this symbols in ELF object file? Thanks, David I'm now try to find a decoder of ARM instructions in oder On Thu, Jun 7, 2012

Hi, Can you please file a bug and Cc me directly on it? I'll go take a look soon. Thanks -jason On Wed, Jul 20, 2011 at 9:53 AM, TDYa127 <a127a127 at gmail.com> wrote: > Hi all, > > I noticed that the static local variable(internal global in .bc) is > not aligned in ARM ELF(use MC(-filetype=obj)). > Then I found that the alignment information is lost at: >

Hello. That's what I've got from ld: /usr/lib/libxenguest.a(xg_private.o): In function `unlock_pages': (.text+0x490): multiple definition of `unlock_pages' /usr/lib/libxenctrl.a(xc_private.o):(.text+0x6a0): first defined here /usr/lib/libxenguest.a(xg_private.o): In function `lock_pages': (.text+0x4d0): multiple definition of `lock_pages'

Hello -- I desperately want to start using Ogg compression on music I release on the internet, but I am encountering a fair amount of artifacts. I noticed some in beta4 and was hoping they would disappear with RC1. However, I've been playing with RC2 and I've still been banging my head into a number of problems. A majority of the music I make has long drones with a fair amount of spectral

I noticed that LLD doesn’t preserve the symbol type for a defsym directive. For example: $ cat f.c void f() {} $ clang -c f.c $ ld.lld -shared --defsym=g=f f.o $ objdump -T a.out DYNAMIC SYMBOL TABLE: 00000000000012a0 g DF .text 0000000000000006 f 00000000000012a0 g D .text 0000000000000000 g f is marked as a function symbol, but g is not. I recognize this is hard to do in the general

Hi Reid, Sure. Here I attach the trimmed IR(sim_0.ll) which llc.exe takes and produces a 0 storage class symbol. The IR is fairly long but there is only 1 usage of real constant as actual argument passing to function iki_vlog_time() at line 137. The version of llc.exe is $ llc.exe --version LLVM (http://llvm.org/): LLVM version 7.0.1 DEBUG build. Default target: x86_64-pc-win32 Host

Some doxygen annotations are attached to the wrong entry, which can be misleading. This patch fixes the mistake everywhere I could find it. --- include/llvm/InstrTypes.h | 54 ++++++++++++++++++++-------------------- include/llvm/MC/MCDirectives.h | 42 +++++++++++++++--------------- include/llvm/Pass.h | 10 +++--- 3 files changed, 53 insertions(+), 53 deletions(-) diff