Имеет ли смысл пихать неизменяемые данные (строки, массивы данных) в секцию констант? Что это даёт кроме защиты от случайного изменения? Влияет ли это на скорость доступа к данным?

Думаю, это влияет лишь на размер exe-шника: больше секций - больше файл, учитывая выравнивание.

Loger
MASM32 вообще автоматом цепляет эту секцию в DATA, т.е. CONST как таковой не существует, но в других ассемблерах может и есть резон использовать отдельную секцию для констант.

Quantum

Не согласен, не цепляет ..
Если мергить секциии то .DATA и .CONST будут точно в разных местах, в других обстоятельствах не проверял.

Т. е. данные секции констант отличаются от остальных либо наличием флага PAGE_READONLY (в отличие от PAGE_READWRITE для данных секции изменяемых данных) у их страниц памяти, либо вообще ничем не отличаются?

Я только что проверил на VC++ 6 и Masm 7: они действительно не создают отдельной секции для константных данных

> Имеет ли смысл пихать неизменяемые данные
> (строки, массивы данных) в секцию констант?
имеет

> Что это даёт кроме защиты от случайного изменения?
экономию памяти (дисковой и виртуальной), т.к. винда никогда не сбрасывает страницы константой секции в своп, и при недостатке памяти просто их прибивает, т.к. в любой момент они могут быть взяты из самого файла. это существенно увеличивает производительность на low-end системах
естественно, без константной секции можно и обойтись - если не смешивать модифицируемые и немодифицируемые переменные, винда справится с ними и сама, но явное задание секции как неизменеяемой позволяет системе оптимизировать стратегию манагера виртуальной памяти. эта стратения у всех осей своя, она постоянно пересматривается и не факт, что вообще работает (тем более на произвольно взятой оси), но... пренебрегать ею все же не стоит.

> Влияет ли это на скорость доступа к данным?
при недостатке памяти и сильно фрагментированном файле подкачки размещение данных в константных секциях несколько увеличивают общую производительность системы.

> Думаю, это влияет лишь на размер exe-шника:
> больше секций - больше файл, учитывая выравнивание.
смотря как тасовать секции. можно их скомбинировать и так, что размер файла совсем не возрастет, к тому же минимально разумная кратность выравнивания (200h байт) по современным меркам не так уж и велика...

> MASM32 вообще автоматом цепляет эту секцию в DATA,
> т.е. CONST как таковой не существует,
MASM'а в природе не существует ;)
транслятор тупо и без излишней самодеятельности помещает все данные их CONST в секцию .rdata объективного файла, отнимая у нее атрибут записи - это в случае с coff. с omf секция CONST так и идет (загляните в obj).
линкер, если он конечно не писх, и если программист его специально не попросит никогда не дает констаным секциям атрибут записи и не комбинирует их с секцией DATA, а если это все-таки произошло, значит, ему передали не те ключи или что-то нахимичено в файле конфигруации.
имена секций в PE/COFF значения не имеют, поэтому могут быть любыми, секция с именем const действительно редкий гость, но от ее переименования она еще не перестает быть константной.

> Если мергить секциии то .DATA и .CONST будут точно в разных местах
если мергить - то они сольются в одну секцию, с атрибутом записи. если не мергить - не сольются

> Т. е. данные секции констант отличаются от остальных
> либо наличием флага PAGE_READONLY (в отличие от
PAGE_ совсем из другой оперы. это атрибут страницы виртуальной памяти, у секцйи свои атрибуты. атрибута READONLY не сущесвует в природе. есть атрибут доступа (он же - чтения), есть атрибут записи. атрибут исполнения x86 не поддерживается (точнее, не поддерживался до последнего времени, но новые P-4 уже поддерживают).
READONLY это - дефайн атрибута чтения. его не следует понимать буквально, т.к. он замечательно комбирируется с другими атрибутами и ONLY там вообще говоря не уместно.

> PAGE_READWRITE для данных секции изменяемых данных)
> у их страниц памяти, либо вообще ничем не отличаются?
если секции не были объеденены, то - отличаются

> Я только что проверил на VC++ 6 и Masm 7:
> они действительно не создают отдельной секции для константных данных

берем файл:

.386
.Model Flat

.data
xxx   db "data",0
.const
yyy    db "const",0

.Code
public _main;
_main:
       ret

End _main

деламем ему ml /c file.asm или ml /c /coff file.asm
смотрим на obj утилитой efd.exe или dumpbin.exe или еще чем...

Section Headers:
SECTION 1: ".text   "
	Physical address              : 00000000
	Virtual address               : 00000000
	Section size                  : 00000001 (1)
	Offset to raw data for section: 000000B4
	Offset to relocation          : 00000000
	Offset to line numbers        : 00000000
	Number of relocation entries  : 0
	Number of line number entries : 0
	Flags (60300020): align=4h TEXT EXECUTABLE READABLE
SECTION 2: ".data   "
	Physical address              : 00000001
	Virtual address               : 00000000
	Section size                  : 00000005 (5)
	Offset to raw data for section: 000000B5
	Offset to relocation          : 00000000
	Offset to line numbers        : 00000000
	Number of relocation entries  : 0
	Number of line number entries : 0
	Flags (C0300040): align=4h DATA READABLE WRITABLE
SECTION 3: ".rdata  "
	Physical address              : 00000006
	Virtual address               : 00000000
	Section size                  : 00000006 (6)
	Offset to raw data for section: 000000BA
	Offset to relocation          : 00000000
	Offset to line numbers        : 00000000
	Number of relocation entries  : 0
	Number of line number entries : 0
	Flags (40300040): align=4h DATA READABLE
SECTION 4: ".drectve"
	Physical address              : 0000000C
	Virtual address               : 00000000
	Section size                  : 0000000C (12)
	Offset to raw data for section: 000000C0
	Offset to relocation          : 00000000
	Offset to line numbers        : 00000000
	Number of relocation entries  : 0
	Number of line number entries : 0

видим секцию .rdata без атрибута записи, если сделаем ей dump, там окажется строка секции const
нормальные линкеры (в т.ч. и ms link) по умолчанию не объединяют секцию .rdata с .data

kaspersky
> если мергить - то они сольются в одну секцию, с атрибутом записи.

В одной конечно если мергить в одну, но строки определённые в .const и в .data будут в файле лежать в разных местах, т.е. будут разделены, кажется таблицей импорта.

> В одной конечно если мергить в одну, но строки
> определённые в .const и в .data будут в файле лежать
> в разных местах, т.е. будут разделены, кажется таблицей импорта.
??? это с какой такой радости? вот уже чего в obj точно нет - так это импорта. позже его цепляет сам линкер. это же каким извращенцем линкеру нужно быть, что бы раздвигать секции и пихать в них что-то свое! обычно линкеры внедряют импорт либо в начало, либо в конец, либо в середину файла, собранного из нескольких obj, но мне неизвестны случаи, когда бы они внедряли ее в середину obj.
при объединении секции они либо не объединяются совсем (многие линкеры запрещают объединять стандартные секции), либо физически сливаются вместе в непрерывный блок. если при объединении секций их атрибуты изменились, а физически они остались разнесенными, то это явный глюк линкера и место ему на свалке.
кстати говоря, таблица импорта вполне может быть в .data и частично даже в .rdata, выделять ей персональную секцию уже не модно, но ведь песня не о том ;)

Ну спутал, разделены они будут кодом ;-)
Вот для примера..

[цензура]

> Ну спутал, разделены они будут кодом ;-)
порядок размещения секций не зависит от их объявления, но нормальный транслятор и линкер стремятся располагать их в таком порядке: код, данные только на чтение, иниц. данные, не иниц. данные.
если это не так, значит, у программиста руки кривые ;)

> если это не так, значит, у программиста руки кривые ;)

который написал линкер ;-)

>> если это не так, значит, у программиста руки кривые ;)
> который написал линкер ;-)
не знаю как на счет багдада (давненько я не имел секса с ним), но ms link в этом отношении вполне нормален и особой голубизны я у него не замечал.
правда, при использовании RTL и библиотек могут проявляться различные конфликты, т.к. там они и те же секции именуются сильно неодинаково и от линера уже требуется изрядный ИИ чтобы рассортировать их на девочек и мальчиков, но это уже из другой области ;)