собственно, вот например:

#pragma section("mysec", read, write, execute)

__declspec(allocate("mysec")) ULONG MyUlong;
VOID MyFunc();

#pragma alloc_text(mysec, MyFunc)

VOID MyFunc(){
    MyUlong = 321;
}

Checked build, собирать отказывается без ссылок на MyFunc, а если ссылки есть — соберет так, что переменная и функция будут в разных секциях с одним и тем же названием.
Вообщем, как бы его заставить собирать код в заданном файле, да так что бы и код и данные были в одной секции как в checked так и fre сборках?

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

S>собственно, вот например:
S>

S>#pragma section("mysec", read, write, execute)

S>__declspec(allocate("mysec")) ULONG MyUlong;
S>VOID MyFunc();

S>#pragma alloc_text(mysec, MyFunc)

S>VOID MyFunc(){
S>    MyUlong = 321;
S>}
S>

S>Checked build, собирать отказывается без ссылок на MyFunc, а если ссылки есть — соберет так, что переменная и функция будут в разных секциях с одним и тем же названием.
S>Вообщем, как бы его заставить собирать код в заданном файле, да так что бы и код и данные были в одной секции как в checked так и fre сборках?

отключите оптимизацию

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

S>собирать отказывается без ссылок на MyFunc

В DDK/WDK по умолчанию используется опция компилятора /Gy, выделяющая функции из общего потока кода, и опция линкера /opt:ref, удаляющая такие функции, на которые нет ссылок. Поищите в скриптах, можно ли их отключить или подавить.

Другой вопрос — а нужны ли в честном коде подобные выкрутасы?

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

S>#pragma section("mysec", read, write, execute)

Слегка оффтоп:
на Windows 10 с включенным Device Guard / HVCI драйвер с такой секцией вообще не будет загружен.

Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Другой вопрос — а нужны ли в честном коде подобные выкрутасы?
Ну прям уж честным я код бы не стал называть Но от подобной идеи уже отказался.

Не буду создавать новую тему, спрошу тут.
А где вообще документацию найти для build утилиты (wdk 7600) и весь синтаксис файла sources и его переменных ? У мс этот момент как то ну вообще слабо гуглится (обрубками)...

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

S>Не буду создавать новую тему, спрошу тут.
S>А где вообще документацию найти для build утилиты (wdk 7600) и весь синтаксис файла sources и его переменных ? У мс этот момент как то ну вообще слабо гуглится (обрубками)...

Вместе с WDK 7 идет набор документации, самое полное описание там, скорее всего.
У MS есть тенденция вместе с обновлением своих тулкитов старую документацию прятать куда-то на задворки
или вообще убирать...

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

O>Вместе с WDK 7 идет набор документации, самое полное описание там, скорее всего.
O>У MS есть тенденция вместе с обновлением своих тулкитов старую документацию прятать куда-то на задворки
O>или вообще убирать...

Всё что нашёл, только "PREfast for Drivers" и "Static Driver Verifier".
Меня интересует вот что — сейчас build command выглядит так

C:\Windows\System32\cmd.exe /k "C:\WinDDK\7600.16385.1\bin\setenv.bat C:\WinDDK\7600.16385.1\ chk x86 WIN7 no_oacr & cd /d $(ProjectDir) & build"
C:\Windows\System32\cmd.exe /k "C:\WinDDK\7600.16385.1\bin\setenv.bat C:\WinDDK\7600.16385.1\ chk x64 WIN7 no_oacr & cd /d $(ProjectDir) & build"
copy "$(ProjectDir)objchk_win7_x86\i386\drv.sys" "$(TargetDir)drv.sys" /y
copy "$(ProjectDir)objchk_win7_amd64\amd64\drv.sys" "$(TargetDir)drv64.sys" /y

Билд под х64 и х86 сразу. До этого момента устраивало, но теперь нужен третий — тоже х64, но еще с дополнительным макросом (#define).
Причём, желательно бы этот макрос обработать еще до компиляции в sources, что бы задать свой TARGETNAME на каждый тип билда, поскольку вторая x64 версия ляжет в ту же objXXX_win7_x64 (можно конечно переименовать после первого билда, но хочется что бы на выходе было 3 комплекта obj/sys/pdb без танцев с бубном).

Ну или как бы по другому реализовать бы задуманное?

upd. Пришла идея в голову использовать разные sources, получилось примерно так

project
    one.c
    two.c
    \build\
        \x64v2\
            makefile
            sources
        \x64\
            makefile
            sources

каждый выглядит примерно так

SOURCES = \
..\one.c \
..\two.c

Но утилита в упор отказывается их видеть. ЧЯДНТ ?

upd2. за неимением лучшего пока ограничился копированием нужного sources файла перед сборкой

ups3. полный провал, не пересобирает от одного изменения sources, что можно предпринять ?