Hello, Returning to L4Re investigations with newer hardware (hosting qemu on the amd64 architecture), I have been trying to debug some of my hastily written code that undoubtedly has a race condition lurking in it. Unfortunately, I cannot remember the way of discovering how to identify the source instruction responsible (if I ever really knew it to begin with).
I get an error like this: L4Re[rm]: unhandled read page fault at 0x38 pc=0x3a8bd9 Previous experiences suggested that I might not get much sense out of the program counter value, and it was also suggested to me that I might try and use the kernel debugger to show the thread execution state. I dug up instructions to achieve this... 1. Modify pkg/l4re-core/l4re/util/include/region_mapping_svr_2 and pkg/l4re-core/l4re_kernel/server/src/region.cc to employ enter_kdebug invocations. 2. Add jdb = L4.Env.jdb in the capabilities section of the start or startv invocation that invokes the task in the appropriate .cfg file. 3. Run the system and wait for an exception to trigger the debugger. 4. Use the t<enter> command sequence to see the thread state. 5. Use <space> to enter the disassembly and see the supposedly problematic instruction. Unfortunately, this seems to add confusion. Firstly, I end up with a different location: ffffffff10455e98. Even if I assume that the actual location is 455e98, being somewhat near to the usual payload base address of 400000, it doesn't help me identify what the code is that resides there. Normally, I would attempt to use addr2line, nm or objdump to provide some kind of map, but I cannot see any correspondence between their output and these values. I also considered, since my code is dynamically linked, that I might need to get the linker to tell me a bit more about where it is positioning library code in memory. This was suggested in another context a couple of years ago: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2018/008274.html However, the only vaguely pertinent output I can find is this: _dl_protect_relro:124: RELRO protecting rom/libuc_c.so: start:0x3a6000, end:0x3a7000 _dl_protect_relro:124: RELRO protecting rom/libdl.so: start:0x3bf000, end:0x3c0000 If the 3a8bd9 value is meaningful, it evidently refers to something between these two regions, if these regions are valid. I thought that there was a more coherent summary of loaded objects, but I cannot find any details of that now. I imagine that there must be a simpler way of getting back to the source from exception addresses and would greatly appreciate being told (or reminded) what that is! Thanks in advance, Paul _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
