Skip to content
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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Implement uDebug for str #25

wants to merge 4 commits into from

Conversation

hnj2
Copy link

@hnj2 hnj2 commented Nov 13, 2020

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 and char::len_utf8 functions.

bors bot added a commit to tock/libtock-rs that referenced this pull request Feb 14, 2022
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]>
@japaric
Copy link
Owner

japaric commented Aug 9, 2022

Thanks for the PR but this fails the nopanic check if you uncomment this line:

// uwrite!(&mut W, "{:?}", a).unwrap();

The problem is not your implementation but rather that something in the core API you are using (maybe escape_debug or even char_indices?) brings in a panicking branch. The fix would require changes in libcore itself.


To have a better idea of where the panicking branch comes from you can use cargo-call-stack:

$ cargo new --bin app
$ cd app

change src/main.rs to this

#![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 Cargo.toml (apart from the ufmt dependency)

[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

cg

if you insert some #[inline(never)] (I didn't try) you may be able to get more resolution. cargo-call-stack doesn't show inlined function calls

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants