News for hackers. Stuff that matters.
Re:This shouldn't have happened: A vulnerability postmortem by jtchang on Wednesday December 01, 2021 @03:32PM (#29408793)
I'd like to write go or rust but embedded constraints are tough. I tried and the binaries are just too big!
Re:This shouldn't have happened: A vulnerability postmortem by jrockway on Wednesday December 01, 2021 @04:02PM (#29409097)
How big is too big? I haven't run into any size issues writing very unoptimized Go targeting STM32F4 and RP2040 microcontrollers, but they do have a ton of flash. And for that, you use tinygo and not regular go, which is technically a slightly different language. (For some perspective, I wanted to make some aspect of the display better, and the strconv was the easiest way to do it. That is like 6k of flash! An unabashed luxury. But still totally fine, I have megabytes of flash. I also have the time zone database in there, for time.Format(time.RFC3339). Again, nobody does that shit on microcontrollers, except for me. And I'm loving it!)

Full disclosure, Python also runs fine on these microcontrollers, but I have pretty easily run out of RAM on every complicated Python project I've done targeting a microcontroller. It's nice to see if some sensor works or whatever, but for production, Go is a nice sweet spot.

Re:This shouldn't have happened: A vulnerability postmortem by jtchang on Thursday December 02, 2021 @12:27PM (#29419283)
I have 16MB of flash and I wanted to link in some webrtc Go library and the binary was over 1MB. As I had other stuff it seemed like C was smaller.
Re:This shouldn't have happened: A vulnerability postmortem by jrockway on Thursday December 02, 2021 @03:25PM (#29422002)
I took a look at using github.com/pion/webrtc/v3 with tinygo, but it apparently depends on encoding/gob which depends on reflection features that tinygo doesn't implement. No idea why they need that, but that's the sort of blocker that you'll run into.
Re:This shouldn't have happened: A vulnerability postmortem by steveklabnik on Wednesday December 01, 2021 @03:44PM (#29408906)
The smallest binary rustc has produced is 138 bytes.

It is true that it’s not something you just get for free, you have to avoid certain techniques, etc. But rust can fit just fine.

Re:This shouldn't have happened: A vulnerability postmortem by cjg on Wednesday December 01, 2021 @04:19PM (#29409265)
Do you have a link to an article / report about that 138 byte program? I'd be interested how to achieve that.
Re:This shouldn't have happened: A vulnerability postmortem by eat_veggies on Wednesday December 01, 2021 @04:47PM (#29409558)
https://github.com/tormol/tiny-rust-executable got it to 137, but here's a blog post explaining the process to get it to 151: http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-...
Re:This shouldn't have happened: A vulnerability postmortem by haberman on Wednesday December 01, 2021 @04:52PM (#29409598)
I'd also like to see the smallest Rust binaries that are achieved by real projects. When the most size-conscious users use Rust to solve real problems, what is the result?
Re:This shouldn't have happened: A vulnerability postmortem by steveklabnik on Wednesday December 01, 2021 @07:09PM (#29410846)
Our embedded OS, Hubris, released yesterday, with an application as well, the entire image is like, 70k? I’ll double check when I’m at a computer.
Re:This shouldn't have happened: A vulnerability postmortem by steveklabnik on Wednesday December 01, 2021 @09:14PM (#29411722)
Yeah, so, using arm-none-eabi-size, one of these apps I have built, the total image size is 74376 bytes. The kernel itself is 29232 of those, the rest are various tasks. RCC driver is 4616, USART driver is 6228.

We have to care about binary size, but we also don't have to stress about it. There are some things we could do to make sizes get even smaller, but there's no reason to go to that effort at the moment. We have the luxury of being on full 32-bit environments, so while there isn't a ton of space by say, desktop or phone standards, it's also a bit bigger than something like a PIC.

Lots of folks also seem to get the impression that Rust binary sizes are bigger than they are because they use ls instead of size; we care deeply about debugging, and so the individual tasks are built with debug information. ls reports that rcc driver is 181kb, but that's not representative of what actually ends up being flashed. You can see a similar effect with desktop Rust software by running strip on the binaries, you'll often save a ton of size from doing that.

Re:This shouldn't have happened: A vulnerability postmortem by dochtman on Wednesday December 01, 2021 @03:38PM (#29408844)
This is not true. Lots of people are putting Rust on microcontrollers now - just have to stick to no_std.