search for: farcall

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 b...

...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. &g...

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

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

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 --dis...

...12 16:51:06.294747337 -0600 +++ syslinux-3.74/core/com32.inc 2009-10-12 16:51:09.750744468 -0600 @@ -172,13 +172,14 @@ ; Now everything is set up for interrupts... + push dword [HighMemSize] ; Memory managed by Syslinux push dword com32_cfarcall ; Cfarcall entry point push dword com32_farcall ; Farcall entry point push dword (1 << 16) ; 64K bounce buffer push dword (comboot_seg << 4) ; Bounce buffer address push dword com32_intcall...

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

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

...opinion (in particular, hpa) about what are the object files that you don't consider a basic service and don't need to be present in the root module. If you consider 25K an acceptable size for the root module, those objects, of course, don't need to be removed. LIBENTRY_OBJS = \ sys/farcall.o sys/cfarcall.o sys/zeroregs.o \ sys/argv.o \ sys/ftell.o \ sys/isatty.o sys/fstat.o LIBGCC_OBJS = \ libgcc/__ashldi3.o \ libgcc/__negdi2.o libgcc/__ashrdi3.o libgcc/__lshrdi3.o \ libgcc/__muldi3.o \ libgcc/__divdi3.o libgcc/__moddi3.o LIBCONSOLE_OBJS = \ sys/colortable.o sys/s...

...o 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 @@ __com32: dd 0 ; 64K bounce buffer dd core_farcall ; Farcall entry point dd core_cfarcall ; Cfarcall entry point +global HighMemSize HighMemSize dd 0 ; End of memory pointer (bytes) dd 0 ; No module name dd pm_api_vector ; Protected mode functions diff --git a/core/display_labels.c b/core/display_labels.c new file mode 100644 in...

...32/lib/libgcc/__muldi3.o /tmp/syslinux/efi64/com32/lib/libgcc/__udivmoddi4.o /tmp/syslinux/efi64/com32/lib/libgcc/__umoddi3.o /tmp/syslinux/efi64/com32/lib/libgcc/__divdi3.o /tmp/syslinux/efi64/com32/lib/libgcc/__moddi3.o /tmp/syslinux/efi64/com32/lib/sys/intcall.o /tmp/syslinux/efi64/com32/lib/sys/farcall.o /tmp/syslinux/efi64/com32/lib/sys/cfarcall.o /tmp/syslinux/efi64/com32/lib/sys/zeroregs.o /tmp/syslinux/efi64/com32/lib/sys/argv.o /tmp/syslinux/efi64/com32/lib/sys/sleep.o /tmp/syslinux/efi64/com32/lib/sys/fileinfo.o /tmp/syslinux/efi64/com32/lib/sys/opendev.o /tmp/syslinux/efi64/com32/lib/sys/r...

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