KMessage is a very big class, it’s just too much trouble for the optional CWD information.
If more features require KMessage I might re-consider, but now it’s just not worth it.
GDB somehow fails to refresh the breakpoint list.
It actually did not. Breakpoint lists were refreshed at the correct time.
What was incorrect was the memory map kept by GDB (implemented using the memory_map target_ops method, inspectable from the CLI by info mem. This map was outdated and still represents the memory region of the old process, making GDB confused when trying to write the new breakpoint.
1 Like
This map was outdated and still represents the memory region of the old process.
The solution to this? Invalidate the maps whenever a solib event occurs.
The latest force-push should fix this issue.
Still the same problem: gdb-cmds1441430974825977309.log · GitHub.
gdb-15-haiku-v6 3b37601dc21 gdb: Initial Haiku support
Strange, considering the way all symbols are loaded yet all breakpoint addresses are not relocated.
Do you have a log for an older commit where breakpoints still work?
For example, at 2811298fd03945f9498ffbee7a5daa4430adfdaa.
gdb-15-haiku-v3 785faff8451: OK
gdb-15-haiku-v4 2811298fd03: Error
gdb-15-haiku-v3 log: gdb-cmds5654615719044095433.log · GitHub
The difference between your v3 and v4 is that one moves the executable relocation code to haiku-nat.c 
Comparing 785faff8451…2811298fd03 · trungnt2910/gdb-haiku (github.com)
I think this may be the reason:
solib_create_inferior_hook (from_tty);
/* [truncated] */
breakpoint_re_set ();
gdb::observers::inferior_created.notify (current_inferior ());
Previously, the main executable relocation was handled in the solib_create_inferior_hook, which is called before breakpoint_re_set. Now, it is handled by an observer callback, called after breakpoint_re_set, causing the issue.
Can you please try f72b729f1142cb56307b6ddb82a758cae1a1b6aa and generate a log?
gdb-15-haiku-v7 f72b729f114: Error
So, I’ve been able to reproduce the bug but only using the MI interface, with these commands:
4-file-exec-and-symbols "/boot/home/Desktop/demo"
5-break-insert -t _start
6-exec-run
Doing the equivalent in the normal CLI does not trigger the bug
1 Like
7e8b3bdfb should fix this test case.
Please try 9e1d04fb9ca9a7d6b327eadd16c3e2f4deba8107.
“Cannot insert hardware breakpoint” and stuck at _start are fixed. Breakpoints set before program execution are working.
Bugs:
-
Breakpoints set during program execution cause debugged program to immediately exit. The same thing happens if attempt to pause execution with toolbar button.
-
Stack trace is not correctly displayed. Local variables can’t be read.
Correct stack trace and variables:
Broken stack trace and variables (maybe related to that it run in another thread):
Currently, unlike on Linux, on Haiku, when a thread hits an event, only the affected thread stops. Other threads continue execution as normal.
Setting breakpoints or getting the stack trace involves reading/writing the process memory, which can only be done when the target thread has stopped due to a debugger event.
Would be nice if you could also get a log for this; I’ll look at that in the morning.
I’ve fixed this issue by declaring Haiku as a “non-stop” execution target. Hopefully this should make GDB more compatible with Haiku’s behavior.
Furthermore, I’ve also fixed some issues I’ve encountered when attaching to some typical Haiku programs.
You can try my latest force-pushed code.
Based on the log, I don’t see any breakpoints being set by Netbeans during program execution. The inferior seems to have exited normally.
I can’t see any commands related to that either. Netbeans should have attempted to interrupt or something like that.
Strange, based on the log I see that you’ve hit a breakpoint on the correct thread. get_cpu_state must have been faulty somehow.
Can you enable additional logging by enabling Haiku native logging? set debug haiku-nat on or -gdb-set debug haiku-nat on if you’re using the MI interface.
2 Likes
Pushed a new small update with ASLR disabling support.
If there are no new bug reports or reasonable feature requests I’ll consider GDB finished for the scope of this project. I’ll proceed to making the recipe and delivering a progress report blog at the end of the week.
7 Likes
6 Likes
First recipe revision.
4 Likes