oxidecomputer / humility

Debugger for Hubris
Mozilla Public License 2.0
526 stars 50 forks source link

Bad read of image ID from archive built with 1.75.0 #470

Closed cbiffle closed 5 months ago

cbiffle commented 5 months ago

So, this is weird. I'm attempting to upgrade Hubris to Rust 1.75.0, and while I've fixed the first thing I hit (#468) I'm now getting this:

$ target/debug/humility -a ../hubris3/target/demo-stm32h753-nucleo/dist/default/build-demo-stm32h753-nucleo-image-default.zip map
humility: attached via ST-Link V3
humility map failed: image ID in archive ([bc, 8f, 32, ff, a6, c6, aa, 68]) does not equal ID at 0x8005600 ([1, 0, 0, 0, 48, 0, 0, 0])

This is ... not correct: using objdump I can see the correct ID in the kernel image. (Ignore the part where it's frantically attempting to decode it as ARM instructions.)

08005600 <HUBRIS_IMAGE_ID>:
 8005600:       ff328fbc                        @ <UNDEFINED> instruction: 0xff328fbc
 8005604:       68aac6a6        stmiavs sl!, {r1, r2, r5, r7, r9, sl, lr, pc}

I'm not sure how this could have broken, so I'm at a bit of a loss for where to even look to fix it.

cbiffle commented 5 months ago

Here's the build archive in question:

build-demo-stm32h753-nucleo-image-default.zip

Humility here is on my cbiffle/fix-signed-variants branch, so it might have been something I broke, but it seems pretty unlikely.

cbiffle commented 5 months ago

.......okay, this turns out to have been my mistake, but it's a bit of a footgun:

Humility commands that work both offline and online will attach to an available board, even if you didn't realize it was plugged in. So guess what I had plugged in.