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

defmt-print snapshot tests #876

Open
Urhengulas opened this issue Oct 18, 2024 · 2 comments
Open

defmt-print snapshot tests #876

Urhengulas opened this issue Oct 18, 2024 · 2 comments
Labels
good first issue Good for newcomers

Comments

@Urhengulas
Copy link
Member

The idea is to have snapshot tests for defmt-print, similar to how we had them for probe-run1. Much of the implementation can probably copied over.

We feed an elf file and some defmt frames into defmt-print and test that the output matches what we expect.

How to get the elfs?

In a first version it would be fine to commit the compiled elf to the repository (that's how it was done for probe-run).

In the long run it would be cool if they can be re-compiled with a xtask command.

How to get the defmt frames

This one is a bit tricky. In theory they can be written by hand with a hex editor. But that is cumbersome, especially since you need to know the indexes of the defmt table, and the indexes might change when the binary is recompiled. Also here it would be better to generate them with a xtask command.

One way to go would be to patch qemu-run (the defmt decoder we use for our existing snapshot tests) to not decode the received data, but to just print it. This can be achieved with the patch below. Then you can run cargo xtask test-snapshot --overwrite to write the defmt frames to firmware/qemu/src/bin/*.out.

diff --git a/qemu-run/src/main.rs b/qemu-run/src/main.rs
index 5ea0c98..91a5f13 100644
--- a/qemu-run/src/main.rs
+++ b/qemu-run/src/main.rs
@@ -5,7 +5,7 @@
 
 use std::{
     env, fs,
-    io::Read as _,
+    io::{self, Read as _, Write},
     process::{self, Command, Stdio},
 };
 
@@ -70,8 +70,7 @@ fn notmain() -> Result<Option<i32>, anyhow::Error> {
     let exit_code;
     loop {
         let n = stdout.read(&mut readbuf)?;
-        decoder.received(&readbuf[..n]);
-        decode(&mut *decoder)?;
+        io::stdout().write_all(&readbuf[..n]).unwrap();
 
         if let Some(status) = child.0.try_wait()? {
             exit_code = status.code();

If this path is taken it would make sense to add a flag to qemu-run which makes it possible to switch from decoding to non-decoding behaviour.

How to tie it all together?

We have an example rust file that we compiled to an elf file.
We have example defmt encoded logs which are matching to the elf.

The only part missing is a test/are tests that run the elf and defmt frames against defmt-print and check the output. This can be done like this:

$ cat defmt-frame.out > defmt-print -e elf-file
decoded log 1
decoded log 2

Footnotes

  1. https://github.com/knurling-rs/probe-run/tree/main/tests#readme

@BenFordTytherington
Copy link
Contributor

Started work on this in #910

@BenFordTytherington
Copy link
Contributor

BenFordTytherington commented Dec 6, 2024

In my implementation, I found that the code you provided for printing without formatting in qemu-run, adds extra spaces inbetween log levels and I haven't been able to diagnose why. Has anything similar happened before that might help me out here?

The trace, debug and error levels seem to be unaffected (I ran the log example) but the others get the added spacing. The .out files also appeared different, so I think the issue pertains to the writing aspect in qemu-run rather than in defmt-print

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants