Есть ли какой-либо способ узнать смещение определенной
метки внутри функции извне функции?

Т.е. есть ли какой-либо способ реализовать такой код

func()
{
...
_LABEL:
}

main()
{
UINT offset = _LABEL — func;
}

Любые идеи welcome!

Здравствуйте, tacit_one, Вы писали:


_>Есть ли какой-либо способ узнать смещение определенной
_>метки внутри функции извне функции?

А на кой такой изврат? Может, чего-нибудь менее радикльное придумать можно будет.

Здравствуйте, Нахлобуч, Вы писали:

Н>Здравствуйте, tacit_one, Вы писали:


_>>Есть ли какой-либо способ узнать смещение определенной
_>>метки внутри функции извне функции?

Н>А на кой такой изврат? Может, чего-нибудь менее радикльное придумать можно будет.

другие варианты гораздо более извратные.
нет времени объяснять, но нужно решение этой задачи,

либо придётся в исходном файле плодить 2^10 naked функций.

Здравствуйте, tacit_one, Вы писали:


_>Есть ли какой-либо способ узнать смещение определенной
_>метки внутри функции извне функции?

_>Т.е. есть ли какой-либо способ реализовать такой код

_>func()
_>{
_> ...
_> _LABEL:
_>}

_>main()
_>{
_> UINT offset = _LABEL — func;
_>}

_>Любые идеи welcome!

После применения оптимизируещего компилятора нельзя будет утверждать что туда куда надо попадешь

Здравствуйте, wwall, Вы писали:

W>После применения оптимизируещего компилятора нельзя будет утверждать что туда куда надо попадешь


ok.
забыл уточнить, что

func()
{
  _asm
  {
   ...
   _LABEL:
  }
}

main()
{
  UINT offset = _LABEL — func;
}

ИМХО должно быть другое решение. Без подобных нестадартных подходов.

Здравствуйте, wwall, Вы писали:

W>ИМХО должно быть другое решение. Без подобных нестадартных подходов.

Это вполне стандартный подход:
заполнение таблицы переходов на этапе инициализации.
Данная задача легко реализуется на любом ассемблере, проблема
в том, что нужно интегрироваться с приложением на C.

Данный участок кода вызывается порядка 1 миллиона раз в секунду.
Любой лишний код здесь не приветствуется.

Здравствуйте, tacit_one, Вы писали:

_>Здравствуйте, Нахлобуч, Вы писали:

Н>>Здравствуйте, tacit_one, Вы писали:


_>>>Есть ли какой-либо способ узнать смещение определенной
_>>>метки внутри функции извне функции?

Н>>А на кой такой изврат? Может, чего-нибудь менее радикльное придумать можно будет.

_>другие варианты гораздо более извратные.
_>нет времени объяснять, но нужно решение этой задачи,

_>либо придётся в исходном файле плодить 2^10 naked функций.

не очень понял про

2^10 naked функций

Достаточно одной, причем если напрячься то можно свести затраты к минимуму push/pop IP, а это, ИМХО, уже как раз и есть нормально, я сам сталкивался с необходимостью балансирования на грани выделения отдельных подпрограмм ( функциями уже трудно назвать naked со своим эпилогом ), и затратами на вызов функции.

Самое главное не портить регистры в naked, тогда все будет

tacit_one wrote:

>
> Есть ли какой-либо способ узнать смещение определенной
> метки внутри функции извне функции?

Для gcc (непереносимо): http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Labels-as-Values.html#Labels-as-Values

--
Maxim Yegorushkin

Those who do not understand Unix are condemned to reinvent it, poorly. © Henry Spencer

Здравствуйте, srggal, Вы писали:


S>Достаточно одной, причем если напрячься то можно свести затраты к минимуму push/pop IP, а это, ИМХО, уже как раз и есть нормально, я сам сталкивался с необходимостью балансирования на грани выделения отдельных подпрограмм ( функциями уже трудно назвать naked со своим эпилогом ), и затратами на вызов функции.

S>Самое главное не портить регистры в naked, тогда все будет

одну... ну, теперь представь вот такой код

func()
{
  _asm
  {
   ...
   _LABEL0x00:
     _LABEL0x01:
     ...
     _LABEL0xff:
     ...
  }
}

main()
{
  UINT offset = _LABEL — func;
}

а ещё представь, что функция func загружается не загрузчиком, а вручную,
и предсавь, во что превратится код, если в C файле будет 0xFF _naked функций...

Здравствуйте, MaximE, Вы писали:

