← All posts tagged x86_64

Об исключенных командах или за что «списали» инструкцию INTO?
Любопытно было почитать материал от разработчика компилятора, способного выжимать из процессора максимум. Ещё @Tajunu писал про ущербность LLVM по сравнению с TenDRA, но так, достаточно поверхностно, а тут — от того, кто реально в теме.

Ну и интересно было узнать, что это не чисто случайно под Аду подходит, а под PL/1 делалось, а Ада попутно получилась, как тоже нормальный язык программирования.

SEH_Init

On x86_64 windows exception mechanism is no more based on a chained list of handlers addresses on the stack. Instead unwinding information is used to retrieve the exception handler (similar to ZCX GCC mechanism). So in order to register an exception handler we need to put in the final executable some unwinding information. This information might be present statically in the image file inside the .pdata section or registered through RtlAddFunctionTable API. Currently the GCC toolchain does not generate the .pdata information for each function. As we don't need to handle SEH exceptions except for signal handling we are registering a "fake" unwinding data that associate a SEH exception handler to the complete .text section. As we never return from the handler, the system does not try to do the final unwinding using the pdata information. The unwinding is handled by the runtime using either the GNAT SJLJ mechanism or the ZCX GCC mechanism. The current implementation is using the RtlAddFunctionTable.

Here is for information purposes the equivalent using a static .pdata section: …

Теперь понятно, что имеет в виду @vt под «знает, как компилировать под Windows». Если считать Microsoft законодателем мод, то что-то в этом есть, хотя как по мне, — скорее вкусовщина. По-любому, без брандмауэров исключений никакой работы с COM не делается, так что какая разница, что внутри.

/etc/init.d/qemu-binfmt по непонятной причине регает какие угодно архитектуры, но только не x86_64. Чтобы добавить поддержку x86_64, нужно просто продолжить по аналогии ряд

echo ':alpha:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x26\x90:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-static-alpha-binfmt:' > /proc/sys/fs/binfmt_misc/register
echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/qemu-static-arm-binfmt:' > /proc/sys/fs/binfmt_misc/register
echo ':sparc:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x02:\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-static-sparc-binfmt:' > /proc/sys/fs/binfmt_misc/register

Оказывается, инженеры AMD64 подложили большую свинью быстрым песочницам и эмуляторам в юзерспейсе, запретив сегментацию даже в x86 программах. В нормальной x86 OS можно запрограммировать LDT как больше нравится, загрузить селекторы в сегментные регистры и, таким образом, получить эмулируемое окружение, например, Xbox или Linux, и даже долбаный fork(), от которого всё никак не откажутся в пользу pthread_create() и posix_spawn(), вполне реализуем без глюков (как в Cygwin), так как внутри эмулируемого окружения расположение нулевого смещения можно выбрать так, чтобы невыгружаемые страницы не занимали место, на котором в форкаемом процессе было что–то другое. В эмуляторе Xbox LDT используется, так как форматы fs:[...] на Windows и Xbox отличаются. А ещё есть программы, которые для противодействия отладке работают на изменённых селекторах. И всё это шмяк — и не работает. В принципе нельзя сделать, чтоб работало как раньше. Только fs и gs можно программировать.

Единственное решение в юзерспейсе — патчить код на лету, как это делает vx86. А ещё вчера узнал, что для 64битной Windows нет coLinux.