similar to: Any "special interest" in R/pic interface?

Hi Folks, I'm trying to locate the source code for a (typical) R graphics device, in order to study how it's done. The underlying reason is that I'm thinking of trying to create a graphics device for 'pic' (the diagram drawing component of [g]troff). I thought the xfig device would be a good place to look, since the format of an xfig file is similar in nature (though very

Question for R users under unix: Do you ever edit figs created by R using xfig or some other program? I tried to edit a figure with xfig (a program which I find quite horrible by the way) and it said it couldn't read it in. I guess xfig has no capability of reading postscript files? Can anyone tell me how to do it, or perhaps suggest another freeware structured drawing program for use in

I noticed that we generate code like this for i386 PIC: calll L0$pb L0$pb: popl %eax movl %eax, -24(%ebp) ## 4-byte Spill I worry that this defeats the return address prediction for returns in the function because calls and returns no longer are matched. From Intel's Optimization Reference Manual: "The return address stack mechanism augments the static and dynamic

Anton, >> Can I ask what platform ABI's are documented other than Itanium ? > I'd bet all platform ABI are more or less documented. Right. Maybe we should collect references and do some LLVM PIC documentation and put it on LLVM website ? >> I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF >> and MachO backends. > ABI is normally induced

Actually, GCC will generate non-PIC for n64. Maybe that is a recent addition, but we are using its results. Even if PIC may be faster and smaller code, it seems that non-PIC is still useful for bare-metal. That's the driver of my interest. I guess we can just test what happens when that part of the conditional is removed. As a side note, if it isn't supported then we should probably

Hello, Aaron > Can I ask what platform ABI's are documented other than Itanium ? I'd bet all platform ABI are more or less documented. > I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF and MachO backends. ABI is normally induced by platform, not by architecture or object file format (however they can influence on it). 1. Windows is PIC by design. Google for

Aaron, > Maybe we should collect references and do some LLVM PIC documentation and > put it on LLVM website ? What you mean as "LLVM PIC documentation"? What should be included there? > Okay. We need documentation, what is the difference between DynamicNoPIC and > full PIC ? >From TargetMachine.cpp (actually this is show in llc --help): cl::values(

I was having problems with my exception handling due to mixing PIC and non-PIC code into my executable. Now I'm confused as to how I'm supposed to do this correctly when I do have to mix different code types. The basic setup: - shared library which throws and catches exceptions, some exceptions leave it's library bounds - main executable which throws and catches exceptions, exceptions

On Jun 16, 2009, at 1:17 PMPDT, Anton Korobeynikov wrote: > Hello, Aaron > >> Can I ask what platform ABI's are documented other than Itanium ? > I'd bet all platform ABI are more or less documented. > >> I need to get to understand PIC on x86, x86_64 and PowerPC for the >> COFF and MachO backends. > ABI is normally induced by platform, not by

>> 2. ABI docs for Darwin (x86, x86_64, ppc, ppc64) you might find >> somewhere @apple.com. There you can have all 3 types of PIC code: >> static (no pic at all), DynamicNoPIC and full PIC. > > Okay. We need documentation, what is the difference between > DynamicNoPIC and > full PIC ? The best way to figure this out is to run a small program through and look at

Has anyone experimented with generating non-PIC for MIPS64 and the n64 ABI? Currently MipsISelLowering.cpp uses conditions like: if ((getTargetMachine().getRelocationModel() == Reloc::PIC_) || IsN64) { } around any PIC code generation. Is generating non-PIC just untested, or is it known not to work? I can't find any discussion of it anywhere. I ran into this when trying to see why

Anton, Sorry I have not replied earlier. Can I ask what platform ABI's are documented other than Itanium ? I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF and MachO backends. Thanks, Aaron 2009/6/15 Anton Korobeynikov <anton at korobeynikov.info> > Hello, Aaron > > > Is there any overview or detailed socumentation on LLVM PIC ? > Did you

Why would this be happening, and how can I fix this - the man subsystem hasn't been working because of this for a while. This is FreeBSD-4.9-Prerelease: # gdb man man GNU gdb 4.18 (FreeBSD) This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... /usr/share/tmac/man: No such file or directory. And when I go to run a manpage, I sometimes get this

HPUX doesn't seem to ship with a set of troff macros that can handle the OpenSSH manpages. Maybe other OSs have this problem? Rather than sodding about with the tmac/ directory, I think we should do one of two things: 1. Ship a set of preformatted manpages, and either auto-install them in $prefix/man/cat{1,1m} or just have instructions in INSTALL to do so 2. Recommend users install groff

The short: Linking to libspeex.a when generating a .so using libtool results in a non-portability warning. This is due to PIC code and non-PIC code intermingling. How can I go about fixing this whilst still using an installed libspeex present on the user's system? The long: I am using autoconf + libtool to generate a codec plugin for speex (sipXmediaLib), and I'm trying to eliminate

Hi Folks - I''m pretty new to ACPI (don''t know my ASL from a hole in the ground :-), but I think the _PRT method has the PIC/APIC cases reversed. I''m looking at tools/firmware/acpi/acpi_dsdt.asl. The ACPI spec says a _PIC method (if defined) will be called with an argument of 1 if the host is using APIC interrupts. If the host is using PIC interrupts instead, it

I'm trying to build a very large shared library (bundle) for PPC on Mac OS X 10.5. The build looks something like this, where mybundlebitcode.o is the large object llc -relocation-model=pic -o=mybundle.s mybundlebitcode.o gcc -arch ppc -c -x assembler -o mybundle.o mybundle.s g++ -o mybundle.bundle -bundle mybundle.o -lotherlibrary I get the following error: ld: 32-bit pic-base out of

On Mar 11, 2010, at 6:07 PM, Chris Lattner wrote: > On Mar 11, 2010, at 5:47 PM, Robb Kistler wrote: > >> I'm trying to build a very large shared library (bundle) for PPC on >> Mac OS X 10.5. The build looks something like this, where >> mybundlebitcode.o is the large object >> >> llc -relocation-model=pic -o=mybundle.s mybundlebitcode.o >> gcc

On Mar 11, 2010, at 5:47 PM, Robb Kistler wrote: > I'm trying to build a very large shared library (bundle) for PPC on Mac OS X 10.5. The build looks something like this, where mybundlebitcode.o is the large object > > llc -relocation-model=pic -o=mybundle.s mybundlebitcode.o > gcc -arch ppc -c -x assembler -o mybundle.o mybundle.s > g++ -o mybundle.bundle -bundle mybundle.o

ELF that MCJIT writes on x86_64 has relocations in it. Particularly, R_X86_64_PC32 relocations are used for the sections .gcc_except_table and .eh_frame related to exception processing. I am not sure where is general documentation on relocation types, including R_X86_64_PC32. Looks like it's nowhere to be found on the web. But 32-bit relocation can't be used in 64-bit code since it