similar to: strange output from llvm-mc

Hi, It doesn't compile with yasm, or nasm (reports invalid combination of opcode and operands), and mov _x,EAX is meaningless as _x is just a label (an numeric constant that happens to be an address), so it would have to be dereferenced to get to the memory at that address, otherwise it's like saying mov 0x12341234, EAX Now, my asm skills are not that great, so I'm prepared to be

Hi Matthew, On Feb 15, 2012, at 5:42 PM, Matthew Huck wrote: > Hi, > It doesn't compile with yasm, or nasm Where did you get the idea that "Intel syntax" means NASM? LLVM actually produces assembly files that can be fed to GAS, or to LLVM's MC framework. (In fact, it's missing a .intel_syntax directive so GAS knows it needs to assemble instructions according to

Apologies - I apparently remembered part of the issue incorrectly, so this ended up quite confusing. The problem comes when referencing labels in a different section of the binary. To clarify, if I assemble the code: .data foo BYTE 5 .code mov eax, foo with Microsoft's ml64.exe, it emits an object file disassembling to: 0: 8b 05 00 00 00 00 mov eax, dword ptr [rip]

Hi, We have a significant regression since llvm 5.0.0 in the x86 assembler. The following snippets fail: 1) .intel_syntax 0: jmp 0b 2) .intel_syntax and edi, 0b010101 when running through `llvm-mc -arch x86-64`. This regression was introduced in r301390, which was driven by PR27884. I think https://llvm.org/PR36144 describes this very well, and I think we should get this fixed, since

Hi, over the past days I have been proofing a concept involving LLVM MC on the PowerPC target. The 32 bit part went quite ok, but i am puzzled with the results I get using the 64 bit target. When disassembling in 64bit some instructions refer to GPRs in PPC::R0 to PPC::R31, some refer to PPC::X0 to PPC::X31. I understand that the registers are modeled with Rx referring to the 32bit parts and Xx

Are you asking what the parsing rules are, or how you should modify the LLVM code to achieve that result? If the latter, you haven’t really given enough detail here. What code, exactly, have you tried modifying? Do you have any ideas for how it could work? -Eli From: Eric Astor <epastor at google.com> Sent: Tuesday, January 21, 2020 2:44 PM To: Eli Friedman <efriedma at

--- Josh Coalson <xflac@yahoo.com> wrote: > > -- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > On Tue, Dec 17, 2002 at 01:01:08PM -0800, Josh Coalson wrote: > > > --- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > > > Ok, what about enabling the 3dnow function in libFLAC by > default? > > > > I think time

--- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > On Wed, Nov 14, 2001 at 09:37:47AM -0800, Josh Coalson wrote: > > cpu support for 3dnow and sse can be easily detected at > > runtime. I turned off 3dnow by default because it is > > implicated in some crashes. > > Hmm, i never have any crash. Can i get more informations about these > crases? Or you

On Thu, Feb 28, 2019 at 3:15 PM Eli Friedman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > -----Original Message----- > > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of s n via > llvm-dev > > Sent: Wednesday, February 27, 2019 9:31 PM > > To: llvm-dev at lists.llvm.org > > Subject: [EXT] [llvm-dev] error building LLVM opt tool

New module which check if the PLoP Boot Loader already has booted a CDROM or USB drive by checking for the presence of the PLoP INT13h hook. The following assembly code (NASM) can detect the PLoP INT13h hook: mov eax,'PoLP' ; Reverse of 'PLoP' mov ebp,'DKHC' ; Reverse of 'CHKD' int 13h cmp eax,' sey' ; Reverse of 'yes ' jz

Hi all, Continuing work on llvm-ml (a MASM assembler)... and my latest obstacle is in enabling MASM's convention that (unless specified) all memory location references should be RIP-relative. Without it, we emit the wrong instructions for "call", "jmp", etc., and anything we build fails at the linking stage. My best attempt at this so far is a small patch to

