07:45 <bitts[m]> Huh, I'm trying to include some c-files into a rust (cortex-a53) project using cc. It compiles fine when I build locally on my (arm) Mac, but if I try to build in a Docker, I get a `rust-lld: error: /<snip>/target/aarch64-unknown-none/debug/build/int_test-3e1a21ae7e1a8a49/out/libweetest.a(db3b6bfb95261072-weetest.o) is incompatible with /tmp/rustcSdBeHS/symbols.o`. Anybody know what is going on?

07:46 <bitts[m]> * project using the cc, * cc crate. It

10:24 <thejpster[m]> Your Mac will have clang, which is a cross compiler. What C compilers does your docker container have?

10:27 <thejpster[m]> Here’s an example that works on Mac and Linux. The CI pipeline on Linux installs gnu-arm-none-eabi, which cc finds automatically.

10:27 <thejpster[m]> https://github.com/ferrous-systems/threadx-experiments/tree/main/qemu-cortex-r5-app

11:44 <bitts[m]> The docker has both aarch64-none-elf-gcc, tiarmclang, arm-none-eabi (and more). I guess cc needs some more hints on which compiler to choose..

12:32 <whitequark[cis]> folks, what would you use for structured-ish data exchange between Rust and Python code? deserialization perf Python-side matters a lot to me

12:33 <whitequark[cis]> (asking here since I think my preferences for this project are typical for an embedded one, although it all runs on a PC)

12:48 <ben[m]> <whitequark[cis]> "folks, what would you use for..." <- You could look into postcard-rpc. But as far as I know you need to write you own python side for it.

12:48 <ben[m]> James Munns might have some thoughts on this

12:48 <ben[m]> * You could look into postcard-rpc. But as far as I know you need to write you own python side for it.

12:48 <ben[m]> James Munns might have some thoughts on this

12:48 <ben[m]> * You could look into postcard-rpc. But as far as I know you need to write you own python side for it. Perhaps a better solution would be to let postcard-rpc do the deserialisation and call that from within python.

12:48 <ben[m]> James Munns might have some thoughts on this

