yaxpeax-x86/src/long_mode, branch 1.1.0 yaxpeax x86 decoder bump to yaxpeax-arch 0.2.7 and proper field description support 2021-08-22T22:04:33+00:00 iximeow me@iximeow.net 2021-08-22T22:04:33+00:00 d4620aedb1e085462f82d2a643a20c7de743ea2b 






add 16/32-bit opcode/operand boundary desc, consistentify memory descriptions
2021-08-22T17:46:32+00:00

iximeow
me@iximeow.net

2021-08-22T17:46:32+00:00

188cf391845a7d86466cd2ad35459b6bf825bb1e












add `AnnotatingDecoder` note to CHANGELOG and publicize descriptions
2021-08-22T05:17:24+00:00

iximeow
me@iximeow.net

2021-08-22T05:17:24+00:00

39eef01e04e478ec5cfa3c8f520c831631ecd67d












improve relative branch offset formatting for DisplayStyle::C
2021-08-22T02:58:19+00:00

iximeow
me@iximeow.net

2021-08-22T02:58:19+00:00

1c06541a85fadbc5b9fc0a3bfee10cec3c8e5667












maintain pre-annotation inlining properties
2021-08-22T02:20:41+00:00

iximeow
me@iximeow.net

2021-08-22T02:01:37+00:00

a5a67ee666381b2716862dec6df2e85419c352bc

this gets yaxpeax-x86 in no-inline configurations back to building as it
did before, but is quite a blunt hammer. it seems that extra calls to
`sink.record` trips the inlining thresholds for `read_with_annotation`,
and then its caller, and its caller, even when one of them is just a
delegation to its inner call.

this is particularly unfortunate because yaxpeax-x86 is now making a
decision about the inlining of a rather large function at the public
edge of its API, but these attributes match the inlining decisions that
LLVM was making before adding `DescriptionSink`. hopefully not too bad.
not sure how to handle this in the future.





this gets yaxpeax-x86 in no-inline configurations back to building as it
did before, but is quite a blunt hammer. it seems that extra calls to
`sink.record` trips the inlining thresholds for `read_with_annotation`,
and then its caller, and its caller, even when one of them is just a
delegation to its inner call.

this is particularly unfortunate because yaxpeax-x86 is now making a
decision about the inlining of a rather large function at the public
edge of its API, but these attributes match the inlining decisions that
LLVM was making before adding `DescriptionSink`. hopefully not too bad.
not sure how to handle this in the future.







add descriptions for other prefixes, 16-bit addressing
2021-08-22T02:20:41+00:00

iximeow
me@iximeow.net

2021-08-22T00:22:07+00:00

b6f83fa1b4859a6de2d7017e9709b9520d933f6b












add description reporting for segment prefixes and opcodes for 32-bit and 16-bit
2021-08-22T02:20:41+00:00

iximeow
me@iximeow.net

2021-08-22T00:10:39+00:00

0a39607d690755c5f7f7462677fb75580946be2c












report barebones decoder annotation for vex-coded instructions
2021-08-22T02:20:41+00:00

iximeow
me@iximeow.net

2021-08-20T08:59:27+00:00

b8cdf3ee6293f41b7b9bcb51d1177baeff24868d












extend decoder annotation through all of 64-, 32-, and 16-bit modes
2021-08-22T02:20:41+00:00

iximeow
me@iximeow.net

2021-08-20T08:59:03+00:00

796e955cdc4f17d191b39da55ce704f90c6f37da












force read_sib inlining in 64-bit mode
2021-08-22T02:08:40+00:00

iximeow
me@iximeow.net

2021-08-14T06:45:16+00:00

49a09cccdd2d4920154e3bc68048dc85754640e3

even though NullSink is no-ops, it causes llvm to not inline this function, for a net perf reduction





even though NullSink is no-ops, it causes llvm to not inline this function, for a net perf reduction