similar to: ppc32: "Relocation truncated to fit"

The parts of klibc specific to the ppc architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit a82c9b6e9b3428bae592241d1ac276054bc46fc5 tree 70852f39dd495c9bffc307d38f6da673d91ab08a parent 078d6614054391efe17093f8d70340e2c0644ffb author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:37 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

Commit-ID: 72d6d78a8f0d24a64911c246487402c81b4beb9d Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=72d6d78a8f0d24a64911c246487402c81b4beb9d Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Sun, 20 Jan 2019 19:41:47 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sun, 20 Jan 2019 21:15:17 +0000 [klibc] Use -Ttext-segment to link

Commit-ID: ad72c27485b86171153ab26a1c1035f8e9bbd5e3 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=ad72c27485b86171153ab26a1c1035f8e9bbd5e3 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Sun, 6 Jan 2019 20:50:56 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 18 Jan 2019 03:10:14 +0000 [klibc] Kbuild: Remove

In the v3.6 kernel, many of the headers were split out into a uapi variant. klibc should be using those variants to compile. There is also a generated subdir, to seperate out generated headers. The old kernel header location needs to be included as well, because linux/compiler.h is available only in the base include directory. Signed-off-by: Robin H. Johnson <robbat2 at gentoo.org> ---

The parts of klibc specific to the i386 architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit bd0599e5290ca1a16bb7a68f7c362d395c612eb3 tree 8f33afdd02a14c22e7a3984da2bad13184e3f729 parent 84f6a72f42cf41e32daa59871a0b5424572093e4 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:21 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

On Wed, Sep 15, 2004 at 10:48:02AM +0930, Alan Modra wrote: > After using SHAREDFLAGS = -Ttext 0x0f000200 on ppc64 (which I see you > suggested in another email), I see the problem you're talking about. > > klibc is fundamentally broken on ppc64. You just can't call into > another chunk of code (klibc.so in this case) which has a separate toc > and expect things to

http://bugs.freedesktop.org/show_bug.cgi?id=10547 --- Comment #6 from Maarten Maathuis <madman2003 at gmail.com> 2008-02-01 11:16:02 PST --- I've not heard people complain about this recently, is it still an issue? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

A while back, there was mention that the release of CentOS 4.3 would bring a ppc32 version. Is this still in the works? If so, is it scheduled to be released at the same time as the more popular releases, or at a later time? Thanks, Barry

Hi For .LL like: define void @Func() { %var1 = alloca double store double 0x40bb580000000000, double* %var1 ret void } ppc32 output is: ... lis 3, 16571 ori 3, 3, 22528 li 4, 0 stw 3, 8(1) stw 4, 12(1) ... I'm using the PPC backend's output as the "bytecode" for an interpreter that I would like to be able to run

Can anyone tell me how the ppc32 version of CentOS-4 is coming along? Thanks, Barry

Does anyone have any news about the PPC32 release of CentOS 4? Thanks, Barry

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: > >>

http://bugs.freedesktop.org/show_bug.cgi?id=10547 --- Comment #11 from Danny <obiwan at mailmij.org> 2008-03-13 01:15:37 PST --- I just add here a link to marcheu's patch to do this in drm instead (to make it easy for ppl who want to avoid rebuilding their kernel: http://icps.u-strasbg.fr/~marchesin/nvdri/ucmpdi2.diff d. -- Configure bugmail:

http://bugs.freedesktop.org/show_bug.cgi?id=10547 Stephane Marchesin <marchesin at icps.u-strasbg.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #12 from Stephane

http://bugs.freedesktop.org/show_bug.cgi?id=10547 bjt23 at cornell.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bjt23 at cornell.edu ------- Comment #5 from bjt23 at cornell.edu 2007-11-12 01:56 PST ------- (In reply to comment #2) > More

The _start stuff was changed some time ago, but ppc was not updated. This fixes klibc for me. I'm not sure what to do with the second arg to __libc_init, so I set it to 0.. However, looking at other static binaries, there is more stuff todo. diff -p -purNx linux -x '.*.d' -x syscalls -x socketcalls y/klibc-0.87/klibc/arch/ppc/crt0.S klibc-0.87/klibc/arch/ppc/crt0.S ---

Hello, Michael > Hi, I'm guessing that no one has tried this exact combination yet. Some quick notes, which can be not connected to your problem. 1. You might need the following patch for FP constants to work properly: diff --git a/gcc/llvm-convert.cpp b/gcc/llvm-convert.cpp index 4c9c8d0..db8c6ba 100644 --- a/gcc/llvm-convert.cpp +++ b/gcc/llvm-convert.cpp @@ -5157,11 +5157,6 @@ Constant

Hi there, it's me again. attached is preliminary support for tail calls on ppc 32. (once i get access to a 64bit machine that part will follow). It has passed the llvm-test with the -tailcallopt flag enabled. (after half a day on an old g4/800 :) okay to submit? probably not. :) suggestions. regards arnold -------------- next part -------------- A non-text attachment was scrubbed... Name:

On Wed, Jul 23, 2008 at 4:23 PM, Scott Graham <scott.llvm at h4ck3r.net> wrote: > I'm using the PPC backend's output as the "bytecode" for an interpreter > that I would like to be able to run on both little- and big-endian > platforms. The split stw's mean that i32s of the f64 are swapped in > memory on little-endian (thus foiling native-code interop).

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