similar to: [LLVMdev] ARM Relocation Information

Hi Jack, Everything should be already using the sized Emit* routines directly rather than outputting individual bytes of larger entities piecemeal. Have you found that not to be the case? The Emit* routines handle endianness for you, so you shouldn't have to do much beyond that. For example, here's the EmitInvValue() implementation that underlies things and does the endianness transform:

Hi Jack, I would have expected the Mips backend to be using these routines (or more likely something on top of them) to emit the contents of the data and text sections and thus have the bit-twiddling done by these routines. I take it that's not happening? Basically, this should already work without any additional infrastructure. If it's not, something is broken and bypassing the

Jim, I see routines that are already available to do the endianizing, but the data and text section contents don't have sizing for the individual elements as far as I can see so that I can endianize them. That is the part I am trying to solve, not the bit twiddling algorithm. Did I miss something? Jack ________________________________________ From: Jim Grosbach [grosbach at apple.com] Sent:

Hello, Renato > While Clang doesn’t include the TARGET2 relocation information, and that > mess up cross-linking. Is there any documentation for this stuff? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Thu, Oct 21, 2010 at 7:50 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Hmm, I wish we had this discussion way earlier.. >> >> How would I emit things in different subsections? I can do a high >> level switch to .ARM.attributes, and if I were emitting one blob from >> begin to end, using the higher level interface would be preferable,

On Tue, May 8, 2012 at 4:59 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Eli, > > > On 07/05/2012 18:15, Eli Friedman wrote: >> >> On Mon, May 7, 2012 at 5:15 AM, Ivan Llopard<ivanllopard at gmail.com> >>  wrote: >>> >>> Hi all, >>> >>> Tuning my TargetAsmPrinter implementation in the back-end side, I

On Wed, Oct 20, 2010 at 2:56 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Gosh, this is taking a while :-) >> Is there anything else I missed? > > Another one I noticed. Instead of > >      SmallString<32> *FC = &currFileFragment.getContents(); >      (*FC) += static_cast<char>(attr); >      (*FC) += static_cast<char>(0xFF

Le 08/05/2012 20:44, Eli Friedman a écrit : > On Tue, May 8, 2012 at 4:59 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi Eli, >> >> >> On 07/05/2012 18:15, Eli Friedman wrote: >>> On Mon, May 7, 2012 at 5:15 AM, Ivan Llopard<ivanllopard at gmail.com> >>> wrote: >>>> Hi all, >>>> >>>> Tuning my

I have a Dell ASC-39230(B) U320 SCSI controller. If I use the linux-2.6-xen kernel I am getting an "Invalid Sequencer interrupt" and the system hangs after this. But if I use the linux-2.6-xen0 kernel it works well. Does anyone know why this is happening and how I can make it go away? Thanks, Aravindh Puthiyaparambil Xen Development Team Unisys, Tredyffrin PA ACPI: PCI Interrupt

I have an Adaptec 392320 Ultra320 SCSI adapter. I am running x86_64 SLES9 SP3. When I build x86_64 Xen with just the 2.6-xen kernel + initrd, I am getting the following error on the module load. But if I go back to building separate xenU and xen0 kernels without initrd the device works without any issues. Any idea what is going wrong here? Am I leaving something out of my initrd? Here is the

Hi all, The AsmPrinter class supports functions like EmitInt8, EmitInt16, and EmitInt32 for writing a 1/2/4 byte directive to the assembly. Each of these calls the MCStreamer::EmitIntValue method with the corresponding size. For some reason, there is no EmitInt64, and I was wondering if there was a fundamental reason why? The EmitIntValue function appears to support 8-byte inputs. I dug into

DWARF already needs to emit 64-bit values, being the type-unit hashes. How is that being done? (If it's going directly to the streamer, then we're already assuming all assemblers are okay with what the streamer does, and adding an AsmPrinter helper seems very reasonable.) --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of James Henderson via llvm-dev Sent:

Hi all, This is my first post to the list. My first real major issue with xen. I started on 3.4.2 and upgraded to 4.0.1 without issues. Now I just attempted to go to 4.1.0 and I got the following errors in my log. # cat /var/log/xen/xend-debug.log Xend started at Fri Apr 1 13:51:15 2011. cat: /sys/bus/scsi/devices/host0/vendor: No such file or directory cat:

https://bugzilla.netfilter.org/show_bug.cgi?id=1144 Bug ID: 1144 Summary: set add always returns false or otherwise ends evaluation Product: nftables Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: normal Priority: P5 Component: kernel

Hi R users, I am new to R and am trying to merge data frames in the following way. Suppose I have n data frames each with two fields. Field 1 is common among data frames but may have different entries. Field 2 is different. Data frame 1: Src Target1 1 aaa 1 bbb 1 ccc 2 aaa 3 ddd Data frame 2: Src Target2 2 aaaa 3 dddd 4 bbbb 4

I am trying to download data from NASA web-service. I am using the following code; for( i in 1:8) { target1 <- paste0(" https://hydro1.gesdisc.eosdis.nasa.gov/daac-bin/access/timeseries.cgi?variable=NLDAS:NLDAS_FORA0125_H.002:TMP2m&location=GEOM:POINT( ", cities[i, "lon_nldas"], ",%20",

W dniu 2012-10-26 16:55, Daniel Kłobuszewski pisze: > Hello, > > Recently I found binaries produced with LLVM impossible to debug under > Windows. This was probably related to the following bug: > http://llvm.org/bugs/show_bug.cgi?id=13636 > > Asm generated from .ll files revealed that some offsets to debug > information were incorrect: they were absolute instead of

I am getting assembler errors on clang-llvm-2.9 output for a program with exceptions that I do not get when using the installed g++ Mac OS-X 10.4 powerpc-apple-darwin > as -version Apple Computer, Inc. version cctools-590.23.2.obj~17, GNU assembler version 1.38 the folks at gnu-binutils assure me this is an assembler bug, but also that this isn't a recognizable "gnu"

Hi Eli, On 07/05/2012 18:15, Eli Friedman wrote: > On Mon, May 7, 2012 at 5:15 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi all, >> >> Tuning my TargetAsmPrinter implementation in the back-end side, I >> discovered that the address space number is not passed down while >> emitting global variables with constant initializers. The information is

Hello, am I wrong or the ARM c++ exceptions handling does not work? See the difference between assembly generated by clang and gcc with the following test code: #include <stdio.h> #include <exception> # test.cpp int main() { try { throw 20; } catch (int e) { printf("Exception Nr %d occurred\n", e); } return 0; }