similar to: [LLVMdev] registerSize on X86 confused?

I looked at this briefly, I think it causes some mistakes that get reversed later in fixupReg. The disassembler design is a bit of a mess with regards to prefixes and operand size. On Tue, Apr 1, 2014 at 4:43 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > > On Mon, Mar 31, 2014 at 11:48 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > >> Hi, >> >>

there is an if-else code in X86DisassemblerDecoder.c that does exactly the same thing on both paths. so this patch removes the redundant path. thanks, Jun diff --git a/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c b/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c index 20e61da..3932ea1 100644 --- a/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c +++

Hi there! In the x86 disassembler I noticed an if-statement with a duplicated branch. Are these intended to be identical? Best regards, Nicolas Kaiser -- diff -ur llvm-2.8.orig/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c llvm-2.8/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c --- llvm-2.8.orig/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c 2010-05-06 22:59:00.000000000 +0200

On Jun 15, 2009, at 11:33 AM, David Greene wrote: > To reduce redundancy, developers must be able to write generic > patterns > like this: > > [(set DSTREGCLASS:$dst, // rr, rrr > (xor (INTSRCTYPE (bitconvert (SRCTYPE SRCREGCLASS:$src1))), > (INTSRCTYPE (bitconvert (SRCTYPE SRCREGCLASS:$src2)))))], > > The substitution then fills in the appropriate types,

On Monday 15 June 2009 14:35, Chris Lattner wrote: > > I suppose you could argue that additional parameters specifying > > the source and dest types could be passed, but why bother when > > it is already encoded in the mnemonic? That would just be > > adding error-prone redundancy. > > Why not synthesize the opcode string from the information passed down?

Chris Lattner wrote: > However, I don't see any reason to base this off of strings. Instead > of passing down "f32" as a string, why not do something like this > pseudo code: > > class X86ValueType { > RegisterClass RegClass; > ... > } > > def X86_f32 : X86ValueType { > let RegClass = FR32; > ... }; > def X86_i32 :

There is a problem on X86 disassembler for instructions beginning with x86 prefix : $ echo "0x66 0x0f 0x6f 0x8f 0x00 0x00 0x00 0x00" | llvm-mc --disassemble movdqa (%edi), %xmm1 $ echo "0x53 0x66 0x0f 0x6f 0x8f 0x00 0x00 0x00 0x00" | llvm-mc --disassemble pushl %ebx <stdin>:1:6: warning: invalid instruction encoding 0x53 0x66 0x0f 0x6f 0x8f 0x00 0x00

Hi, I am looking at the "LLVMOpInfoCallback GetOpInfo" callback. Example 1 GOOD: 41 c6 84 24 16 04 00 00 0c : movb $12, 1046(%r12) Makes calls to the callback with: Offset = 0x4, Size = 0x4 <- Octets: 16 04 00 00 Offset = 0x8, Size = 0x1 <- Octets: 0c That was correct. Example 2 BAD: c7 45 98 a1 ff ff ff : movl $4294967201, -104(%rbp) Makes calls to the callback

hi, i think the current X86 disassembler is quite broken and fails badly on handling REX for x86_64 code. below are some examples: $ echo "0x0f,0xeb,0xc3"|./Release+Asserts/bin/llvm-mc -disassemble -triple=x86_64 .text por %mm3, %mm0 $ echo "0x40,0x0f,0xeb,0xc3"|./Release+Asserts/bin/llvm-mc -disassemble -triple=x86_64 .text por %mm3, %mm0 $ echo

On Wed, Dec 24, 2014 at 2:43 PM, Craig Topper <craig.topper at gmail.com> wrote: > I believe this particular error is caused by this. That seems easy enough > to just drop the bit. Do you have other non-mmx examples? > > case TYPE_MM: \ > if (index > 7) \ > *valid = 0;

I am getting -Werror failures building: [off-opt] : [llvm] /ptmp/dag/llvm/official/llvm/include/llvm/ADT/StringRef.h: In member function 'virtual llvm::AliasAnalysis::AliasResult {anonymous}::AliasAnalysisCounter::alias(const llvm::AliasAnalysis::Location&, const llvm::AliasAnalysis::Location&)': [off-opt] : [llvm]

hi, i found this code in X86DisassemblerDecoder.h #define EA_BASES_32BIT \ ENTRY(EAX) \ ENTRY(ECX) \ ENTRY(EDX) \ ENTRY(EBX) \ ENTRY(sib) \ ENTRY(EBP) \ ENTRY(ESI) \ ENTRY(EDI) \ ENTRY(R8D) \ ENTRY(R9D) \ ENTRY(R10D) \ ENTRY(R11D) \

The IMM3/IMM5 come from here X86RecognizableInstr.cpp 943 TYPE("SSECC", TYPE_IMM3) 944: TYPE("AVXCC", TYPE_IMM5) On Thu, Dec 25, 2014 at 8:22 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > On Fri, Dec 26, 2014 at 11:54 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > >> hi, >> >> some instructions

hi, some instructions mismatch between assembler & disassembler, like below. it seems this happens with all SSECC related instructions? thanks, Jun $ echo "cmpps xmm1, xmm2, 23" | ./Release+Asserts/bin/llvm-mc -assemble -triple=x86_64 --output-asm-variant=1 -x86-asm-syntax=intel -show-encoding .text cmpps xmm1, xmm2, 23 # encoding: [0x0f,0xc2,0xca,0x17] $

I attach a patch that fixes this bug. Applies to llvm 3.4svn Please commit it please. Kind Regards James On 13 September 2013 17:46, James Courtier-Dutton <james.dutton at gmail.com>wrote: > Hi, > > I am looking at the "LLVMOpInfoCallback GetOpInfo" callback. > > Example 1 GOOD: > 41 c6 84 24 16 04 00 00 0c : movb $12, 1046(%r12) > > Makes

Hi Fangrui, Many thanks for providing such detailed feedback! Please find my comments inlined below. - Ammar On Sun, Jun 28, 2020 at 5:59 AM Fangrui Song <maskray at google.com> wrote: > On 2020-06-26, Ammar Ben Khadra via llvm-dev wrote: > >## TL;DR > > > >We introduce bcov, an open-source binary-level coverage analysis tool [1]. > >The details are discussed

+ruiu and compnerd, since there might be an lld issue here. A slightly simpler example. This is all x86_64; I haven't tried x86. % cat imp.c __declspec(dllimport) void ExitProcess(unsigned exitCode); int mainCRTStartup() { ExitProcess(0); } % cat kernel32.def LIBRARY kernel32 EXPORTS ExitProcess % dlltool –d kernel32.def –l kernel32.lib % cl /Zl /c imp.c % link /subsystem:console imp.obj

Indeed, it's 32bits x86 and there's no .safeseh or anything like it, even readobj -coff-load-config says nothing: File: ConsoleApplication830.exe Format: COFF-i386 Arch: i386 AddressSize: 32bit Now I know what to look for, thanks! On Mon, Aug 20, 2018, at 18:46, Reid Kleckner wrote: > This is 32-bit x86, right? Sounds like the exception handler did not > appear in the /safeseh

llvm[2]: Compiling DWARFDebugArangeSet.cpp for Debug+Asserts build llvm[2]: Compiling DWARFDebugAranges.cpp for Debug+Asserts build llvm[2]: Compiling DWARFDebugFrame.cpp for Debug+Asserts build /home/rkotler/llvm_trunk/lib/DebugInfo/DWARFDebugFrame.cpp:118:8: error: private field 'LinkedCIE' is not used [-Werror,-Wunused-private-field] CIE *LinkedCIE; ^ 1 error

## TL;DR We introduce bcov, an open-source binary-level coverage analysis tool [1]. The details are discussed in our paper [2], which is accepted to ESEC/FSE'20. bcov statically instruments x86-64 ELF binaries without compiler support. It features several techniques that allow it to achieve high performance, transparency, and flexibility. For example, running "make