1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
## TODO
~~TODO: Reader::next_n should return the number of items read as Err(ReadError::Incomplete(n)) if the buffer is exhausted~~
* a reader's `.offset()` should reflect the amount of items that were consumed, if any. if a reader can quickly determine
there is not enough input, should it return Incomplete(0) or ExhaustedInput? Incomplete(0) vs ExhaustedInput may still
imply that some state was changed (an access mode, for example). this needs more thought.
TODO: Reader::offset should return an AddressDiff<Address>, not a bare Address
* quick look seems reasonable enough, should be changed in concert with
yaxpeax-core though and that's more than i'm signing up for today
TODO: impls of `fn one` and `fn zero` so downstream users don't have to import num_traits directly
* seems nice at first but this means that there are conflicting functions when Zero or One are in scope
... assuming that the idea at the time was to add `fn one` and `fn zero` to `AddressBase`.
TODO: 0.4.0 or later:
* remove `mod colors`, crossterm dependency, related feature flags
## 0.3.1
fix InstructionTextSink::write_char to not panic in debug builds
## 0.3.0
added a new crate feature flag, `alloc`.
this flag is for any features that do not require std, but do require
containers from `liballoc`. good examples are `alloc::string::String` or
`alloc::vec::Vec`.
added `yaxpeax_arch::display::DisplaySink` after revisiting output colorization.
`DisplaySink` is better suited for general markup, rather than being focused
specifically on ANSI/console text coloring. `YaxColors` also simply does not
style text in some unfortunate circumstances, such as when the console that
needs to be styled is only written to after intermediate buffering.
`DisplaySink` also includes specializable functions for writing text to an
output, and the implementation for `alloc::string::String` takes advantage of
this: writing through `impl DisplaySink for String` will often be substantially
more performant than writing through `fmt::Write`.
added `mod color_new`:
this includes an alternate vision for `YaxColors` and better fits with the
new `DisplaySink` machinery; ANSI-style text markup can be done through the
new `yaxpeax_arch::color_new::ansi::AnsiDisplaySink`.
this provides more flexibility than i'd initially expected! yours truly will
be using this to render instructions with HTML spans (rather than ANSI
sequences) to colorize dis.yaxpeax.net.
in the future, `mod colored` will be removed, `mod color_new` will be renamed
to `mod color`.
deprecated `mod colored`:
generally, colorization of text is a presentation issue; `trait Colorize`
mixed formatting of data to text with how that text is presented, but that is
at odds with the same text being presented in different ways for which
colorization is not generic. for example, rendering an instruction as marked
up HTML involves coloring in an entirely different way than rendering an
instruction with ANSI sequences for a VT100-like terminal.
added `yaxpeax_arch::safer_unchecked` to aid in testing use of unchecked methods
these were originally added to improve yaxpeax-x86 testing:
https://github.com/iximeow/yaxpeax-x86/pull/17, but are being pulled into
yaxpeax-arch as they're generally applicable and overall wonderful tools.
thank you again 522!
added `mod testkit`:
this module contains tools to validate the correctness of crates implementing
`yaxpeax-arch` traits. these initial tools are focused on validating the
correctness of functions that write to `DisplaySink`, especially that span
management is correct.
`yaxpeax-x86`, for example, will imminently have fuzz targets to use these
types for its own validation.
made VecSink's `records` private. instead of extracting records from the struct
by accessing this field directly, call `VecSink::into_inner()`.
made VecSink is now available through the `alloc` feature flag as well as `std`.
meta: the major omission in this release is an architecture-agnostic way to
format an instruction into a `DisplaySink`. i haven't been able to figure out
quite the right shape for that! it is fully expected in the future, and will
probably end up somehow referenced through `yaxpeax_arch::Arch`.
## 0.2.8
added an impl of `From<ReadError>` for `StandardPartialDecoderError`, matching the existing `StandardDecodeError` impl.
moved a use of `serde` types to be covered by the relevant cfg flag; using `colors` without `serde` (unlikely) now actually builds.
fixed up doc comments to build without error.
(and additional testing permutations to validate cfg flags and doc comments in the future)
## 0.2.7
moved `AnnotatingDecoder` and its associated types to `annotation/`, for module-level documentation about that feature.
yanked 0.2.6 because there was not yet a user of it other than myself, and it had this feature in the wrong location in the crate.
## 0.2.6
added `AnnotatingDecoder` and associated traits `FieldDescription` and `DescriptionSink` for architectures to report meanings for bit ranges in decoded instructions.
added `NullSink`, with an `impl<T> DescriptionSink<T> for NullSink` - `NullSink` can always be used to discard instruction annotations. this is mostly useful for shared annotating and non-annotating decode logic.
added a `docs/` directory for `yaxpeax-arch`: trip reports for `yaxpeax-arch` design. if `yaxpeax` eventually grows an RFC process one day, these are the kind of changes that would get RFC'd.
added `docs/0001-AnnotatingDecoder.md`, describing motivation and implementation notes of `AnnotatingDecoder`.
## 0.2.5
added `yaxpeax-lc87` to the matrix
## 0.2.4
fix incorrect `Reader` impls of `offset` and `total_offset` on non-`u8` words
## 0.2.3
added `Reader` impls for `U8Reader` on `u16` addresses
## 0.2.2
added `ReaderBuilder` trait and impls for `U8Reader` on various address and word types.
added documentation for `Reader`, `U8Reader`, and `ReaderBuilder`.
avoid an unlikely violation of `core::ptr::offset` safety rules on 32-bit architectures.
## 0.2.1
updated architecture matrix
## 0.2.0
correct a bug in 0.1.0 that incorrectly bounded `DecodeError` and did not actually require `std::error::Error`. added a test that `std::error::Error` is actually required of `Arch::DecodeError` in non-std builds.
## 0.1.0
new trait `Reader` to provide a reader of `Arch`-defined `Word`s. in many cases it is acceptable for `Word` to be `u8`, but `yaxpeax-arch` provides pre-defined words `u8`, `U16le`, `U16be`, `U32le`, `U32be`, `U64le`, and `U64be`.
`yaxpeax_arch::U8Reader` is a struct to read from `&[u8]` that implements `Reader` for all predefined words. it is suitable to read larger words if the minimum word size is still one byte.
`Decoder` now decodes from a `Reader<A::Address, A::Word>`, to prepare for ISAs where instruction sizes are not multiples of 8 bits.
`yaxpeax_arch::DecodeError` now requires a `std::error::Error` impl for `std` builds, to support interop with the Rust `error` ecosystem.
committed to `AddressDiff` being convertable to a primitive with `AddressDiff::to_const`
- this addresses the need for hacks to translate an instruction length into a usize
## 0.0.5
swap the `termion` dependency for `crossterm`. this is motivated by improved cross-platform support (notably Windows) as well as removing a type parameter from `Colored` and `YaxColors`.
## 0.0.4
add `AddressDiff`. `LengthedInstruction::len` now return `AddressDiff`. the length of an instruction is the difference between two addresses, not itself an address.
## 0.0.3
`ColorSettings` gets a default impl
## 0.0.2
add `AddressDisplay` to provide a usable interface to display `Address` implementors.
at the same time, remove `Address::stringy()`. it was a very bad interface, and will not be missed.
## 0.0.1
history starts here
|
