-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement uDebug for str #25
base: main
Are you sure you want to change the base?
Conversation
371: ufmt: add support for hex printing and width specifiers r=jrvanwhy a=hudson-ayers This change adds ufmt support for hex printing of numbers and for fixed-width printing up to widths of 18 using 0s or spaces as padding. 0 padding is only supported for numbers. Custom fill characters and specified alignment is not supported. This change does decrease the size savings of ufmt relative to core::fmt, but brings them much closer to feature parity. This change has not been submitted to the upstream ufmt repo, as it includes variations on several changes already submitted as PRs to that repo which have not been accepted: japaric/ufmt#25 and japaric/ufmt#26 . A number of tests were added to verify that ufmt formatting is identical to core::fmt formatting for the supported additions. These can be run using `cargo test --features=std` from the ufmt directory. In a closed-source codebase, switching apps to use ufmt instead of core::fmt reduced code size by a total of 7200 bytes across 4 apps, with the only loss in functionality being two locations that used fixed alignment printing. In the same codebase switching to unmodified ufmt saved 12,500 bytes, at the expense of - not being able to print any numbers in hexadecimal - not being able to print fixed width fields Notably, this support is *somewhat* pay-for-what-you-use: The savings were ~10kB before I switched back to hex/fixed width formatting where it had been used before. Accordingly, for users of ufmt who do not need/want any of this functionality, the overhead is about a 20% increase in code size. I suspect I can get that number somewhat lower, but wanted to submit this as-is for feedback before I spend too much time optimizing. Co-authored-by: Hudson Ayers <[email protected]>
Thanks for the PR but this fails the Line 29 in 7edbb12
The problem is not your implementation but rather that something in the To have a better idea of where the panicking branch comes from you can use $ cargo new --bin app
$ cd app change #![no_main]
#![no_std]
use core::{convert::Infallible, panic::PanicInfo, ptr};
use ufmt::{uWrite, uwrite};
#[no_mangle]
fn _start() -> usize {
write as usize
}
fn write(s: &str) {
uwrite!(&mut W, "{:?}", s).unwrap();
}
struct W;
impl uWrite for W {
type Error = Infallible;
fn write_str(&mut self, s: &str) -> Result<(), Infallible> {
s.as_bytes().iter().for_each(|b| unsafe {
let _ = ptr::read_volatile(b);
});
Ok(())
}
}
#[panic_handler]
fn panic(_: &PanicInfo) -> ! {
loop {}
} add this to the [profile.release]
codegen-units = 1
incremental = false
lto = 'fat'
opt-level = 'z' run this to build a call graph $ rustup default nightly
$ rustup component add rust-src
$ rustc -V
rustc 1.65.0-nightly (f03ce3096 2022-08-08)
$ cargo call-stack --target thumbv7m-none-eabi --bin app > cg.dot
$ dot -Tsvg cg.dot -o cg.svg if you insert some |
This implementation of uDebug shouldn't contain any panicking branches.
To do this I've used the unsafe
str::get_unchecked
function.The necessary safety requirements result form the use of the
str::char_indices
andchar::len_utf8
functions.