A
ещё возможно при вырпвнивании кода, данных компиль может нулями заполнить промнжуток
скорее всего это
Size: a a a
2020 January 22
A
но скорей всего то что ты показываешь это не код а данные, имхо
ЕК
s
но скорей всего то что ты показываешь это не код а данные, имхо
Там с офсета 28 написано
__PAGEZERO. Это неспроста 😁ЕК
Memory allocated by this function is automatically initialized to zero.
ЕК
Пастбин не смотрел пока.
s
Пастбин не смотрел пока.
Там в пастебине бинарник для мака, дизассемблированный как raw.
ЕК
https://pastebin.com/SA1NrG9U
если бы я знал как спросить, я бы спросил.
у меня обычный “hello world” бинарь на ассемблере на диске.
как это связано со страничной памятью? не понимаю.
или это как-то связано с тем, что файлы в фс не хранятся размером меньше, чем 4кб?
если бы я знал как спросить, я бы спросил.
у меня обычный “hello world” бинарь на ассемблере на диске.
как это связано со страничной памятью? не понимаю.
или это как-то связано с тем, что файлы в фс не хранятся размером меньше, чем 4кб?
Лучше код всегда приводить, иначе не понять, что ты делаешь.
A
но скорей всего то что ты показываешь это не код а данные, имхо
меня смущает, что это лежит в бинаре
A
меня смущает, что это лежит в бинаре
и пока я пришел к выводу, что это относится к заголовку mach-o
ЕК
меня смущает, что это лежит в бинаре
Это может лежать в бинаре, потому что, например, так код написан.
ЕК
Оригинального исходника нет?
A
Оригинального исходника нет?
section .text
global _start
_start:
mov rax, 0x02000004
mov rdi, 1
mov rsi, message
mov rdx, 2
syscall
mov rax, 0x02000001
xor rdi, rdi
syscall
section .data
message: db "Hello, World", 10
A
в спеке mach-o
1. The static linker creates a __PAGEZERO segment as the first segment of an executable file. This segment is located at virtual memory location zero and has no protection rights assigned, the combination of which causes accesses to NULL, a common C programming error, to immediately crash. The __PAGEZERO segment is the size of one full VM page for the current CPU architecture (for x86 and PowerPC, this is 4096 bytes or 0x1000 in hexadecimal). Because there is no data in the __PAGEZERO segment, it occupies no space in the file (the file size in the segment command is zero).
Field Descriptions
2. vmsize
Indicates the number of bytes of virtual memory occupied by this segment. See also the description of filesize, below.
3. filesize
Indicates the number of bytes occupied by this segment on disk. For segments that require more memory at runtime than they do at build time, vmsize can be larger than filesize. For example, the __PAGEZERO segment generated by the linker for MH_EXECUTABLE files has a vmsize of 0x1000 but a filesize of zero. Because __PAGEZERO contains no data, there is no need for it to occupy any space until runtime. Also, the static linker often allocates uninitialized data at the end of the __DATA segment; in this case, the vmsize is larger than the filesize.
The loader guarantees that any memory of this sort is initialized with zeros.
если сделать: otool -lv app, там можно найти:
segname __PAGEZERO
vmaddr 0x0000000000000000
vmsize 0x0000000100000000
fileoff 0
filesize 0
Все логично, подходит по спеке.
Размер файла на диске 12кб (ок, 3 pagesize’а)
Сам размер файла 8300+ байт, если открывать средствами не какого-нибудь hexdump, а средствами с++ или саблаймом тем же.
это при чтении файла fs распознает формат и отдает лишние 0? Нелогичено для меня, почему тогда размер на диске учитывает эти 0
1. The static linker creates a __PAGEZERO segment as the first segment of an executable file. This segment is located at virtual memory location zero and has no protection rights assigned, the combination of which causes accesses to NULL, a common C programming error, to immediately crash. The __PAGEZERO segment is the size of one full VM page for the current CPU architecture (for x86 and PowerPC, this is 4096 bytes or 0x1000 in hexadecimal). Because there is no data in the __PAGEZERO segment, it occupies no space in the file (the file size in the segment command is zero).
Field Descriptions
2. vmsize
Indicates the number of bytes of virtual memory occupied by this segment. See also the description of filesize, below.
3. filesize
Indicates the number of bytes occupied by this segment on disk. For segments that require more memory at runtime than they do at build time, vmsize can be larger than filesize. For example, the __PAGEZERO segment generated by the linker for MH_EXECUTABLE files has a vmsize of 0x1000 but a filesize of zero. Because __PAGEZERO contains no data, there is no need for it to occupy any space until runtime. Also, the static linker often allocates uninitialized data at the end of the __DATA segment; in this case, the vmsize is larger than the filesize.
The loader guarantees that any memory of this sort is initialized with zeros.
если сделать: otool -lv app, там можно найти:
segname __PAGEZERO
vmaddr 0x0000000000000000
vmsize 0x0000000100000000
fileoff 0
filesize 0
Все логично, подходит по спеке.
Размер файла на диске 12кб (ок, 3 pagesize’а)
Сам размер файла 8300+ байт, если открывать средствами не какого-нибудь hexdump, а средствами с++ или саблаймом тем же.
это при чтении файла fs распознает формат и отдает лишние 0? Нелогичено для меня, почему тогда размер на диске учитывает эти 0
A
В любом случае спасибо; откуда это идёт разобрался.
А если кто допрет, почему на диске лежит этот пэйджзеро и поделится, тоже буду благодарен
А если кто допрет, почему на диске лежит этот пэйджзеро и поделится, тоже буду благодарен
A
а вот и сам код
A
Я с кодом разобрался. Всякие хексдампы и дизасмы выплевывают нормально
A
Кроме,кстати, дизасма nasm. Не знаю каким боком, но первый раз он выплюнул интерпретируя нули. Остальные разы норм
КП
Спасибо, пожаловался на спам.
A
#book
Это слайд-лист моего выступления GDC 2014 под названием "Оптимизация шейдеров низкого уровня для следующего поколения и DX11." Этот разговор продолжается в моей речи GDC 2013 "Low-Level Think in High-Level Shading Languages", демонстрирующей трюки оптимизации низкого уровня для оборудования DX11 уровня, и в частности архитектуры GCN.
http://www.humus.name/Articles/Persson_LowlevelShaderOptimization.pdf
Это слайд-лист моего выступления GDC 2014 под названием "Оптимизация шейдеров низкого уровня для следующего поколения и DX11." Этот разговор продолжается в моей речи GDC 2013 "Low-Level Think in High-Level Shading Languages", демонстрирующей трюки оптимизации низкого уровня для оборудования DX11 уровня, и в частности архитектуры GCN.
http://www.humus.name/Articles/Persson_LowlevelShaderOptimization.pdf