aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2024-06-23deduplicate write_lt_* implsiximeow
2024-06-22docs typosiximeow
2024-06-22be more careful about what does and doesnt need allociximeow
2024-06-22VecSink only needs `alloc`, hide struct itemsiximeow
2024-06-22update changelog, adjust doc emphasisiximeow
2024-06-22fix annotation doc test not compiling under nostdiximeow
... this makes the doc test not exist under nostd, yes. `VecSink` does not have a no-std alternative that makes the example reasonable.
2024-06-22document `mod safer_unchecked`iximeow
2024-06-22move DisplaySink code out from yaxpeax-x86iximeow
it was built in-place around yaxpeax-x86, hoisted out once it seemed suitable and could be generalized. yay! also include a Makefile in yaxpeax-arch now to test that various crate feature flag combinations.. work.
2024-05-13update crossterm to a version released in the last two yearsiximeow
also bump rust-toolchain and edition of yaxpeax-arch
2024-05-13fix cfg(!default,colors,serde) imports, doc commentsiximeow
2021-09-25add missing `From<ReadError>` impliximeow
2021-08-22document a bit of what yaxpeax-arch is all about, add README as crate docsiximeow
2021-08-22move annotation stuff to its own moduleiximeow
2021-08-13add `AnnotatingDecoder`, supporting definitions, and a doc about itiximeow
2021-07-06fix incorrect `offset` and `total_offset` counts for non-`u8` Word0.2.4iximeow
also update yaxpeax-arch to 0.2.4
2021-07-06add Reader impls for U8Reader on u16 addresses0.2.3iximeow
2021-07-06add ReaderBuilder to generically construct arch-required Readers0.2.2iximeow
also revise an `unsafe` that might be unsafe un extremely unlikely circumstances - no one should be passing yaxpeax a `&[u8]` larger than `isize::MAX`, but on 32-bit architectures we can't necessarily guarantee that it won't happen
2021-07-04actually enforce DecodeError impl'ing std::error::Error in std buildsiximeow
the previous test and code only tested one concrete archtecture, and it turns out never required `std::error::Error` on `DecodeError`.
2021-07-03support std::error::Erroriximeow
included is mandataing a `description` method on `DecodeError` implementors - already approximately required by the Debug and Display anyway. also include a StandardPartialDecoderError for incomplete decoders to use. i expect that one of the last steps of a decoder's 1.0 release will be to move away from this.
2021-07-03document yaxpeax_arch traits and add an AddressDiff::to_constiximeow
2021-07-03reader impls for various word sizesiximeow
2021-07-03add a Reader type that can read architecture-defined wordsiximeow
this is useful for instruction sets like arm where instructions are guaranteed to be 4 bytes, as well as instruction sets where an instruction word is not a multiple of u8 bytes.
2021-07-03define a standard decode error for client libraries to useiximeow
additional variants will require clients to implement DecodeError, still
2021-06-14address diff is an u64 thingy that can be added to addressesnonbyte-wordsiximeow
2021-06-14experimentiximeow
2021-05-07swap termion dep for crossterm, simplify Colorization interfaces0.0.5iximeow
2020-05-03add AddressDiff, CHANGELOG, and bump to 0.0.40.0.4iximeow
2020-01-20Default impl of ColorSettings was needlessly feature gatediximeow
on a feature that doesnt exist, no less!
2020-01-18finally replace `stringy` with something usableiximeow
addresses must implement a function that returns a struct that is applicably formattable. particularly because the default Display impl on primitives is not necessarily desirable, if you want hex. additionally this allows meaningful Display for complex (eg, not a single primitive) addresses, such as segmented memory also expose AddressDisplay to name outside this crate. what an oversight
2020-01-15no_std!!iximeow
this makes yaxpeax-arch no_std. generally nothing has changed w.r.t downstream crates, but a lot to do with colorization has been moved tweaked to make it no_std-friendly (specifically, allowing `termion` to be an optional dependency) this also makes address parsing optional, in the hopes that decode-only use cases don't need to involve as much machinery when building.
2020-01-13default Decoder::decode() impliximeow
2020-01-12allow for granular and customizable errors when decoding instructionsiximeow
2020-01-12color helper for misc instructionsiximeow
2020-01-12decoders are stateful, so decode functions should take them as a parameteriximeow
2020-01-12warnings-b-goneiximeow
2020-01-12addresses are Hashiximeow
2020-01-12remove unused importiximeow
2020-01-12sneak hash/partialeq/etc into yaxpeax-archiximeow
2020-01-12awful tweaks to expose a serde flag on yaxpeax-arch which will trickle ↵iximeow
through everything
2020-01-12add color for program counter register (default to the same as ret and friends)iximeow
2020-01-12expose platform op coloriximeow
2020-01-12fix sign display bugiximeow
2020-01-12add some display logic into archiximeow
2020-01-12tweak how ColorSettings is usediximeow
enum to tie together a color and a thing to be colored, helper methods to build that, and an impl on Option that gives non-colored variants
2020-01-12add many more color types to settings, AddrParse to parse addresses from hex ↵iximeow
or decimal strings
2020-01-12real color settings, and defaultsiximeow
2020-01-12add traits for syntax highlighting and contextualized displayiximeow
these traits are not ideal but are what i can do in rust right now the initial attempt to add these traits involved a trait providing a `colorize` function that returned a struct (or tuple) that impl'd Display but bundled all useful data together. this would be nice because use would be like: ``` println!("the next instruction is: {}", instr.colorize(settings)); ``` but this runs into the same kind of lifetime issues as mentioned in the ContextRead commit. additionally complicating is contextualization, which involves a larger structure than just a copyable color setting - a similar builder-and-display style use would be nice but involves a third lifetime (the content, the colors, the contexts) and is not workable. references could be Rc pointers and this all might work. why not do that? moral opposition to cloning Rc pointers when doing any instruction rendering. might be worth revisiting later if i'm convinced this is too annoying - it's already close. meanwhile, it turns out implementing traits on tuples is currently not possible anyway - tuples are not #[fundamental]. in the future i need to investigate if i can use macros to tie into `derive`, so that a ShowContextual impl can #[derive(Colorize, Display)]. those implementations would really just call ShowContextual.colorize with fewer and fewer parameters non-None. the blanket impl ``` impl <T, U> Colorize for T where T: ShowContextual<U> ``` is entirely just a relic of one attempt, and can be ignored. this idea conflicted with coherence rules because someone else could impl Colorize for some type covered under this blanket impl.
2020-01-12add impls for address as used by x86_64iximeow
2020-01-12tweak core lifetimes, add an address formatteriximeow
2020-01-12require Arch to have addresses that can += and -=, as well as that ↵iximeow
instructions have a debug display
generated by cgit v1.1 at 2024-11-15 09:00:13 +0000