13:07 <jason-kairos[m]> design question: in a multithreaded system it can be nice to append the name of the thread "battery management thread: starting charge cycle" to serial port println!()s (it's plain ascii, no fancy precomputed defmt etc... (full message at

13:07 <jason-kairos[m]> <https://catircservices.org/_irc/v1/media/download/Aeej_8LLRKvO151zciVUfVkNSc2e11nD-lxk7I4SIyBTH64K8m5ICi3StXQ-X6ZY6RwoRTbClo3yQ3TREmXopCe_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9nUlljYlBmcmdyUmhlU2xuYXFtd0dBa1U>)

13:12 <thejpster[m]> I’d call it “tprintln!”

13:19 <bitts[m]> <ben[m]> "You could look into postcard-rpc..." <- We used postcard + PyO3 a while back, but I would not call the experience smooth. There were quite a few gotchas and things that did not work quite as you would expect. Possible, but I am hesitant to recommend it..

14:24 <JamesMunns[m]> <ben[m]> "You could look into postcard-rpc..." <- Happy to chat about postcard-rpc, it could definitely work through FFI/pyO3, there's definitely no official non-Rust bindings yet.

14:24 <JamesMunns[m]> I'm very open to Python bindings for postcard/postcard-rpc, and have some ideas, but it's definitely not ready to use outside of Rust-to-Rust

14:47 <korbin[m]> <whitequark[cis]> "folks, what would you use for..." <- the new postcard IDL probably

14:47 <JamesMunns[m]> <ben[m]> "You could look into postcard-rpc..." <- Yeah, the new IDL would be one way to generate python bindings, it's still a work in progress tho, and doesn't really do codegen yet. I got pulled off on other things

15:04 <jason-kairos[m]> I noticed when interfacing with a C library using autogenerated bindings that the bindings work if the C library is compiled with llvm/clang and it breaks if it is compiled with GCC.

15:04 <jason-kairos[m]> for certain reasons, I'd prefer to build the C library with GCC but am somewhat mystified that it matters

15:05 <jason-kairos[m]> * for certain reasons, I'd prefer to build the C library with GCC but am somewhat mystified that choice of compiler matters at all for bindings

15:06 <JamesMunns[m]> you probably want to check your build flags for both GCC and LLVM. There are sometimes some subtle differences that will cause problems

15:06 <JamesMunns[m]> off the top of my head, gcc defaults to -fshort-enums for embedded targets, while llvm doesn't

15:07 <JamesMunns[m]> * llvm doesn't (I think?)

15:08 <jason-kairos[m]> that sounds almost exactly like what I was running into (fields of nested unions/structs emulating a dataful enum)

15:09 <JamesMunns[m]> also make sure you are fully configuring bindgen for the specific target you are using

15:09 <JamesMunns[m]> it's been a while since I've had to do it, so I don't remember all the settings off the top of my head, but maybe someone has done bindgen things more recently

15:11 <JamesMunns[m]> https://github.com/nrf-rs/nrfxlib-sys/blob/develop/build.rs might be a reasonable place to start

15:11 <JamesMunns[m]> but in general, it would be good to verify your ABI-sensitive parts, like struct sizes, alignment, float mode, etc.

15:15 <jason-kairos[m]> whoa... they put a lot more care info the autogeneration than I did.... (full message at <https://catircservices.org/_irc/v1/media/download/AeT-jrsQKeziVt_7Lw3vbG-itXgjwUYwc5Pi4yaHY9R3m60qoMEmrjjaR8BNj1QNzGx2er0KKdkYS_gL0yatqj2_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9UY0RwZEV4S21HY1FBUUFUUXl4WFpmYWM>)

15:15 <jason-kairos[m]> s/info/into/, s/./.\/

15:15 <jason-kairos[m]> s/info/into/

15:16 <JamesMunns[m]> yes, all those things. I've done spot checking manually before, I think bindgen will spit out layout tests for you which you can cross check as well

15:17 <jason-kairos[m]> now that I think about it, the proper way might be to inspect the binaries with a script as part of compilation. Pull out the C structure layout and compare it to the rust one using debug symbols. But that would be a great deal of work.

15:17 <jason-kairos[m]> * the binaries in `target/` with a

15:18 <jason-kairos[m]> * the binaries in `target/` with a, * of work. Debug symbols are not fun to work with.

15:21 <JamesMunns[m]> in the past I've very much just stored stuff like `sizeof` in a variable and did gdb stepping to spot check

15:22 <JamesMunns[m]> or printf or whatever

15:22 <JamesMunns[m]> there are probably smarter ways to do it

15:24 <jason-kairos[m]> are the autogenerated tests actually useful?... (full message at <https://catircservices.org/_irc/v1/media/download/ASLHoqvsQVIKlgLHo0CIHDWvMqHL3x3VsrG6EcLDCYdSfEpMxYo_SOPMN5DoOh7_rnKtjbLAidfFX2zeOGJ0reu_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9MakRuZEZIekJOSk5ObnpQcGJDVWFKQ1U>)

15:27 <jason-kairos[m]> surely any test performed in a rust file must implicitly assume that the C library was also compiled with LLVM and probably with certain flags, right?

15:28 <dngrs[m]> you should be able to rely on the C ABI

15:31 <jason-kairos[m]> maybe GCC does noncompliant things by default without certain flags (for example James mentioned `-fshort-enums` which I think is true)

15:31 <jason-kairos[m]> while rust might have a well defined/behaved expectation - it seems the generated library can easily not meet that expectation, and it possibly seems it can go undetected

15:31 <jason-kairos[m]> * maybe GCC does noncompliant things by default without certain flags (for example James mentioned `-fshort-enums` which I think is true)

15:31 <jason-kairos[m]> while rust might have a well defined/behaved expectations of what the ABI "should be" - it seems the generated library can easily not meet that expectation, and it possibly seems it can go undetected

15:32 <jason-kairos[m]> * maybe GCC does noncompliant things by default without certain flags (for example James mentioned `-fshort-enums` which I think is true)

15:32 <jason-kairos[m]> while rust might have a well defined/behaved expectations of what the ABI "should be" - it seems the generated library can easily not meet that expectation, and it possibly seems it can go undetected. At least, that has been my experience with a certain library running a product I'm developing.

15:34 <dngrs[m]> you might find this interesting (unsure if helpful tho): https://faultlore.com/blah/abi-puns/

15:37 <jason-kairos[m]> '“everyone pretends to be C, even though C has the worst and wobbliest ABIs of all time”.'

15:37 <jason-kairos[m]> I like this article - it might just be helpful

15:41 <jason-kairos[m]> it says that rustc, clang, and gcc all generate different incompatible ABIs for certain cases (i128 - which doesn't apply to me). This is shattering my view that compilng the C library with LLVM instead of GCC was automatically safe (it isn't).

15:43 <JamesMunns[m]> it's like all C abis: it's dependent on a lot of unspecified platform things

15:43 <JamesMunns[m]> it's definitely possible to get working, but it does require some care

16:04 <jason-kairos[m]> I think what I have to do is find out what compiler flags this tool uses for it's abi tests.

16:04 <jason-kairos[m]> edit: I guess that ideal is flawed. I'd doubt anyone has tried testing ABI compatibility on ARM Cortex M0+ using this tool - so it wouldn't necessarily know the flags (because it varies by playform/targeT)

16:04 <jason-kairos[m]> [1] https://faultlore.com/abi-cafe/book/harness/combos/toolchains.html

16:05 <jason-kairos[m]> and I suppose nrxlib is for ARM Cortex M33 - not necessarily the same, although it is closer

16:30 <jason-kairos[m]> * I think what I have to do is find out what compiler flags this tool uses for it's abi tests.

16:30 <jason-kairos[m]> edit: I guess that idea is flawed. I'd doubt anyone has tried testing ABI compatibility on ARM Cortex M0+ using this tool - so it wouldn't necessarily know the flags (because it varies by playform/targeT)

16:30 <jason-kairos[m]> \[1\] https://faultlore.com/abi-cafe/book/harness/combos/toolchains.html

17:08 <dngrs[m]> the one thing I can say from experience is that stuff like [the cmsis-dsp Rust bindings](https://github.com/samcrow/cmsis_dsp.rs) has worked for me, and from what I can tell it uses prebuilt libraries that were made with GCC, see https://github.com/samcrow/cmsis_dsp.rs/blob/master/cmsis_dsp_sys_pregenerated/build.rs#L73

17:39 <jason-kairos[m]> that's interesting

17:39 <jason-kairos[m]> I wonder if any manufacturers have done this work already (in a way that is publicly visible) but I don't necessarily know who or what.

17:39 <jason-kairos[m]> I think math functions have relatively simple function signatures / types / etc. - not many structs, unions, enums, etc. which probably makes the task of "getting it right for the subset of things that the DSP library uses" a lot easier than getting everything correct in general

17:41 <jason-kairos[m]> * that's interesting... (full message at <https://catircservices.org/_irc/v1/media/download/AWm1UIDTLK537Jn-T1INn2Z74zQZQCqA9fDeR9UXs0lSYfvopA06qNUYcEkPeNLrCIVAu-Oww-5ZwcJO2pdVbWW_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9vR0Rzem5ET2lubW9Gb1pmbHBIV2FIZGE>)

18:54 <whitequark[cis]> <korbin[m]> "the new postcard IDL probably" <- thanks, this is the kind of answer I am interested in! I'm considering this as an alternative to a fully homegrown serialization format, so having to implement a bunch of stuff doesn't scare me

18:58 <whitequark[cis]> whitequark[cis]: basically what I want is a way for gateware to produce byte streams that can be easily consumed by both Rust and Python code

19:12 <JamesMunns[m]> <korbin[m]> "the new postcard IDL probably" <- https://github.com/jamesmunns/postcard-idl is here, the wire spec for `postcard` is here: https://postcard.jamesmunns.com/

19:12 <JamesMunns[m]> I've started writing out a more formal description of postcard-rpc here: https://postcard.rs/, the top level docs of postcard-rpc also aren't a bad example of how things currently work: https://docs.rs/postcard-rpc/latest/postcard_rpc/

19:13 <JamesMunns[m]> <korbin[m]> "the new postcard IDL probably" <- https://matrix.to/#/#onevariable:matrix.org is usually where I chat about postcard-specific stuff, happy to answer any questions here or there tho!

19:15 <whitequark[cis]> <whitequark[cis]> "basically what I want is a way..." <- I wonder if I should adopt the postcard-rpc architecture wholesale for Glasgow internals

19:16 <whitequark[cis]> whitequark[cis]: it's solving more or less the same problem

19:19 <JamesMunns[m]> <korbin[m]> "the new postcard IDL probably" <- ooh, very cool!

19:20 <JamesMunns[m]> <korbin[m]> "the new postcard IDL probably" <- My current research area is actually trying to formalize more of a "net stack" based on the concepts from postcard-rpc, so I can also handle things like "bridged nodes", where you have a PC talking to a device over USB, which is then connected to another device over UART

19:20 <JamesMunns[m]> <korbin[m]> "the new postcard IDL probably" <- I have some hacky limited "bridging" capability for this, but it's a very "network stack and routing" shaped problem

19:21 <JamesMunns[m]> <korbin[m]> "the new postcard IDL probably" <- and then, eventually, I'd like to use it as the basis of the kernel message passing interface for mnemos, but, that's more "eventually" :D

23:09 <KevinPFleming[m]> <whitequark[cis]> "it's solving more or less the..." <- I am using protobuf, with the micropb crate on the Rust side.