История изменений

Кстати - тоже слегка удивительно мне: тот tcc, который сейчас утягивается из Git авторов очень сильно отличается от release с тем же номером.

Вот только что глянул – dev-lang/tcc-0.9.27_p20211022. Я ставил просто как emerge dev-lang/tcc и даже не парился по данному поводу. Видимо, у них идёт разработка и они не стали городить отдельную ветку почему-то.

The interpreter specified in the shebang line is executed by the kernel itself inside the execve call.

Ненене… Человек говорит почти правильно. Это справедливо для случая, если у Вас, как я Вам сразу и говорил, настроен и используется binfmt_misc. Там ниже, в том же комменте он прямо предлагает посмотреть функцию load_script:

Have a look at the load_script kernel function for more details.

load_script это функция, вот она например, это для загрузки/исполнения скрипта в kernel space -> https://elixir.bootlin.com/linux/latest/source/fs/binfmt_script.c

В «стандартном исполнении», execve() просто заменяет код вызывающего процесса на код вызываемого процесса. Даже файловые дескрипторы может не прихлопывать при замене кода. С ядром это связано, но весьма опосредовано (ну сисколлы-то в ядре должны же исполняться, не Духом же Святым оно там реализуется!), не напрямую как при использовании binfmt_misc.

Собственно, я про необходимость настройки binfmt_misc сразу поэтому и сказал. Можно «по правильному», с полной поддержкой ядра, в kernel space (хотя, если честно, это отчасти чревато), а можно просто как простой процесс, в юзерспейсе. В нашем случае это именно что userspace и ни каких делов.

Тут можно использовать отладочные подходы, типа ptrace. Но тут мне уже реально лень залезать так глубоко, да и для себя лично смысла не вижу.

А хотелось видеть внутренности, как:

Если бы мне хотелось видеть внутренности, то я бы либо извне их получал (через ptrace), либо изнутри анализом аргументов, указанных для данного скрипта (ну там getenv() каким-нибудь, например, примерно так же, как Вы сейчас получаете переменные окружения, которые внешние для Вашего скрипта), либо настроил себе binfmt_misc и смотрел бы что там происходит, либо читал бы строку запуска из вызывающего скрипта и смотрел как будет запущен следующий скрипт или читал бы те же переменные окружения из /proc/PID/environ на лету. Ну так, чисто навскидку что на ум приходит. Чудес-то не бывает, это же просто процесс.

Кстати - тоже слегка удивительно мне: тот tcc, который сейчас утягивается из Git авторов очень сильно отличается от release с тем же номером.

Вот только что глянул – dev-lang/tcc-0.9.27_p20211022. Я ставил просто как emerge dev-lang/tcc и даже не парился по данному поводу. Видимо, у них идёт разработка и они не стали городить отдельную ветку почему-то.

The interpreter specified in the shebang line is executed by the kernel itself inside the execve call.

Ненене… Человек говорит почти правильно. Это справедливо для случая, если у Вас, как я Вам сразу и говорил, настроен и используется binfmt_misc. Там ниже, в том же комменте он прямо предлагает посмотреть функцию load_script:

Have a look at the load_script kernel function for more details.

load_script это функция, вот она например, это для загрузки/исполнения скрипта в kernel space -> https://elixir.bootlin.com/linux/latest/source/fs/binfmt_script.c

В «стандартном исполнении», execve() просто заменяет код вызывающего процесса на код вызываемого процесса. Даже файловые дескрипторы может не прихлопывать при замене кода. С ядром это связано, но весьма опосредовано (ну сисколлы-то в ядре должны же исполняться, не Духом же Святым оно там реализуется!), не напрямую как при использовании binfmt_misc.

Собственно, я про необходимость настройки binfmt_misc сразу поэтому и сказал. Можно «по правильному», с полной поддержкой ядра, в kernel space (хотя, если честно, это отчасти чревато), а можно просто как простой процесс, в юзерспейсе. В нашем случае это именно что userspace и ни каких делов.

Тут можно использовать отладочные подходы, типа ptrace. Но тут мне уже реально лень залезать так глубоко, да и для себя лично смысла не вижу.

А хотелось видеть внутренности, как:

Если бы мне хотелось видеть внутренности, то я бы либо извне их получал (через ptrace), либо изнутри анализом аргументов, указанных для данного скрипта (ну там getenv() каким-нибудь, например, примерно так же, как Вы сейчас получаете переменные окружения, которые внешние для Вашего скрипта), либо настроил себе binfmt_misc и смотрел бы что там происходит, либо читал бы строку запуска из вызывающего скрипта и смотрел как будет запущен следующий скрипт или читал бы те же переменные окружения из `/proc/PID/environ на лету. Ну так, чисто навскидку что на ум приходит. Чудес-то не бывает, это же просто процесс.