similar to: [LLVMdev] Build problem in current svn

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

I've prepared a preliminary patch with the intention of implementing PPC-EABI subtarget features for applications that run in a standalone embedded environment. https://reviews.llvm.org/D26344 The most significant difference compared with the SVR4 ABI is the use of SDA (small data area). This allows full-word constants and data to be grouped into small-data sections accessed using relocated

----- Original Message ----- > From: "Jack Andersen via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, November 16, 2016 10:39:53 PM > Subject: Re: [llvm-dev] [MC] Target-Independent Small Data Section Handling > > Just pinging this patch for review, particularly from PPC > maintainers:

Just pinging this patch for review, particularly from PPC maintainers: https://reviews.llvm.org/D26344 It's now rebased for the latest master commits, `check-all` test results match those of the upstream base. There is also a clang driver patch, extending PPC target support for the `-G` flag: https://reviews.llvm.org/D26345 And lld patch implementing the _SDA_BASE_ symbols and includes an

hi, I am trying to build the llvm trunk with make. I am trying a debug build and I am ending with the following build error. /home/rajika/projects/llvm/llvm/lib/Target/TargetLoweringObjectFile.cpp: In member function ‘virtual bool llvm::TargetLoweringObjectFileMachO::shouldEmitUsedDirectiveFor(const llvm::GlobalValue*, llvm::Mangler*) const’:

I have done a possible cleanup patch for the MachineCodeEmitter, ELFWriter, and MachOWriter classes. It removes the two startGVStub(), and finishGVStub() JIT specific methods. You may remember the following comments :- /// JIT SPECIFIC FUNCTIONS - DO NOT IMPLEMENT THESE HERE! To get rid of these easily turned out to be a semicomplex modification because of the JITInfo classes dependance on

I'll look at these. First scan looks good. Are you able to run some tests? Evan On Feb 28, 2009, at 9:36 AM, Aaron Gray wrote: > I have done a possible cleanup patch for the MachineCodeEmitter, > ELFWriter, and MachOWriter classes. It removes the two > startGVStub(), and finishGVStub() JIT specific methods. > > You may remember the following comments :- > >

> I've never looked at the MachO code as I do not have such a platform nor do > I know the file format. > > Could we concentrate on the ELF backend, please. I don't mind using the ELF backend as our test case, it just seems that the ELFWriter/ELFCodeEmitter don't even use the BufferBegin/BufferEnd/CurBufferPtr system exposed by the base MachineCodeEmitter. There is a big

On Wed, 15 Jun 2005, Reid Spencer wrote: > So, here's the plan: > > 1. No reading interface. To have a system agnostic interface for reading > a dynamic library, use System/DynamicLibrary. No plans for reading a > native object file for any kind of examination purpose (at least, not > for a long while). Sounds good. > 2. We will support .so/.dll and .o/.obj file output.

On Mon, 27 Feb 2006, Vladimir Prus wrote: > I'm looking for a way to make the the "llc" tool (or any other tool), > directly produce a binary file for some target. ok > The TargetMachine class has a method 'addPassesToEmitMachineCode', that's > suitable for that, but that method also requires an instance of > MachineCodeEmitter. Actually, you probably

Hi, Have you guys considered libelf [1] for implementing ELFWriter? [1] http://people.freebsd.org/~jkoshy/download/libelf/article.html Regards, -Mahadevan.

On Wed, May 5, 2010 at 11:15 AM, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > ... We basically want one MCStreamer callback to correspond to one > statement in the .s file. This makes it easier to handle from the compiler > standpoint, but is also very important for the llvm-mc assembly parser > itself. > > This

On Wed, May 5, 2010 at 9:38 PM, Chris Lattner <clattner at apple.com> wrote: > On May 5, 2010, at 6:44 PM, Nathan Jeffords wrote: > > ... >> Thanks, applied in r103150! llvm-mc -filetype=obj probably needs a >> similar patch. >> >> > cool!, I will make that change and submit it too. > > > Thanks! > > After looking into this, I have found

On Wed, 2010-05-05 at 13:22 -0700, Nathan Jeffords wrote: > > The important point here is that the COFF MCSection needs to > have the right level of semantic information. In fact, > MCSection is the place that I'd start for COFF bringup. > > OK, I see that now. The current isolation > between TargetLoweringObjectFile ->

Hi all, I have interest in some ideas, some I've seen in the Open project pages (copied straight from there) and some are by my own, they are: 1) Implement MachOWriter and ELFWriter to allow LLVM-based compilers to bypass an external assembler. This may include the idea of an assembler for inline assembly 2) Write a disassembler for machine code that would use TableGen to output

On May 4, 2010, at 11:03 AM, Nathan Jeffords wrote: > This is a brain-dump of my thoughts on the MCStreamer interface after several > days of digging around trying to get a COFF writer working. Great! Something that is worth pointing out is that the MCStreamer API is intended to directly reflect what is happening in .s files. We basically want one MCStreamer callback to correspond to one

On Feb 6, 2011, at 8:52 PM, sivakumar srinivasan wrote: > Hi Everyone, > > I am really new to LLVM. I am working on something where I had to pick-up a half-cooked backend and need to add debug support to it. I have searched through messages but could not find a nice starting place. Could some one please provide me with some pointers about > - what is already supported in llvm as far

On 22 November 2010 20:52, Jason Kim <jasonwkim at google.com> wrote: > So far, for X86 identical ELF relocation flags show up in > > include/llvm/Support/ELF.h and > lib/Target/X86/X86ELFWriterInfo.h > > Not to mention, there are two different files named ELF.h I would say that ELF.h should be the canonical one. > ./lib/CodeGen/ELF.h > ./include/llvm/Support/ELF.h

Hello > I really need in my backend value for this section, distinct from > default. Where can I set it? It was renamed to ReadOnlySection. You might want to check the logic inside CodeGen/TargetLoweringObjectFileImp.cpp (in particular - TargetLoweringObjectFile::SelectionSectionForGlobal) to see how it's used. -- With best regards, Anton Korobeynikov Faculty of Mathematics and

On May 6, 2010, at 11:22 PM, Nathan Jeffords wrote: > Thanks! Funny, I was just preparing a patch to submit for my changes to MCSectionCOFF. My changes look to be fairly independent of yours, my change was to deal with COMDAT's. I had dealt with the characteristics flags in the object writer, but I like this. If you don't mind I would like to merge my changes into this patch and submit