Как корректно вывести функцию в байтовом виде?

Question

[blecked88]

Хочу реализовать нечто такое:

#include <stdio.h>
#include <stdint.h>

typedef unsigned char uchar;

int f(int a, int b) {
    return a + b;
}
void _end(void) {};


int main(void) {
    uchar* start = f, *end = _end;
    int size = (int)(end - start);
    printf("size = %i\n", size);
    for (int i = 0; i < size; ++i) {
        printf("%02X ", *(start + i));
    }

    return 0;
}

однако данная программа либо вообще ничего не выдает (size < 0), либо выдает какие то неотносящиеся к данной функции байты.

реализовать надо так, чтобы работало на ЛЮБОМ компиляторе. Как это можно сделать?

Comments

[GavriKos]

Так а может функция просто вырезается оптимизхатором?

[Сергей Горностаев]

GavriKos, практически стопроцентно вырезается, так как нет ни одного её вызова.

[GavriKos]

Сергей Горностаев, ну есть надежда что компилировали с отключением оптимизатора )

[Василий Дёмин]

Я не уверен, что можно сделать платформо и компиляторонезависимое решение. Я для своих нужд использовал таблицу символов в ELF файлах (в PE принцип тот же), которую генерирует GCC. Алгоритм был следующий:

1. Добавляем в скрипт компоновщика символ для хэш-таблицы с именами и размерами функцмй пока что с размером равным нулю, в коде программы обращаемся к этой таблице, как-будто бы она уже заполнена (делаем поиск по имени функции, получаем по нему размер и далее делаем с размером то, что нам нужно).
   
2. Компилируем программу.
   
3. Пишем другую программу, которая будет смотреть полученный на предыдущем шаге ELF файл, доставать из таблицы символов функции и их размеры, заполнять хэш таблицу и записывать её в отдельный файл.
   
4. Пишем новый скрипт компоновщика, в котором вместо символа с нулевым размером, создаём символ с тем же именем с размером и содержимым файла, полученным на предыдущем шаге
   
5. Компилируем программу снова с использованием скрипта компоновщика, созданного на предыдущем шаге
   

Answer 1

[Rsa97]

Переписать всё на ассемблер.
Компилятор C/C++ может использовать оптимизацию, менять порядок функций, делать функции инлайновыми.

Comments

[blecked88]

я знаю про инлайновость, но дело в том что так

#include <stdio.h>
#include <stdint.h>

typedef unsigned char uchar;

#pragma auto_inline(off)
int f(int a, int b) {
    return a + b;
}
void _end(void) {};
#pragma auto_inline(on)

int main(void) {
    uchar* start = f, * end = _end;
    int size = (int)(end - start);
    printf("size = %i\n", size);
    for (int i = 0; i < size; ++i) {
        printf("%02X ", *(start + i));
    }

    return 0;
}

тоже не работает

[Wataru]

blecked88, Компилятор может вырезать неиспользуемые функции, он может их переставлять местами.

Answer 2

[Сергей Соловьев]

Я назвал 2 функцию не _end, а g и сработало. Возможно, gcc как-то по особенному интерпретирует это название - при дизассемблировании функции _end, даже не было.

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

Answer 3

[15432]

Ну почему же ничего не выдает, size < 0 означает, что функция _end расположена перед функцией f, и это нормально, потому что часто компилятор соблюдает алфавитный порядок.
Назовите их func_a и func_b и попробуйте ещё раз. Обязательно используйте в коде эти функции, чтобы они не оказались вырезанными

Answer 4

[res2001]

Что мешает предусмотреть варианты когда f < _end и f > _end?
https://godbolt.org/z/8M33E4PYo
Но это не гарантирует, что компилятор чего-нибудь не вставит между функциями. О чем и говорит итоговый выхлоп.
И еще выхлоп может быть разным при разных флагах оптимизации: -O0/1/2

Answer 5

[mayton2019]

Это так не работает. Тут есть квантовый эффект что если ты подглядываешь за кодом
то он ведет себя так. А если уберешь эту формулу расчета длины то код будет собран
совсем другой.

int f(int a, int b) {
    return a + b;
}
void _end(void) {};

Может быть будет инлайнинг функции f. Поэтому расчет длины кода тебе практически
не несет никакой информации. Тоесть никаких выводов из его длины сделать нельзя.

И трюки которые работали в ассемблере могут не работать для языков где есть агрессивная
оптимизация.