Figure out why nasm 2.12 hates a macro

[steveklabnik]

The version of nasm packaged with debian stretch doesn't work, but the one with jessie does. It appears to be a change between nasm 2.11 and nasm 2.12, but working on both seems like a good idea.

[jtdowney]

I spent some time looking into this. I am not sure the code currently does what is expected, even under nasm 2.11. From looking at the code, it appears the expectation is the macro H{n}_IST will be used if it is defined. The only one I see is H8_IST, but when I run nasm -E src/arch/x86_64/interrupt_table.asm to view the macro expanded code it appears that H8_IST is not referenced correctly. My experience with nasm is very limited but it seems macros cannot be referenced across files since they appear to be assembled independently.

But purhaps I am missing something.

[steveklabnik]

Yeah, it's not totally clear to me. It does work on the older version...

[jtdowney]

It definitely works but I think it is doing something non-obvious and swallowing the error. If you remove the lines:

%ifdef H%1_IST
    DB H%1_IST      ;interrupt stack table index
%elif
    DB 0            ;no stack switch (if cpl doesn't change)
%endif

And replace them with:

DB 0

It will compile on nasm 2.11 and 2.12. What appears to be happening is that 2.11 is silently ignoring the issue and just always using the else branch in the pre-processor. You can validate this by comparing the hashes of the .o file with and without those lines and see that they're identical.

It even appears to always be 0 once the kernel has been fully linked if you use objdump to read the .data section.

[steveklabnik]

Ah ha, interesting.

On May 23, 2016, 15:06 -0400, John Downeynotifications@github.com, wrote:

It definitely works but I think it is doing something non-obvious and swallowing the error. If you remove the lines:

%ifdefH%1_ISTDBH%1_IST;interrupt stack table index%elifDB0;no stack switch (if cpl doesn't change)%endif

And replace them with:

DB0

It will compile on nasm 2.11 and 2.12. What appears to be happening is that 2.11 is silently ignoring the issue and just always using the else branch in the pre-processor. You can validate this by comparing the hashes of the.ofile with and without those lines and see that they're identical.

It even appears to always be0once the kernel has been fully linked if you useobjdumpto read the.datasection.

— You are receiving this because you authored the thread. Reply to this email directly orview it on GitHub(https://github.com/intermezzOS/kernel/issues/29#issuecomment-221060794)

[steveklabnik]

https://github.com/intermezzOS/kernel/pull/31 should have eliminated the bad macro but i want to verify before closing this

[steveklabnik]

The code now builds with both versions of nasm, so closing.