Hi David, > I've try to use llvm-objdump to disassemble some ARM binary, such as busybox > in android. > > ./llvm-objdump -arch=arm -d busybox It's probably assuming the wrong architecture revision. I don't have an android busybox handy, but I see similar on binaries compiled for ARMv7. The trick is to use: llvm-objdump -triple=armv7 -d whatever (ARMv7 covers virtually

Hi Evan, Thanks for the information! I've try to use llvm-objdump to disassemble some ARM binary, such as busybox in android. ./llvm-objdump -arch=arm -d busybox There are many instructions cannot decode, :./llvm-objdump: warning: invalid instruction encoding Did I use llvm-objdump in a correct way? I think that one possible reason is that llvm-objdump encounter pc relative data.

On Thu, Jun 26, 2014 at 10:23 AM, Adam Nemet <anemet at apple.com> wrote: > > > On Jun 25, 2014, at 7:05 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > > > On Thu, Jun 26, 2014 at 5:47 AM, Adam Nemet <anemet at apple.com> wrote: > >> Hi Jun, >> >> On Jun 25, 2014, at 8:14 AM, Jun Koi <junkoi2004 at gmail.com> wrote: >>

a) A previous patch for stream_encoder_intrin_xxxx.c removes definitions of abs_residual_partition_sum variables but leaves unnecessary empty line after it. The first attached patch removes them. b) The second attached patch fixes coding style for lpc_asm.nasm: mov{space}ebp, esp to mov{tab}ebp, esp etc. -------------- next part -------------- A non-text attachment was scrubbed...

... > nasm -f elf -Ox -g -F dwarf -DDATE_STR="''" \ > -DHEXDATE="0x56dc3c62" \ > -Di386 \ > -I/tmp/syslinux-6.04-pre1/core/ \ > -l ldlinux.lsr -o ldlinux.o -MP -MD ./.ldlinux.o.d /tmp/syslinux-6.04-pre1/core/ldlinux.asm > nasm -f elf -Ox -g -F dwarf -DDATE_STR="''" \ > -DHEXDATE="0x56dc3c62" \ > -Di386 \ >

On 06.03.2016 18:23, poma wrote: > On 06.03.2016 16:47, poma wrote: >> ... >>> nasm -f elf -Ox -g -F dwarf -DDATE_STR="''" \ >>> -DHEXDATE="0x56dc3c62" \ >>> -Di386 \ >>> -I/tmp/syslinux-6.04-pre1/core/ \ >>> -l ldlinux.lsr -o ldlinux.o -MP -MD ./.ldlinux.o.d /tmp/syslinux-6.04-pre1/core/ldlinux.asm >>>

On Thu, Jul 19, 2001 at 04:58:44PM -0400, Matt Zimmerman wrote: > On Thu, Jul 19, 2001 at 10:38:14AM -0700, Josh Coalson wrote: > > > So, last chance to checkout from CVS and break it! > > Also, my libtool doesn't seem to recognize --tag=CC. What is its purpose? > > /bin/sh ../../../libtool --tag=CC --mode=compile \ > sh ../../../strip_fPIC.sh nasm -f

On 12/03/2014 04:15 PM, zep wrote: > >>> oh. the ARP packet suggests that MAC address is 192.168.1.144 >> that is how i see it. >> > is that 1.144 IP address in use by the machine you ran the lspci > from? somewhere. but i know not where. http://www.whoami.it/home/ shows me to be; adsl-184-41-28-86.mem.bellsouth.net for the hell of it, i pulled and

Hi Tim, Thanks a lot for the reply. I tested libc.so which is a shared library. llvm-objdump also report some disassemble errors. Could you please tell me more about $a, $t and $d symbols? How these symbols are used to define different regions? Where I can find this symbols in ELF object file? Thanks, David I'm now try to find a decoder of ARM instructions in oder On Thu, Jun 7, 2012