Read in a crash or oops-style backtrace and access DWARF information to output the current content of the stack and registers in term of symbols, and the the crash commands to dump/pretty print them. In other words, when looking at a crash dump, answer the questions "Which variable is currently stored in $rax? What is the structure of the stack? Which variable is stored at $rsp+16?"

Status at the end of hackweek 10

New Development In previous hack weeks, the first few days ended up being wasted on just getting it working. I'm pleased to share that the code quality has improved dramatically since the last hack week and there are now extensive test cases for both unit testing and testing against real vmcores, and we'll use both mypy and pylint (if installed) to perform static analysis. Packages for those are available in openSUSE or as part of the crash-python OBS repo for SLE15. It has been tested with kernels from 3.0 to 5.1.

This is the tool I've been working on since HW11 and it needs more work. Actually, there's always something which could be done on it. It is basically an x86 instruction decoder with special emphasis on the kernel and decoding interesting pieces of it in order to help in the development of low-level patching techniques, among others. git repo: https://gitlab.suse.de/bp/x86d

cscope is a great tool index C/C++ sources and allow to navigate through the code. I have learned that the project is mostly dead and what is worse it uses its own database format to store the index. I would like to see some extended functionality in the tool - e.g. search whether a function A is reachable from B, filtering search results per-file, fix functions with function parameter detection (such functions are not recognized properly currently) and some others. See if the cscope specific storage can be replaced by a more generic database (sqlite?) and understand how the code flow works so that new extensions would be easier to implement.

Look once again on Xperia Tablet Z and try to have there openSUSE running natively as alternative operating system. I'm able to work on that only during my vacations or hackweeks so

Recently I became a (not very proud) owner of Acer Aspire Switch 10E, a small notebook/tablet convertible based on Intel baytrail platform. Replacing preinstalled (32-bit!) Windows 8.1 with (64-bit) openSUSE proved more challenging than expected, mostly because the device is haunted by a 32-bit UEFI so that it took me a week to make it boot without an external USB flash disk. Even today, a lot of issues persist. As I do not want to waste a (partially) good hardware, I would like to make it as usable as possible. This is much less selfish than it sounds as there are many other devices based on Intel baytrail platform so that the effort is going to help their owners as well (if successful, that is).

https://gitlab.suse.de/l3ms/RES-weather/ needs some improvements, e.g. manual generation of statistics and reports.