[Debugger] Add some missing features with respect to core filesupport

[anevilyak]

With the recent addition of corefile support to the system and Debugger, one or two extra pieces would be handy:

• Currently, one can only specify loading a corefile via a command line switch. Ideally, one should be able to do so graphically as well. Probably the most straightforward path would be adding a button to do so to the Teams window as an additional alternative to attach / start new team.
• A CLI command to request a core dump of the currently attached team is needed, as in the case of an app_server/registrar crash this would be highly desirable, as it'd provide more useful crash analysis capabilities than the current reports.

[pulkomandy]

Debugger could also register a filetype for core files so it's possible to simply open them from Tracker by double clicking them.

[anevilyak]

That's certainly possible, but that'd first require a sniff rule for them. Ingo would be able to say for certain, but since my understanding is that they're largely ELF files, such a rule might not be trivial/foolproof to write, nor am I certain if it'd be possible to explicitly set the mimetype in all cases, since e.g. for the current case of asking to save one at the crash dialog, the request is made directly by debug_server, and the actual core dump write is handled by the kernel.

[bonefish]

A sniffer rule shouldn't be a problem. The ​e_type field of the ELF header, a 16-bit integer at offset 16, specifies the type of the ELF file. The value 4 indicates a core file. One would need two cases to deal with little and big endianess, which is indicated by the byte at offset 5 (1 == little, 2 == big).

The real problem is the icon. ;-)

[bonefish]

MIME type for core files and RefsReceived() handling in Debugger added in hrev50254.

[anevilyak]

I don't suppose we already have a vector icon for a mushroom cloud...

[anevilyak]

Added graphical core loading button in hrev50255. That just leaves the CLI command and corresponding support in {Local}DebuggerInterface.

[anevilyak]

Added necessary supporting hooks and write-core CLI command in hrev50258. This completes the items mentioned in this ticket. There are still a few other core-related UI quirks remaining though, that should probably be addressed in their own ticket. Most notably, when debugging a core, the thread state is currently marked as 'Debugged', and consequently the UI thinks one can happily run/step such threads. I'd suggest adding a new thread state such as, say, THREAD_STATE_AUTOPSY to mark such threads so the UI has a way to discriminate that thread control is entirely unavailable, and disable the buttons accordingly.

[bonefish]

I'd rather keep the original thread state (might be useful information) and instead mark the team respectively and disable the live debugging features (break/watch points) depending on that. I intend to do that, but I'd first like to get the symbols going, so that core file debugging becomes useful at all.

[anevilyak]

Replying to bonefish:

I'd rather keep the original thread state (might be useful information) and instead mark the team respectively and disable the live debugging features (break/watch points) depending on that. I intend to do that, but I'd first like to get the symbols going, so that core file debugging becomes useful at all.

Sounds good. As far as symbols, I assume that only applies to a core for a release binary? At least an induced crash + core from a debug binary over here resulted in both symbols and variables being displayed for the respective thread. On a related note, is it planned for cores to also be able to store the heap of the crashed team? At least from what I saw of your commits that didn't appear to be the case yet, but I may have missed it.

[bonefish]

Replying to anevilyak:

Sounds good. As far as symbols, I assume that only applies to a core for a release binary? At least an induced crash + core from a debug binary over here resulted in both symbols and variables being displayed for the respective thread.

Good to know, I haven't tested that yet. :-) Without debug info from the shared object we rely fully on what DebuggerInterface returns, which in case of core file is currently an empty list.

On a related note, is it planned for cores to also be able to store the heap of the crashed team? At least from what I saw of your commits that didn't appear to be the case yet, but I may have missed it.

All of the team's areas are stored in the core file and CoreFileDebuggerInterface::ReadMemory() is implemented as well. So at least in theory heap access should already work. I haven't tested it yet, though.

[anevilyak]

Replying to bonefish:

Good to know, I haven't tested that yet. :-) Without debug info from the shared object we rely fully on what DebuggerInterface returns, which in case of core file is currently an empty list.

One point that's unclear to me for this: Since, based on the aforementioned debug case, we are in fact loading the corresponding executable image as well, is there any reason the core file needs to be used for symbols rather than reading them from said image like usual? I assume that's only necessary so one can analyze the core in the absence of having a local copy of the executable in question?

All of the team's areas are stored in the core file and CoreFileDebuggerInterface::ReadMemory() is implemented as well. So at least in theory heap access should already work. I haven't tested it yet, though.

Good to know, the simple test I had was only using stack variables, so I was uncertain if areas outside of the thread stacks were being stored.

[bonefish]

Replying to anevilyak:

One point that's unclear to me for this: Since, based on the aforementioned debug case, we are in fact loading the corresponding executable image as well, is there any reason the core file needs to be used for symbols rather than reading them from said image like usual? I assume that's only necessary so one can analyze the core in the absence of having a local copy of the executable in question?

The latter is one reason. There are also images (well, one image, the "commpage") without a corresponding file. That's why symbols are fetched via the DebuggerInterface, which should know how to retrieve the information. In the local case the implementation does indeed open the shared object file, if available, falling back to reading the runtime loader information from the team's memory. We can do pretty much the same for core files -- with the distinction that we can't use the debug kit code and that the team memory is more readily available. It probably makes most sense to port the relevant debug kit code to Debugger and make it bitness, endianess, and access method agnostic.

Moreover we'll need an indication that an image is possibly or definitely not local and do file path mapping in this case.