Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: njholcomb at wi dot rr.com
Target Milestone: ---
Libopcodes produces invalid 32-bit address for a 64-bit MPX instruction.
Output: addr32 bndstx %bnd0
https://sourceware.org/bugzilla/show_bug.cgi?id=19660
--- Comment #4 from njholcomb at wi dot rr.com ---
Coming back to this, my concern is that outputting instructions with prefixes
where the prefixes cause the instruction to be undefined is misleading. If the
output of the decoder is intended
IRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: njholcomb at wi dot rr.com
Target Milestone: ---
Decoding the bytes: 0xd50b753f
Should produce: ic ivau, xzr
Instead produces: ic ivau
I test
: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: njholcomb at wi dot rr.com
Target Milestone: ---
Decoding an A64 base instruction with bytes: 0x331957fa should produce a bit
field insert of the zero register:
bfi
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: njholcomb at wi dot rr.com
Target Milestone: ---
Register names produced by objdump fail to be assembled by gas, specifically r
and f registers.
>From objdump:
:
0: c0 73 e3 d0 lfs
https://sourceware.org/bugzilla/show_bug.cgi?id=19722
--- Comment #4 from njholcomb at wi dot rr.com ---
This may not be a valid output from the libopcodes disassembler, but there are
a lot of tools out there, and not all of them may produce expected
instructions. People can also edit binaries
https://sourceware.org/bugzilla/show_bug.cgi?id=19661
--- Comment #2 from njholcomb at wi dot rr.com ---
Created attachment 9202
--> https://sourceware.org/bugzilla/attachment.cgi?id=9202&action=edit
File displays locking without a memory operand.
objdump -d lock_no_mem.o
lock_n
https://sourceware.org/bugzilla/show_bug.cgi?id=19660
--- Comment #2 from njholcomb at wi dot rr.com ---
Created attachment 9201
--> https://sourceware.org/bugzilla/attachment.cgi?id=9201&action=edit
Shows rep prefixes on non-string instructions
--
You are receiving this mail because:
https://sourceware.org/bugzilla/show_bug.cgi?id=19659
--- Comment #2 from njholcomb at wi dot rr.com ---
Created attachment 9200
--> https://sourceware.org/bugzilla/attachment.cgi?id=9200&action=edit
File causes Abort by objdump
This file contains bytes that objdump fails to decod
https://sourceware.org/bugzilla/show_bug.cgi?id=19722
--- Comment #2 from njholcomb at wi dot rr.com ---
Hi,
I'm not assembling this instruction, I am disassembling it from raw bytes. I
probably should have specified that this instruction is produced as decoder
output, not as assembler o
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: njholcomb at wi dot rr.com
Target Milestone: ---
Pair word instruction, like ldpsw, are undefined if the address for loading is
specified in a register also used as a
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: njholcomb at wi dot rr.com
Target Milestone: ---
The libopcodes decoder for aarch64 incorrectly aliases ORR instructions with
the zero register but non-zero shift values to MOV
: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: njholcomb at wi dot rr.com
Target Milestone: ---
Lock prefixes are also allowed even when they cause an Illegal Instruction
signal. Lock prefixes should require a memory
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: njholcomb at wi dot rr.com
Target Milestone: ---
The rep prefixes only affects string instructions (like scas, movs, etc.), yet
these are shown in other cases, such as:
repz loopne 0x5b
--
You are
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: njholcomb at wi dot rr.com
Target Milestone: ---
inst[] holds the bytes from left to right, zero indexed in a buffer.
INIT_DISASSEMBLE_INFO(disInfo, outf, (fprintf_ftype)fprintf);
disInfo.buffer
15 matches
Mail list logo
