ADDR32 relocation invalid without /LARGEADDRESSAWARE:NO (VS)

[PhantomR]

I'm using Visual Studio 2017 to develop a "kernel". However, I recently tried integrating some assembly code with my C files only to get this weird error:
"Error LNK2017 'ADDR32' relocation to '.data' invalid without /LARGEADDRESSAWARE:NO"

I'm posting links to my small assembly code, should someone want to take a look. I'm declaring this function as

Code: Select all

extern "C" void pit_interrupt();

in my C code and calling it. The assembly file is built using the "-f win64" flag for NASM. EDIT: Also, should it have any meaning, this assembly file resides in a Static Libary (.lib) project and I'm calling it inside that project.

Maybe it's also meaningful in some way, I loaded the kernel at a higher-half 64bit address.

https://pastebin.com/d9VzKe9r (main assembly file)
https://pastebin.com/99kySJFY (included macros.inc)

EDIT: Also, it's really strange, but a similar code actually seemed to work when using MASM instead of NASM .

[alexfru]

The code looks 64-bit, but that option is typically used for 32-bit code.
Are you making a 32-bit binary somehow by mistake?

[PhantomR]

I honestly wish I was building a 32-bit binary, but, sadly, no, it's 64 bits .

EDIT: I added this note to the main post as well: "Maybe it's also meaningful in some way, I loaded the kernel at a higher-half 64bit address."

[alexfru]

See the following sections in nasmdoc:

3.3 Effective Addresses
6.2 `DEFAULT': Change the assembler defaults
7.6.1 `win64': Writing Position-Independent Code
11.2 Immediates and Displacements in 64-bit Mode

(Section 7.6.1 mentions the error you're getting, but read all of those sections mentioned.)

IOW, you may want "default rel" at the beginning of the asm file. Or use "rel" in memory operands.

[Octocontrabass]

Your references to pit_count are in the form of signed absolute 32-bit displacements, but the linker thinks your kernel is somewhere outside that range.

If your kernel is not within the top 2GB of address space (or you can't convince the linker that it is), you'll have to use a different addressing mode. As far as I know, your choices are 32-bit relative addressing and 64-bit addressing. Relative addressing is a sensible default; you can use "default rel" to tell NASM that all memory references are 32-bit relative unless otherwise specified, or just "[rel pit_count]". If you really need a 64-bit offset for some reason you can use "[qword pit_count]", but it's only valid when RAX/EAX/AX/AL is the source or destination. If you're using "default rel" you must also specify that it's absolute addressing: "[abs qword pit_count]".