similar to: [LLVMdev] LLVM-3.0 fails to build on linux ppc32

Nico, There is a third place that '#undef PPC' is needed (at the top of PPCFixupKinds.h). Alternatively, you can run configure with -UPPC in your CPPFLAGS. I'll try to get this fixed in trunk shortly. -Hal On Fri, 2011-12-02 at 12:30 +0100, acrux_it at libero.it wrote: > hi, i just try to build llvm-3.0 (stable) on linux ppc32 (CRUX PPC 2.7) with > gcc-4.5.3, binutils-2.21.1,

On Fri, 2011-12-02 at 06:58 -0600, Hal Finkel wrote: > Nico, > > There is a third place that '#undef PPC' is needed (at the top of > PPCFixupKinds.h). Alternatively, you can run configure with -UPPC in > your CPPFLAGS. I'll try to get this fixed in trunk shortly. I just tested this, and I was wrong: passing -UPPC to configure in CPPFLAGS does not work for some reason.

>Da: hfinkel at anl.gov >Data: 02/12/2011 16.27 >A: "acrux_it at libero.it"<acrux_it at libero.it> >Cc: <llvmdev at cs.uiuc.edu> >Ogg: Re: [LLVMdev] LLVM-3.0 fails to build on linux ppc32 > >On Fri, 2011-12-02 at 09:15 -0600, Hal Finkel wrote: >> On Fri, 2011-12-02 at 06:58 -0600, Hal Finkel wrote: >> > Nico, >> > >> >

On Fri, 2011-12-02 at 20:18 +0100, acrux_it at libero.it wrote: > >Da: hfinkel at anl.gov > >Data: 02/12/2011 16.27 > >A: "acrux_it at libero.it"<acrux_it at libero.it> > >Cc: <llvmdev at cs.uiuc.edu> > >Ogg: Re: [LLVMdev] LLVM-3.0 fails to build on linux ppc32 > > > >On Fri, 2011-12-02 at 09:15 -0600, Hal Finkel wrote: > >>

Hi, I've run Clang Static Analyzer checker alpha.cplusplus.NewDeleteLeaks over LLVM codebase to detect false-positives and at the same time eliminate memory leaks. The majority of leaks were detected in lib/Target/* and lib/MC/*. In all cases the similar trick was detected as a leak (example from lib/Target/Sparc/MCTargetDesc/SparcMCTargetDesc.cpp) : static MCStreamer

Jim, Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. The issue I was having was the difficulty of subclassing MCELFStreamer. Or are you saying that I should be messing with the base MCELFStreamer for a specific fixup. One of the issues I hit initially with llvm is that

On Nov 15, 2011, at 10:36 AM, Carter, Jack wrote: > Jim, > > Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. > > The issue I was having was the difficulty of subclassing MCELFStreamer. Or are you saying that I should be messing with the base MCELFStreamer

i just tried to build llvm-3.0rc2 on my powerpc (G4) but without success. My toolchain (CRUX PPC 2.7): gcc-4.5.3, binutils-2.21.1, glibc-2.12.2, libffi-3.0.10 my llvm config: ./configure --prefix=/usr --mandir=/usr/man \ --enable-shared \ --enable-libffi --enable-optimize \ --enable-targets=all \ --enable-threads --enable-pic --enable-jit \

Hi Jack, I'm not 100% up on how MIPS represents jump tables, so take with a grain of salt and all that. Normally how this stuff works is that the streamer will create Fixups (MCDataFragment::addFixup()) for anything that might require a relocation. That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for

On Tue, Nov 15, 2011 at 11:06 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Nov 15, 2011, at 10:36 AM, Carter, Jack wrote: > >> Jim, >> >> Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data. >> >> The issue I was having was

On Fri, 2011-12-02 at 13:28 +0100, Joerg Sonnenberger wrote: > On Fri, Dec 02, 2011 at 12:30:29PM +0100, acrux_it at libero.it wrote: > > +// Generated files will use "namespace PPC". To avoid symbol clash, > > +// undefine PPC here. PPC may be predefined on some hosts. > > +#undef PPC > > + > > I wonder if it shouldn't just be renamed to PowerPC

On Fri, 02 Dec 2011 13:23:07 -0600 Hal Finkel <hfinkel at anl.gov> wrote: _omissis__ > > > > ciao Hal, > > thanks a lot for your support. > > i'll try your last suggestion. > > > > Btw, adding -UPPC to my system cxx flags i.e.: > > export CXXFLAGS="$CXXFLAGS -UPPC" > > > > i got, instead, some tests error: > >

On Fri, Dec 02, 2011 at 12:30:29PM +0100, acrux_it at libero.it wrote: > +// Generated files will use "namespace PPC". To avoid symbol clash, > +// undefine PPC here. PPC may be predefined on some hosts. > +#undef PPC > + I wonder if it shouldn't just be renamed to PowerPC everywhere. It's not that much longer. Joerg

On Fri, Dec 02, 2011 at 06:59:47AM -0600, Hal Finkel wrote: > On Fri, 2011-12-02 at 13:28 +0100, Joerg Sonnenberger wrote: > > On Fri, Dec 02, 2011 at 12:30:29PM +0100, acrux_it at libero.it wrote: > > > +// Generated files will use "namespace PPC". To avoid symbol clash, > > > +// undefine PPC here. PPC may be predefined on some hosts. > > > +#undef

Well Jim, that may just be my problem. As background I am working on the outer reaches of llvm for the direct object output for Mips. Part of what I am to do is instruct the folks working closer to the backend what I am getting that is incorrect. My first reaction is to assume that I am being fed things the correct way and that I am not handling it correctly. I feed the compiler a source file

I am having an issue with MCJIT on the ppc64 machine architecture. The symptom is that for a particular IR function the target machine won't emit neither an object nor an assembly file and subsequent calling the pointer to function results in a segfault. My application generates on the fly several functions with the builder and executes them with the MCJIT engine. I came across this

I have been working on getting ELF object file writing working for the MBlaze backend. Currently, each supported backend calls ELFObjectWriter::createELFObjectWriter from within the backend's TargetAsmBackend::createObjectWriter method. The createELFObjectWriter method then creates a new backend specific ELFObjectWriter class (either X86ELFObjectWriter or ARMELFObjectWriter) by decoding a

I'm working on Position-independent code for 32-bit PowerPC, but running into a problem. At the beginning of each function, there's a pre-word that's the difference between the PICBase (.L1$pb) and the GOT. This works fine when generating assembly output, but it fails when generating ELF output, with the error "Cannot represent a difference across sections" (line 847,

Hi Gents, For those of us with out-of-tree backends which are not 32bit, the msp430 backend is a useful vehicle for examining changes and testing out ideas. So I was wondering about enabling debug output on the MSP430 backend so that I can illustrate a few issues to Adrian and you on the variable pieces side. (there doesn't appear to be any specific person claiming the msp430 code right

I've been working on ELF object support for the MicroBlaze backend and found that ELFObjectWriter assumes the x86/x86-64 architecture. Attached is a patch that makes the 16-bit e_machine value in the ELF header configurable by the target backend. Right now the target backend simply passes the 16-bit value that it would like to use in the ELF header. I have considered a second approach where