Install feedback

[bacam]

Earlier this week I successfully followed the installation instructions on our Morello box. I've a few bits of feedback that you can use/chop up/ignore as you like:

• The build instructions use ./cheribuild rather than ./cheribuild.py.
• The firmware update instructions are a little awkward because the Android build the Arm guide expects the firmware to be taken from has the firmware split up into two different directories, but the repository linked to in this guide has everything in one place.
• I didn't get the expected results from running gdb on the hello world example. When compiling with -O2 the printf is turned into a puts, and I also found that it usually steps over the library function and never seems to print function arguments (maybe I'm missing a libc debug package?).
• Is there anything to be said about updating the system, both for new releases and for package updates?

[bacam]

One other suggestion that occurred to me is to mention cheribuild's --source-root and -j options.

[rwatson]

• I didn't get the expected results from running gdb on the hello world example. When compiling with -O2 the printf is turned into a puts, and I also found that it usually steps over the library function and never seems to print function arguments (maybe I'm missing a libc debug package?).

@brooksdavis -- do you mind taking a look at this point?

[rwatson]

• The firmware update instructions are a little awkward because the Android build the Arm guide expects the firmware to be taken from has the firmware split up into two different directories, but the repository linked to in this guide has everything in one place.

I was also wondering about whether we need to provide our own firmware installation instructions. But we should ping Arm as well to look at updating their guide for the precompiled binaries as provided by GitLab CI.

[rwatson]

• Is there anything to be said about updating the system, both for new releases and for package updates?

That’s a good question. We probably need, if nothing else, some words about package building expectations, and also about ABI breakages [which will inevitably happen .. one is due this upcoming week, in fact!].

@kwitaszczyk, @gvnn3 is this something you could look at?

[kwitaszczyk]

@kwitaszczyk, @gvnn3 is this something you could look at?

@rwatson I will add a subsection on package upgrades in the third-party packages section.

Regarding new releases, we should document that we don't support system upgrades at the moment. Instead, some reinstall path should be recommended not to loose any data. We probably must discuss what exactly should be documented there but maybe @gvnn3 @brooksdavis @jrtc27 @bsdjhb already have some ideas?

[brooksdavis]

• I didn't get the expected results from running gdb on the hello world example. When compiling with -O2 the printf is turned into a puts, and I also found that it usually steps over the library function and never seems to print function arguments (maybe I'm missing a libc debug package?).

@brooksdavis -- do you mind taking a look at this point?

I've updated the example to reflect the optimization as best I can working in qemu. Skipping the library function entirely seems broken, but I'm been unable to reproduce that. Someone with hardware should look into it.

#8

[kwitaszczyk]

@rwatson I will add a subsection on package upgrades in the third-party packages section.

I added a separate PR for this change: #12.

@bacam, could you tell if the PR covers information you would expect from such section?

[kwitaszczyk]

FYI #12 is merged now.