diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-17 09:10:43 +0200 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-17 09:10:43 +0200 |
| commit | f2ec263023649e596c5076df32c2d328bc9393d2 (patch) | |
| tree | 5dd86caab46e552bd2e62bf9c4fb1a7504a44db4 /results/scraper/fex/1208 | |
| parent | 63d2e9d409831aa8582787234cae4741847504b7 (diff) | |
| download | qemu-analysis-main.tar.gz qemu-analysis-main.zip | |
Diffstat (limited to 'results/scraper/fex/1208')
| -rw-r--r-- | results/scraper/fex/1208 | 23 |
1 files changed, 23 insertions, 0 deletions
diff --git a/results/scraper/fex/1208 b/results/scraper/fex/1208 new file mode 100644 index 000000000..4581f153e --- /dev/null +++ b/results/scraper/fex/1208 @@ -0,0 +1,23 @@ +Reasons to fork glibc +We really don't want to do this, but there are some reasons to go about doing this and we need to track the pain points. +This list will grow as we care about more things + +- clone support + - There are a lot of clone flags that can't be accurately wrapped while using glibc + - One of the big issues is that a guest application can be using clone directly, with flags that if we allow it breaks FEX's TLS usage. + - This is because glibc doesn't provide us a way to do clone flags plus keeping our TLS setup working + - We would need to fork glibc to expose a subset of flags AND keep our TLS working. +- 32-bit thunks + - In order to keep 32-bit VA usage down, we will need to wrap the mmap and munmap usage inside of glibc's dynamic loader + - The 32-bit side of the thunk stays in the 32-bit VA space. + - A significant amount of the 64-bit side could live in 64-bit VA space + - Exported symbols would need to still live in the 32-bit VA, which means the full host library also needs to live in the 32-bit VA, or we need to duplicate the symbol inside of the 32-bit space + +- Guest thunk hooks + - Add support for hooking when symbols are loaded so we can partially thunk a library + - A bit gross but would work for partial thunking? + +- Guest thunk callback support + - If the thunk creates a thread and is expected to call in to the guest as a callback. Then TLS state doesn't exist + - We could have a TLS region allocated for a guest thread post-thread creation if this was the case + - Bit of a faff \ No newline at end of file |