ME>Для gcc (непереносимо): http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Labels-as-Values.html#Labels-as-Values

Да, спасибо огромное, я знаю про GCC.

Но у меня, к сожалению, VC.6

tacit_one wrote:

> Н>А на кой такой изврат? Может, чего-нибудь менее радикльное придумать можно будет.
>
> другие варианты гораздо более извратные.
> нет времени объяснять, но нужно решение этой задачи,
>
> либо придётся в исходном файле плодить 2^10 naked функций.

Определи структуру с членами, которые у тебя были бы локальными переменными в твоей ф-ции и массив указателей на ф-ции, которые у тебя были бы метками:

struct local_vars
{
     int some;
     int other;
};

void do_0(local_vars*);
void do_1(local_vars*);
// ...

void(*do_n[])(local_vars*) = {
       do_0
     , do_1
     // ...
};

void do_some(int n)
{
     local_vars vars;
     do_n[n](&vars);
}

--
Maxim Yegorushkin

Those who do not understand Unix are condemned to reinvent it, poorly. © Henry Spencer

Здравствуйте, MaximE, Вы писали:

Для этого нужно точно знать структуру функции, и при её изменении придётся "подстраивать" структуру.
В принципе, это эквивалентно "зашиванию" смещений константами, но это не есть красивое решение...

Очень хочется здачу вычисления offset'ов возложить на компилятор.

ME>Those who do not understand Unix are condemned to reinvent it, poorly. © Henry Spencer[/i]

Здравствуйте, tacit_one, Вы писали:

_>Здравствуйте, srggal, Вы писали:


S>>Достаточно одной, причем если напрячься то можно свести затраты к минимуму push/pop IP, а это, ИМХО, уже как раз и есть нормально, я сам сталкивался с необходимостью балансирования на грани выделения отдельных подпрограмм ( функциями уже трудно назвать naked со своим эпилогом ), и затратами на вызов функции.

S>>Самое главное не портить регистры в naked, тогда все будет

_>одну... ну, теперь представь вот такой код

_>

_>func()
_>{
_>  _asm
_>  {
_>   ...
_>   _LABEL0x00:
_>     _LABEL0x01:
_>     ...
_>     _LABEL0xff:
_>     ...
_>  }
_>}

_>main()
_>{
_>  UINT offset = _LABEL — func;
_>}
_>

_>а ещё представь, что функция func загружается не загрузчиком, а вручную,
_>и предсавь, во что превратится код, если в C файле будет 0xFF _naked функций...

Опять же, ИМХО, может вы замудрили и ВСЁ можно сделать проще ? Чессно гря, как-то надуманно

Здравствуйте, srggal, Вы писали:

S>Опять же, ИМХО, может вы замудрили и ВСЁ можно сделать проще ? Чессно гря, как-то надуманно

KIS — вещь правильная, но не всегда возможна

Здравствуйте, tacit_one, Вы писали:

_>Здравствуйте, srggal, Вы писали:

S>>Опять же, ИМХО, может вы замудрили и ВСЁ можно сделать проще ? Чессно гря, как-то надуманно

_>KIS — вещь правильная, но не всегда возможна

Не понял, что Вы имеете в виду под

KIS

Keep It Simple

tacit_one wrote:

> Здравствуйте, MaximE, Вы писали:
>
> Для этого нужно точно знать структуру функции, и при её изменении придётся "подстраивать" структуру.
> В принципе, это эквивалентно "зашиванию" смещений константами, но это не есть красивое решение...

А по-моемому — элегантное. Ты берешь стэковый фрейм и запихиваешь его в структуру. После этого ты можешь передавать этот фрейм в другие ф-ции. (Кстати, именно так работает лямбда в питоне — лямбда ф-ция держит ссылку на объект фрейма).

--
Maxim Yegorushkin

Those who do not understand Unix are condemned to reinvent it, poorly. © Henry Spencer

Здравствуйте, tacit_one, Вы писали:

_>Keep It Simple

Может имеет смысл в func инициализировать глобальную таблицу переходов ?

Здравствуйте, MaximE, Вы писали:

ME>А по-моемому — элегантное. Ты берешь стэковый фрейм и запихиваешь его в структуру. После этого ты можешь передавать этот фрейм в другие ф-ции. (Кстати, именно так работает лямбда в питоне — лямбда ф-ция держит ссылку на объект фрейма).

Согласен, элегантное, но не в этом случае. В этой функции стека вообще нет — сегментом SS пользоваться нельзя.
Я даже push eax не могу сделать...