[section] directives

[nobody]

Hi!

I'm just wondering how the the primitive section diretive ([section]) is supposed to do. I have read the doc but it was highly insufficient and didn't really explain anything.


------------------------------

Some of my tests: sequences below generate correct sections:

[section code use32 class=code]
;CODE

[section code use32 class=bss]
;CODE

[section bss use32 class=rdata]
;CODE

[section rdata use32]
;CODE

[section LOL use32 class=LOL]
;CODE

-----------------------------------

A test source:

;assemble: nasm -f obj test.asm
;link: alink -oPE test.obj -entry start -subsys windows

import MessageBoxA user32.dll
extern MessageBoxA

global start

[section what use32 class=the]
start:
   push dword 0
   push dword szCaption
   push dword szText
   push dword 0
   call near [MessageBoxA]
   ret

[section  heck class=???]
szCaption   db 'Caption',0
szText      db 'Hello, how are you ?',0


------------

That may possibly relate to PE module format, but i don't know, all I know is that replacing the above "[section.." lines in test.asm with only "[section]" (and adding "user32" in the "code" section) still works, while it crashes if removing all section directives alltogether.

[nobody]

This should work:

;assemble: nasm -f obj test.asm
;link: alink -oPE test.obj -entry start -subsys windows

import MessageBoxA user32.dll
extern MessageBoxA

global start

section .text

start:
push dword 0
push dword szCaption
push dword szText
push dword 0
call near [MessageBoxA]
ret

section .data

szCaption db 'Caption',0
szText db 'Hello, how are you ?',0

[nobody]

I know that would also work. What I'm curious about is why my deliberate misdefinition of sections still produces correct output !!

[Frank Kotler]

First, the difference between the "primitive" form, "[section ...]", and the "user" form, "section ..." is only that the former doesn't set the internal __SECT__ variable... which you generally want to do. (used in the "struc" macro)

Nasm's "-f obj" format defaults to 32 bits, so you *should* need "use32" for 32-bit code. Why it's working without it is a mystery. I think maybe Alink is saving your a**.

The section names are arbitrary (unlike in most other output formats, where ".text", ".data" etc. mean something), as are the parameters to "class=", so with the exception of leaving out "use32" in the "heck"/".data" section, you haven't really "misdefined" anything.

I recall that Ollydebug used to complain about "entrypoint outside of code section" if you didn't say "class=code" - apparently "code" means something to Olly. Outside of that, it worked alright... As I recall...

I can't test the executable, but I *have* got Alink running on Linux (Thanks, Stewart!!!), and it produces an executable without complaint. Agner Fog's "objconv" does *not* disassemble the excutable correctly, however! Apparently "class-code" means something to objconv, too. The bytes look okay - including 32-bit addresses for variables in the "heck" section - but objconv thinks it's a data section and doesn't disassemble it as code...

Nasm just passes your arbitrary names and "class="s on to the linker. After that, it's a "linker question" - not Nasm's problem! I have no explanation for the fact that Alink seems to "know" that section "heck" needs to be 32 bits, even though you didn't say so...

What were you expecting it to do? What were you expecting to learn from the Manual that wasn't there?

Best,
Frank