- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
uint64_t ObjectLoadListener::getRelocationAddend(uint64_t LLVMRelocationType,
uint8_t *FixupAddress) {
uint64_t Addend = 0;
switch (LLVMRelocationType) {
case IMAGE_REL_AMD64_ABSOLUTE:
Addend = *(uint32_t *)FixupAddress;
break;
case IMAGE_REL_AMD64_ADDR64:
Addend = *(uint64_t *)FixupAddress;
break;
case IMAGE_REL_AMD64_REL32:
Addend = *(uint32_t *)FixupAddress;
break;
default:
llvm_unreachable("Unknown reloc type.");
}
return Addend;
}
Follow us!
нет, там сверху в углу написанно
2. Upcasting Pointers
- Релиз? Пацаны, я всю жизнь на дебаге собираю, УМСР.
- А Почему юнит тесты падают?
- Пацаны, это не я, я такого вообще не пишу
У вас говно вместо конпелятора, а входные данные вообще какая-то питушня писала. Возьмите gcc последний, линукс 64 бит, и данные на входе чоткие должны быть, а не питушня.
> /c-undefined-behaviors/
Ну ладно, я тебя понял.
getRelocationAddend вызывается тут: https://github.com/dotnet/llilc/blob/97cf48ea9a3cdf4a2582a95683a74b572f4cfe45/lib/Jit/LLILCJit.cpp#L761
FixupAddress получается так:
Если дальше ковырять это говно, можно найти
и
надо еще вот этот класс проанализировать
Что-то мне лень анализировть все это говно, но достаточно очевидно, что этот Offset показывает смешения в байтах в MSIL (он же CIL) байткоде, этот байткод не имеет фиксированного размера инструкций, так что там вполне может быть какая-то параша с выравниванием, не кратным 4 или 8 байтам
Вот это кстати очень круто, икнлудить какое-то говно в тело функции
Я и в инициализатор массива инклудил, брат жив.
"Ну не могут же uint8_t и uint64_t лежать в одном и том же месте!" - подумал конпелятор и выкинул код нахуй.
Что за хуйня? Мне показалось, или оно вывело байты в обратном порядке? Ты про это?
З.Ы. Бля, ща попробую воспроизведение замутить. Что-то все примеры из инета перестали UB триггерить.
На пока почитай: http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html
Логичнее было бы назвать бедолагу "byte*", но боюсь что это слово тогда не было де-факто
п.с. в pcap указатель на контекст передается через u_char. Тлен и безысходность
Но я подозреваю, что речь не об этом.
Всегда думал что старшее слово имеет меньший адрес.
Есть ещё процессоры со смешанным порядком (PDP-11, в котором старшее двухбайтовое слово имеет меньший адрес, но внутри каждого двухбайтового слова старший октет имеет больший адрес). А на ARM можно вообще переключать порядок октетов на ходу.
- это всё нерабочее?
Я это и хотел соснуть
Сдвигами же.
З.Ы. А, ты не про uint32, а про int32 - никак, переполнение, все дела... Разве что кучу ифов нахерачить, чтобы переполнения не задевать.
Где здесь используется представление чисел?
(0b111 >> 1) == 0b11
и мне похуй где располагается старшее слово, а где младшее
Тем, что переполнение в знаковый разряд - UB.
А общее у них только представление положительных чисел до 0 .. 2^(n-1) - 1. Отрицательные - implementation defined.
Допустим есть
1010111010 - некий 10битный чисел с первой половиной 10101 и второй 11010
нужно получить
1101010101
Причем тут переполнение? Причем тут знаковый разряд?
Свободу процессорам и компиляторам!
Например можно реализовать проверку на переполнение, как в шарпике, и убивать прогу нахуй... Или сделать saturated числа. Стандарт не запрещает.
Эмбедщина.
Что такое Эмбедщина?
Программирование для встраиваемых устройств (аля микроконтроллеры).
Где-то здесь был пример адовых оптимизаций циклов, которые прокатывали только с int, но не с size_t.
хуй его знает как хранятся байты (а может даже биты) в uint32?
Может змейкой или в шахматном порядке?
Может всё-таки это UB и какой-нибудь конпелятор NASA для космической ракеты имеет право этот код выпилить?
Я может ошибаюсь, но по-моему нифига не UB, обычное implementation defined. А так как эмбедщина под конкретный процессор пишется, то вполне допустимо.
http://en.cppreference.com/w/cpp/language/implicit_conversion
> If the destination type is signed, the value does not change if the source integer can be represented in the destination type. Otherwise the result is implementation-defined. (Note that this is different from signed integer arithmetic overflow, which is undefined).
Ты не знал про байт ордер?
А чего ты еще не знал?
Но signed/unsigned char* не альясятся со всем.
З.Ы. Или ты как раз об этом?
http://en.cppreference.com/w/cpp/language/reinterpret_cast
> AliasedType is char or unsigned char: this permits examination of the object representation of any object as an array of unsigned char.
не пашет
В чар что-ли конвертить?
я тут вопросы задаю
К сожалению, в сишке уже стало нормой складывать буквы с цифрами, поэтому теперь разделить не получится.
Фактически, поверх вектора сделан свой аллокатор с индексами вместо сырых указателей. Несложно догадаться, что с таким аллокатором можно написать любые виды багов: и мертвые "ссылки", и порча "кучи", и вообще любая хуйня. Еще оверхед на проверку индекса при доступе к элементам вектора. Зато безопасно, че.
Ну да, если пилить односвязные списки на каждый чих, как в сишечке, то всё будет обмазано unsafe'ами... Но ведь даже в крестах так не делают, а пилят контейнер и юзают его :)
Профит подхода с unsafe в том, что опасные куски легко загрепать, перечитать и обмазать на 146% тестами. А остальной код чё-попало с памятью творить не сможет.
В расте статические проверки тоже слишком строгие, чтобы верифицировать интересные программы.
им бы не помешало стандарт почитать. Делать такую фигню совершенно необязательно.
мы не читаем стандарт, мы его пишем