Re: А как заставить ddk собирать неиспользуемый код ?
От: okman Беларусь https://searchinform.ru/
Дата: 25.09.18 09:05
Оценка: 2 (1)
Здравствуйте, smbdnew, Вы писали:

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


Слегка оффтоп:
на Windows 10 с включенным Device Guard / HVCI драйвер с такой секцией вообще не будет загружен.
А как заставить ddk собирать неиспользуемый код ?
От: smbdnew  
Дата: 25.09.18 08:14
Оценка:
собственно, вот например:
#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 сборках?
Re: А как заставить ddk собирать неиспользуемый код ?
От: mike_rs Россия  
Дата: 25.09.18 08:38
Оценка:
Здравствуйте, 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 сборках?

отключите оптимизацию
Re: А как заставить ddk собирать неиспользуемый код ?
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 25.09.18 09:04
Оценка:
Здравствуйте, smbdnew, Вы писали:

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


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

Другой вопрос — а нужны ли в честном коде подобные выкрутасы?
Re[2]: А как заставить ddk собирать неиспользуемый код ?
От: smbdnew  
Дата: 25.09.18 10:21
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Другой вопрос — а нужны ли в честном коде подобные выкрутасы?
Ну прям уж честным я код бы не стал называть Но от подобной идеи уже отказался.
Re: А как заставить ddk собирать неиспользуемый код ?
От: smbdnew  
Дата: 08.10.18 07:17
Оценка:
Не буду создавать новую тему, спрошу тут.
А где вообще документацию найти для build утилиты (wdk 7600) и весь синтаксис файла sources и его переменных ? У мс этот момент как то ну вообще слабо гуглится (обрубками)...
Re[2]: А как заставить ddk собирать неиспользуемый код ?
От: okman Беларусь https://searchinform.ru/
Дата: 08.10.18 07:53
Оценка:
Здравствуйте, smbdnew, Вы писали:

S>Не буду создавать новую тему, спрошу тут.

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

Вместе с WDK 7 идет набор документации, самое полное описание там, скорее всего.
У MS есть тенденция вместе с обновлением своих тулкитов старую документацию прятать куда-то на задворки
или вообще убирать...
Re[3]: А как заставить ddk собирать неиспользуемый код ?
От: smbdnew  
Дата: 08.10.18 08:17
Оценка:
Здравствуйте, 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, что можно предпринять ?
Отредактировано 08.10.2018 12:12 smbdnew . Предыдущая версия . Еще …
Отредактировано 08.10.2018 10:32 smbdnew . Предыдущая версия .
Отредактировано 08.10.2018 8:41 smbdnew . Предыдущая версия .
Отредактировано 08.10.2018 8:40 smbdnew . Предыдущая версия .
Отредактировано 08.10.2018 8:18 smbdnew . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.