Как использовать varargs с __stdcall без компилятора, разрушающего стек

Question

Как использовать varargs с __stdcall без компилятора, разрушающего стек

0

Я столкнулся с проблемой с MSVC и ICC:

Мне нужно использовать аргументы varadic с условным вызовом stdcall, но компилятор игнорирует его для функций varadic и повреждает стек.

Легкий способ исправить это состоит в том, чтобы просто принять количество аргументов как один из аргументов и компенсировать ESP до того, как он будет поврежден, но в этом случае мне не нужно количество аргументов для контекста функции, поэтому скорее избегайте его если возможно.

Кто-нибудь знает, есть ли способ сделать это?

Nowayz 08 янв. 2015, в 05:49

Источник

2

По умолчанию вы не можете. При использовании stdcall вызываемый абонент отвечает за очистку стека. Поскольку вызываемый не знает ни количества аргументов, ни количества стекового пространства, занимаемого аргументами, он не может логически очистить стек без предоставления дополнительной информации. То, что вы пытаетесь сделать, не является хорошей идеей, и любая попытка заставить его работать, скорее всего, потребует гораздо больших усилий, чем оно того стоит. Это звучит как проблема XY, и вы должны действительно переосмыслить то, что вы пытаетесь достичь.
Captain Obvlious 08 янв. 2015, в 04:00
0

@CaptainObvlious Это не традиционная функция. И действительно, самое хорошее решение - сделать то, что я прошу (если это возможно). Но посмотри мой ответ на ответ Джона; это объясняет немного больше.
Nowayz 08 янв. 2015, в 04:08

Теги:

c++

c

visual-c++

icc

1 ответ

Ещё вопросы

По умолчанию вы не можете. При использовании stdcall вызываемый абонент отвечает за очистку стека. Поскольку вызываемый не знает ни количества аргументов, ни количества стекового пространства, занимаемого аргументами, он не может логически очистить стек без предоставления дополнительной информации. То, что вы пытаетесь сделать, не является хорошей идеей, и любая попытка заставить его работать, скорее всего, потребует гораздо больших усилий, чем оно того стоит. Это звучит как проблема XY, и вы должны действительно переосмыслить то, что вы пытаетесь достичь.
@CaptainObvlious Это не традиционная функция. И действительно, самое хорошее решение - сделать то, что я прошу (если это возможно). Но посмотри мой ответ на ответ Джона; это объясняет немного больше.

John Zwinck · Answer 1 · 2015-01-08T01-32-00.000Z

1

Согласно документации:

Вызов очищает стек, поэтому компилятор выполняет функции __cdecl.

Учитывая это, я не уверен, как вы ожидаете продолжения. Если stdcall требует, чтобы вызывающая сторона очищала стек, но в vararg-функциях вызываемый пользователь не мог узнать, что в стеке во время компиляции, как бы он работал? Вы ожидаете, что макросы stdarg va_list будут манипулировать кадром вызова? Я не думаю, что Microsoft видит это, поэтому то, что вы просите, не представляется возможным, по крайней мере, не путем написания C с использованием компилятора Microsoft.

John Zwinck 08 янв. 2015, в 01:32

0

В 99% случаев было бы смешно пытаться, и я согласен. К сожалению, в моей функции он очищает стек должным образом, но я не могу не очистить стек, потому что это делает не мой код.
Nowayz 08 янв. 2015, в 04:06
2

@Nowayz Не стесняйся, это смешно в 100% случаев.
Captain Obvlious 08 янв. 2015, в 04:09
0

@CaptainObvlious Не в этот раз :) Функция является прокси-сервером, вызывающим WINAPI (stdcall), который самостоятельно очищает стек, а затем выполняет jmp обратно к кешированному указателю retn, так как его пришлось перетасовать с вершины стека. Это означает, что стек имеет 100% гарантию правильной очистки каждый раз, но компилятор все еще пытается это сделать.
Nowayz 08 янв. 2015, в 04:10
0

@Nowayz: я не знаю, почему вы пытаетесь бороться с этим. Вы знаете, что такое соглашения о вызовах и что для них требуется. Эта магическая функция, о которой вы говорите, не следует никаким соглашениям и создает свои собственные, она не является стандартным вызовом ... Если вы хотите работать с этой функцией, вы должны следовать тому соглашению, которое она использует, даже если это означает необходимость писать свой собственный пролог / эпилог.
Jeff Mercado 08 янв. 2015, в 04:13
0

@JeffMercado Вот почему я задаю этот вопрос - хотя хорошие наблюдения. (В этом случае мне, вероятно, придется написать свой собственный эпилог, я просто хотел этого избежать )
Nowayz 08 янв. 2015, в 04:15
0

@Nowayz: как вы на самом деле вызываете функцию на практике? Вы всегда называете это одним определенным количеством параметров определенных типов? А с какого языка вы на самом деле звоните: C или C ++? И на что ориентирован ISA? x86? amd64?
John Zwinck 08 янв. 2015, в 04:19
1

@Nowayz: Win32 API использует __stdcall для всего, кроме wsprintf() который требует __cdecl . Ваш прокси также должен использовать __stdcall . Похоже, вы пытаетесь заставить прокси __cdecl действовать так, как если бы это был __stdcall , и это просто не сработает. Я согласен с CaptainOblivious, это проблема XY. Вы гонитесь за неправильным решением. Опубликуйте код, с которым у вас возникли проблемы, и, возможно, кто-то подскажет, как его исправить.
Remy Lebeau 08 янв. 2015, в 04:48
0

@RemyLebeau Это не проблема XY, и даже если бы это было так, вам следует сосредоточиться на вопросе ради него, а не обойти его, потому что вы предполагаете некомпетентность. Я решил это сам, просто взяв argc и сместив регистр esp, как я предложил в моем первоначальном вопросе
Nowayz 09 янв. 2015, в 11:41
0

@Nowayz: значит, ты не на amd64 / x86_64? Поскольку AFAIK, MSVC не поддерживает встроенную сборку там. Вот почему я вчера спросил, какой ISA вы используете.
John Zwinck 09 янв. 2015, в 14:23
0

@JohnZwinck Я использую компилятор intel для встроенной сборки при компиляции в архитектуру AMD64, но в этом случае я писал код для IA-32. (Хотя у меня были планы написать реализацию для обоих)
Nowayz 13 янв. 2015, в 02:48

Показать ещё 8 комментариев