Re: [RFC PATCH 00/34] The rest of the x86_64-gnu port

[Luca]

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