It appears you skipped over the padding between vendor length and number of formats...

[mrtodd]

I could be wrong, but looking at the X documentation there appears to be padding between the vendor length and the number of formats (reference: your x11_send_handshake function). Since the vendor string was likely "The X.Org Foundation" which is 5*4 bytes long, no padding was required for this case.

I was trying to use gdb to look at this, but it complains about no line number information in the executable. I compiled with '-g' so I expected all the required debug info to be there. Do you know what might be the problem? I'm using the following: NASM version 2.15.05 / GNU ld (GNU Binutils for Ubuntu) 2.38 / GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1 in case it is a version specific problem.

I ended up doing a system call to write the vendor string to STDOUT.

-- Todd

[gaultier]

Good catch, the docs explicitly mention the padding:

     v     STRING8                         vendor
     p                                     unused, p=pad(v)        -----> Padding there
     8n     LISTofFORMAT                   pixmap-formats 

I'll try to make a fix in the next days.

It boils down to padding to the next multiple of 4.

libX11 uses this macro:

#define ROUNDUP(nbytes, pad) (((nbytes) + ((pad)-1)) & ~(long)((pad)-1))

and gcc optimizes it to:

  add     eax, 3
  and     eax, -4

[mrtodd]

I am curious if gdb works for you. Since I'm not getting line number information into my output ELF64, it just runs to the end of the program when I try to single step through the code and the only place I can set breakpoints is at labels. I guess I could just put a bunch of labels into the code around the part I want to look at.

This is what I did to see the vendor string in your "x11_send_handshake" function:

. . .
;; mov eax, DWORD [rdi] ; Store (and return) the window root id.
mov r10d, DWORD [rdi] ; Store (and return) the window root id.

; Set the root_visual_id globally.
mov edx, DWORD [rdi + 32]
mov DWORD [root_visual_id], edx

; DEBUG -- output vendor string
mov rax, SYSCALL_WRITE ; this smashes the result in eax so used r10d as a temp
lea rsi, [rsp + 32]
mov BYTE [rsi + rcx], 10 ; append newline to vendor string
mov rdi, STDOUT
mov rdx, rcx
add rdx, 1 ; increment count for newline char
syscall

mov eax, r10d

add rsp, 1<<15
pop rbp
ret

-- Todd

[gaultier]

Gdb (version 13.2-1) does work for me out of the box including with line numbers:

(gdb) b x11.nasm:111
Breakpoint 1 at 0x401096: file x11.nasm, line 111.
(gdb) r
Starting program: /home/pg/my-code/nasm-work/x11.exe

Breakpoint 1, x11_send_handshake () at x11.nasm:111
111	  syscall
(gdb) n
113	  cmp rax, 12*8 ; Check that all bytes were written.
(gdb) p * (char*)$rsp@12
$1 = "l\000\v\000\000\000\000\000\000\000\000"
(gdb)

Alternatively, breaking on the function name (i.e.: label) should also work but be a bit more cumbersome.

If all fails, gdb can also add a breakpoint at a certain address so one could disassemble like this (assuming no Position Independent Code):

objdump --prefix-addresses -M intel -S x11.exe 

and note at which addresses the interesting code locations are e.g. 0x401098. Then in gdb:

break *0x401098
r
info registers 

Perhaps make sure you compile with nasm -g to generate the debug information, and are not stripping this information at the linking stage with ld -s ?

[gaultier]

Fixed in fdead46

[mrtodd]

Just fyi, I tried it on an Arch Linux based distro and gdb was working.  Looks like Ubuntu is doing something odd. -- Todd On Monday, June 26, 2023 at 06:17:40 PM GMT+8, Philippe Gaultier ***@***.***> wrote: Gdb does work for me out of the box including with line numbers: (gdb) b x11.nasm:111 Breakpoint 1 at 0x401096: file x11.nasm, line 111. (gdb) r Starting program: /home/pg/my-code/nasm-work/x11.exe Breakpoint 1, x11_send_handshake () at x11.nasm:111 111 syscall (gdb) n 113 cmp rax, 12*8 ; Check that all bytes were written. (gdb) p ***@***.*** Attempt to dereference a generic pointer. (gdb) p * ***@***.*** $1 = "l\000\v\000\000\000\000\000\000\000\000" (gdb) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>