search for: farcaller

Hi all. I came across a strange behaviour in the instruction printer for Thumbv2: The instruction is 0xf000b800, which is a b.w #0 LLVM returns it as b.w #-262144, which doesn't make any sense to me. Should I consider it a bug? -- Vladimir Pouzanov http://www.farcaller.net/

...ied to compile both LLVM and my lib with -frtti with same results. On Dec 10, 2012, at 21:57, Jim Grosbach <grosbach at apple.com> wrote: > Llvm typically doesn't build with RTTI enabled. Perhaps that's what you're running into? > > Jim -- Vladimir Pouzanov http://www.farcaller.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4454 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121210/9ee47c04/attachment.bin>

...;-- maps to immed #8 <MCOperand Imm:14> <MCOperand Reg:0> Now, what are the two last operands (that are not actually present in disassembly)? And is it somehow possible to map the operands to OutOperandList/InOperandList found in the td definition? -- Vladimir Pouzanov http://www.farcaller.net/

...abel instead. Here's a patch that only acknowledges the broken instructions: https://github.com/garious/llvm/commit/916c4badd816178da9fdbac5b5ed2331a7201f98 I submitted this to llvm-commits a while back, but nobody replied. :( -Greg On Thu, Dec 27, 2012 at 4:20 PM, Vladimir Pouzanov <farcaller at gmail.com>wrote: > Hi all. > > I came across a strange behaviour in the instruction printer for Thumbv2: > > The instruction is 0xf000b800, which is a b.w #0 > > LLVM returns it as b.w #-262144, which doesn't make any sense to me. > > Should I consider it a bug...

...t's ok to use llvm::MCAsmInfo objects, but as soon as I use it in the cast (e.g. to_ruby), I immediately get an undefined symbol __ZTIN4llvm9MCAsmInfoE. Similar symbols for other llvm classes are there in my library's .o file, this one does not. Any hints? -- Vladimir Pouzanov http://www.farcaller.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4454 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121210/cabaab67/attachment.bin>

...wledges the broken instructions: > > > https://github.com/garious/llvm/commit/916c4badd816178da9fdbac5b5ed2331a7201f98 > > I submitted this to llvm-commits a while back, but nobody replied. :( > > -Greg > > > > On Thu, Dec 27, 2012 at 4:20 PM, Vladimir Pouzanov <farcaller at gmail.com>wrote: > >> Hi all. >> >> I came across a strange behaviour in the instruction printer for Thumbv2: >> >> The instruction is 0xf000b800, which is a b.w #0 >> >> LLVM returns it as b.w #-262144, which doesn't make any sense to me. >...

Llvm typically doesn't build with RTTI enabled. Perhaps that's what you're running into? Jim On Dec 10, 2012, at 1:27 PM, Vladimir Pouzanov <farcaller at gmail.com> wrote: > Hi all. > > I fully understand that the problem is a bit OT for llvmdev, but I'm stuck for two days now and I really need some direct push. > > To the problem. I have a C++ shared library, that's working with llvm C++ api. Consider a function: &gt...

...92 case ARM::tUXTH: printOperand(MI, 1, O); break; As the operand is not enough in this case. I'm pretty stuck at the TableGen deciphering to fix the issue. It'll be nice if someone with more llvm skills would check the file and make the required fix. -- Vladimir Pouzanov http://www.farcaller.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4454 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120326/02e45133/attachment.bin>

Vladimir Pouzanov <farcaller at gmail.com> writes: > On Dec 10, 2012, at 21:57, Jim Grosbach <grosbach at apple.com> wrote: >> Llvm typically doesn't build with RTTI enabled. Perhaps that's what >> you're running into? >> > I've actually tried to compile both LLVM and my lib w...

Good. Copying llvmdev for the record. Vladimir Pouzanov <farcaller at gmail.com> writes: > Sorted it out. > > In the end, the working build commands for me were: > > % export CXXFLAGS=-frtti > % ../llvm-3.1/configure > --prefix=/Users/farcaller/Developer/Active/llvm-src/install-3.1 > --enable-debug-runtime --enable-debug-symbols --disab...

I'm working on getting the latest Linux distros working well on one of our prototype machines, however, some of them are failing to boot into the installer from the CD/DVD images. I've narrowed it down to isolinux hanging just before displaying the graphical menu. After a little bisecting between the last version that worked (3.73) and the first version which was broken (3.74), I found

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Óscar Fuentes > > Vladimir Pouzanov <farcaller at gmail.com> writes: > > > On Dec 10, 2012, at 21:57, Jim Grosbach <grosbach at apple.com> wrote: > >> Llvm typically doesn't build with RTTI enabled. Perhaps that's what > >> you're running into? > >> > > I've actually tried to c...

Hi, Am Mittwoch, 26. Dezember 2012, 15:20:27 schrieb Manny Ko: > The MCInstrDesc has a method getNumDefs() which tells you how many 'out > registers' that MCInst has. The 'out' registers are always at the beginning > of the list. You can also use getNumOperands(). I've run into the problem, that this doesn't work for instructions which have variadic arguments

...;-- maps to immed #8 <MCOperand Imm:14> <MCOperand Reg:0> Now, what are the two last operands (that are not actually present in disassembly)? And is it somehow possible to map the operands to OutOperandList/InOperandList found in the td definition? -- Vladimir Pouzanov http://www.farcaller.net/ _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Greetings! As I have presented in the announcement about the ELF dynamic linker preview earlier this week, one of my tasks now is to reduce the size of the root COM32 module to a minimum, and make the rest of the klibc available as dynamic loadable content. After I studied the linker map output and saw what are the minimal requirements of the dynamic linker itself from the C library (the object

I tried to replace display_labels asm code (ui.inc) with new C code (pm_display_labels), but the data i access in command_line doesn't seem to be always up to date. The patch i am working on is only for PXELINUX because of different vkernel structure: diff --git a/core/com32.inc b/core/com32.inc index 111590c..f19df7c 100644 --- a/core/com32.inc +++ b/core/com32.inc @@ -135,6 +135,7 @@

Hi, Matt Fleming wrote: > 'make efi64' will build just for x86-64. Likewise, 'make efi32' will > build just for i386. You can combine these, so to build BIOS and efi64 > you'd do, > > make bios efi64 'make efi64' failed with: ld -T /tmp/syslinux/efi/x86_64/syslinux.ld -Bsymbolic -pie -nostdlib -znocombreloc -L/usr/lib64 --hash-style=gnu -m elf_x86_64

On Sat, 29 Jun, at 01:57:58AM, Igor Sverkos wrote: > Hi, > > Matt Fleming wrote: > > On Tue, 25 Jun, at 01:52:00PM, Helmut Hullen wrote: > >> Thanks - now it crashes later ... > > > > What crash are you seeing? > > > >> I don't have the ia64 files which are needed for a complete binary. But > >> maybe that's only my special

From: Matt Fleming <matt.fleming at linux.intel.com> This series fixes some bugs and switches the elflink branch to be entirely ELF modules. It applies on top of, http://syslinux.zytor.com/archives/2011-April/016369.html The deletions in the diff stat below are mainly from deleting com32/elflink/modules (finally!). Now there should be no duplicate code because we don't need COM32 and