Debugger: Use BString::HashValue().Previously BString::HashValue() had an identical hash to the onein StringUtils::HashValue(), but now it uses hashdjb2, so thismeans Debugger will now use that a
Debugger: Use BString::HashValue().Previously BString::HashValue() had an identical hash to the onein StringUtils::HashValue(), but now it uses hashdjb2, so thismeans Debugger will now use that also.Tested basic Debugger functionality, seems to still work.Change-Id: Ia341daa56249967a494df46e6e0a69a74c8b5fe2Reviewed-on: https://review.haiku-os.org/c/haiku/+/8266Reviewed-by: Rene Gollent <rene@gollent.com>
show more ...
Debugger: Fix #13939, more work on #13800.- Fix various cases where OpenHashTables weren't being cleared properly.- Fix various reference counting errors.- Simplify FileManager reference handling
Debugger: Fix #13939, more work on #13800.- Fix various cases where OpenHashTables weren't being cleared properly.- Fix various reference counting errors.- Simplify FileManager reference handling.- Fix bug in LocatableDirectory where the directory named '/' would have its name returned as empty. This would lead to failed lookups for entries already in the table, and ultimately corrupted the hash table when deleting unused entries, leading to #13939. This was previously never noticed due to the entries not being freed properly.- AbbreviationTable wasn't clearing its entries.
Debugger: Rework parts of report generation.Team:- Adjust report generation event to include a final status code for listeners.CliContext,TeamWindow,ReportUserinterface:- Use aforementioned sta
Debugger: Rework parts of report generation.Team:- Adjust report generation event to include a final status code for listeners.CliContext,TeamWindow,ReportUserinterface:- Use aforementioned status code to indicate whether report generation succeeded or failed.DebugReportGenerator:- Notify listeners if report generation fails. This may have previously been responsible for some bug reports where it was indicated that the debugger hung without exiting after being asked to save a report from a crashed app.- When dumping disassembly, retrieve it directly if necessary rather than requesting it via the user interface listener. This also fixes the quirk that requesting to save a crash report while looking at the source code of a function would trigger switching it to disassembly visually.- When walking the list of threads to dump, acquire references to all of them before starting. Otherwise, it was potentially possible for a running but not crashed thread to exit while we were generating the report, leaving us with a pointer to a deleted thread. This was most likely the cause of one of the crashes reported in #13082.- When receiving the notification that source code state has changed, clear the waiting function. Otherwise, it was potentially possible for us to get other state change notifications, leading to the data semaphore being released too often. This would then cause later potential waits such as the stack frame memory dump to not actually wait when they should, potentially leading them to dereference objects that weren't yet ready. This fixes another of the crashes in #13802.
Debugger: Fix #12940.- Add new interface TeamFunctionSourceInformation. Currently this exposes a single function allowing one to query for the currently active source code given a FunctionDebug
Debugger: Fix #12940.- Add new interface TeamFunctionSourceInformation. Currently this exposes a single function allowing one to query for the currently active source code given a FunctionDebugInfo instance.- Implement TeamFunctionSourceInformation on TeamDebugInfo.- Pass TeamFunctionSourceInformation to Dwarf{Team,Image}DebugInfo. In turn, make use of it in DwarfImageDebugInfo::GetStatement() in order to determine whether to return the corresponding assembly or source statement.With this piece of information, the debugger is now correctly able todetermine that the user is currently looking at disassembly despite debuginfo being available, and consequently adjust its stepping behavior based onthat. Previously, the source code statement was always used, leading to itnot being possible to single step assembly lines in such a circumstancewithout manually using run to cursor.Other related cleanups:- TeamDebugInfo now inherits BReferenceable directly, rather than relying on indirectly inheriting it from TeamTypeInformation.- Remove BReferenceable from TeamTypeInformation. The latter is only an interface anyways, and inheriting that base class from multiple locations was causing GCC5 trouble when resolving BReference<TeamDebugInfo>, even when virtual inheritance was used.
Debugger: Split into core library and application.- Add subfolder src/kits/debugger which contains the debugger's core functionality and lower layers. Correspondingly add headers/private/debugger
Debugger: Split into core library and application.- Add subfolder src/kits/debugger which contains the debugger's core functionality and lower layers. Correspondingly add headers/private/debugger for shared headers to be used by clients such as the Debugger application and eventual remote_debug_server. Adjust various files to account for differences as a result of the split and moves.- Add libdebugger.so to minimal Jamfile.