Closed Coekjan closed 1 month ago
In addition, I see line 178: for (int i=9; i<15 && idx==-1; ++i)
. I don't understand why the for-loop starts from 9 (I am not familiar with x64 architecture), could you please give me some hints or information about it?
I don't remember those stuff. I did that some time ago and didn't touched it. I just remember it's very sensitive. I have to go back in the code to understand/remember what desciptor 8 is...
To reproduce the issue, download the newest version (1.36.1-2) of busybox from archlinux archive ( https://archive.archlinux.org/packages/b/busybox/ ), and run it with box64:
$ box64 busybox ls
So, "8" is the selector used by libc for it's tls stuffs. That's why it's handled as a spacial case, to be abble to wrap libc correctly.
I suppose on you side, the program you are using is statically linked, wich is still not really supported with box64. While I can do a special case to check if libc is currently used and if not, allow the selector 8, there are still some other stuffs, like "threads", that will probably badly behave because box64 use libphtread internaly, and that will conflict with staticaly linked pthread on your program I think.
@ptitSeb if statically-linked programs are not planned to support yet, I will close this PR (even if we plan to support those programs, this PR is not doing the right thing)
I found that
mov %fs:0x0, %rax
in my application got wrong FS BASE. After investigation, I found thatmy_context->segtls[idx].key
(whereidx = 8
in my case corresponding to FS BASE) is not correctly initialized. I modified the if-statement condition and my app is working well now.I am not very sure if my patch is correct. If I am wrong, please correct me.