So basically I my nasm syntax asm code, I use some extern functions like this:extern _printfextern __imp__Sleep@4....call _printfcall    [__imp__Sleep@4]Then I use nasm to assemble it into obj:nasm -f win32 test.asmThen I use IDA Pro to disassemble test.obj, I can see code like this: See, extern function name like _printf has been kept.But when I link this obj file:cl /MT z:\\windows\\test.obj /link kernel32.lib libcmt.lib /SUBSYSTEM:CONSOLEThen I use IDA Pro to disassemble test.exe, I can see code like this:See, the function name of _printf has been changed.I know basically after static link, the code of _printf has been put into the test.exe, in the subroutine of sub_409C9BBut basically I have to make the name of extern declared functions unchangeable, because I need to reverse engineering the test.exe and do some modify/remove towards those functions, and once PE exe lost the name info, I can not locate those targeting functions.So my question is:Why cl.exe will change the name of those functions, and is there any way to stop the change(I mean keep the function name unchangeable during the link time)?
Why cl.exe change the extern function name used in my code?
ida;winapi;nasm
You've got some kind of XY-problem.The truth is: it's IDA who so to say changes the name of (something she thinks is) a function from absolutely nothing to sub_{address}. Why on earth would PE-file have non-exported symbols stored in it? Some kind of masochism? To give a candy to reversers?Thus, you have at least three ways of dealing with your problem:pray and hope that IDA's FLIRT will heuristically recognize printf;link your program with debug-info: -debug which tells linker to generate pdb-file which IDA will query for all the symbols stored for your application;tell linker to -export:printf so that it's name will be in export directory and you can get it's address easily even programmatically.