Store vmlinux for builds

[broonie]

Currently we do not store the vmlinux generated as part of the kernel build, having access to it can be very useful when debugging issues especially those that generate stacktraces since ./scrupts/decode_stacktrace.sh can use it to translate log messages with addresses:

<4>[ 62.189031] do_el0_svc_compat+0x24/0x48

into references to the file and line number the relevant code was generated from:

<4>[ 62.189031] do_el0_svc_compat (arch/arm64/kernel/syscall.c:159)

In the past with the old storage server we didn't save vmlinux since it tends to be quite large even compressed, with the new storage implementation it should be a lot easier to handle storing the vmlinux so we should revisit this.

[broonie]

Requested by Linus in: https://lore.kernel.org/r/CAHk-=wh=PVSpnca89fb+G6ZDBefbzbwFs+CG23+WGFpMyOHkiw@mail.gmail.com

[nuclearcat]

Will proceed. I think to find some reasonable tradeoff, do you think it is enough to store vmlinux for 1 month only or we need to store it 6 month as all other data?

[gctucker]

See also: kernelci/kernelci-core#1637

[gctucker]

I can't find any GitHub issue about the idea of running post-processing jobs to add extra debug information and decode stacktraces but I've replied to the email thread to explain the idea. This was proposed a few years ago when the new API design was being worked on as the legacy Jenkins system wasn't a good base for adding this kind of feature. Then a more recent idea is to generalise this with dynamic scheduling to decide which builds and tests to run based on results as they come in. I should be writing a blog post about this in the near future too.