Il 19/03/23 18:39, Sergey Bugaev ha scritto:
Once this works, you should be able
to build ext2fs.static, exec.static and run a "hello-dynamic-glibc" test
by replacing /hurd/startup, which is the first dynamically-linked
executable started.
Actually no, exec is the first dynamic executable already, it's started as
/lib/ld.so.1 /hurd/exec
I guess you can use either the static version or the dynamic one
Yes yes, I know that already (but thank you). What I'm saying is this
did not work for me, I was unable to break there. I think I was unable
to even set the breakpoint?
That is quite strange. If you can't even set a breakpoint, there is
clearly some difference in the commands we run (see below for mine)
IIUC, gdb breakpoints work by overwriting a single byte of code with
int3 (though I wonder how that works in absence of Unix/SIGTRAP?..),
so the code needs to be present in the virtual memory already when you
place the breakpoint. How/when does that happen, when does Mach switch
/ set up the pagetables?
I don't know how gdb actually sets the breakpoint, I guess it relies on
the gdb server (so qemu), which maybe emulates a hardware breakpoint.
How do you even attach gdb to qemu properly without racing against
Mach starting up? qemu -S doesn't work (unlike on i386), since if you
attach GDB immediately at startup, it freaks out about some message
size mismatch, apparently related to the long mode switch.
The only time I've seen this error was when using qemu-system-x86_64 to
debug a 32-bit kernel, or vice-versa.
Ah, I was breaking to the entry address (as specified in the ELF
header) directly, not via symbol, so that shouldn't have been an
issue.
But you're still setting a breakpoint very early anyway, I don't think
it's relevant if you use the symbol or the address directly. From what
I've seen in this case, it seems like stopping execution so early loads
some state in gdb that is not updated later. For example, I had issues
stepping over instructions that update GDT, enable paging or long mode.
I didn't have issues if during debug these "special states" were not
updated, so I'm able to debug either the very early boot or the late boot.
Well, yes, thank you, but as you can see, I knew most of that already,
so that doesn't really solve my issue :( Maybe I just need to try
again, maybe it will work this time. In the meantime, please try
building my glibc branch with the hello world static executable and
see if that works on your setup.
I might have missed it from the previous emails, do you have a git repo
I can pull from?
Just to be clear, this is what I run in my tests from the "qemu" terminal:
$ qemu-system-x86_64 -m 512 -nographic -no-reboot -cdrom test-hello.iso
-gdb tcp::1234 -S
and I launch gdb from another folder, where I have a .gdbinit with:
--------8<----------
set print pretty
set $xxx=sizeof(void*)
if $xxx == 8
target remote :1234
add-symbol-file ../gnumach/build-64/module-hello
else
target remote :11234
end
display/i $pc
b Panic
b Assert
--------8<----------
then I can break both in kernel and user space, from the "gdb" terminal:
--------8<----------
$ gdb ../gnumach/build-64/gnumach
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../gnumach/build-64/gnumach...
0x000000000000fff0 in ?? ()
add symbol table from file "../gnumach/build-64/module-hello"
Breakpoint 1 at 0xffffffff810130e0: file ../kern/debug.c, line 138.
Breakpoint 2 at 0xffffffff81013200: file ../kern/debug.c, line 62.
(gdb) b setup_main
Breakpoint 3 at 0xffffffff81019d60: file ../kern/startup.c, line 98.
(gdb) c
Continuing.
Breakpoint 3, setup_main () at ../kern/startup.c:98
98 cninit();
1: x/i $pc
=> 0xffffffff81019d60 <setup_main>: sub $0x18,%rsp
(gdb) bt
#0 setup_main () at ../kern/startup.c:98
Backtrace stopped: Cannot access memory at address 0x1000146
(gdb) b main
Breakpoint 4 at 0x401000: file ../tests/test-hello.c, line 6.
(gdb) c
Continuing.
Breakpoint 4, main (argc=0, argv=0xbfffff1c, envc=-1073742052, envp=0x34)
at ../tests/test-hello.c:6
6 {
1: x/i $pc
=> 0x401000 <main>: push %rbp
(gdb) bt
#0 main (argc=0, argv=0xbfffff1c, envc=-1073742052, envp=0x34) at
../tests/test-hello.c:6
#1 0x0000000000402f17 in _start () at ../tests/testlib.c:123
#2 0x0000000000000004 in ?? ()
#3 0x00000000bfffffec in ?? ()
#4 0x00000000bffffff9 in ?? ()
#5 0x00000000bffffffc in ?? ()
#6 0x00000000bffffffe in ?? ()
#7 0x0000000000000000 in ?? ()
(gdb)
--------8<----------
Luca
