GoLink is not outputting a .bss section in my EXE file

[Ben321]

My assembly code is correctly assembled into an OBJ file with NASM, and then linking with GoLink. This has worked so far up until now, with both .data and .text sections. Now I have just tried to add a .bss section but this isn't working. Looking at the OBJ file with a hex editor, I can see there is a .bss section in it, but it's not being put into the EXE file by GoLink. Please fix this. I need the memory allocated by a .bss section to store some data generated in one part of my program, so it is accessible in other parts of my program. Please fix this. Thanks in advance.

[dedndave]

i am no expert with GoAsm, but in MASM source code,
you use .DATA to open a data section and .DATA? to open a bss section

[Ben321]

Here's my test code

Code: [Select]

GLOBAL main

SEGMENT .bss
hStdIn: resd 1
hStdOut: resd 1
hStdErr: resd 1

SEGMENT .data
STD_INPUT_HANDLE: dd -10
STD_OUTPUT_HANDLE: dd -11
STD_ERROR_HANDLE: dd -12

SEGMENT .text

main:
mov [hStdIn],eax
ret
I then ran NASM with this command line:
nasm -f win32 myprog.asm

I then ran GoLink with this command line:
golink /entry main myprog.obj

The final EXE file doesn't have a .bss section. Why not?

[wjr]

Linkers typically merge the .bss section with the .data section. GoLink does so by increasing the virtual size of the .data section by the size of .bss section. Your test OBJ file has a .data section and .bss section each requiring 12 bytes. The final EXE has a .data section with a virtual size of 24 bytes.

Ben is using NASM, but it is a bit different with GoAsm with uninitialised data written in the source file with the .data section using ?:

Code: [Select]

.DATA
hStdIn DD ?
hStdOut DD ?
hStdErr DD ?


[Ben321]

Linkers typically merge the .bss section with the .data section. GoLink does so by increasing the virtual size of the .data section by the size of .bss section. Your test OBJ file has a .data section and .bss section each requiring 12 bytes. The final EXE has a .data section with a virtual size of 24 bytes.

Ben is using NASM, but it is a bit different with GoAsm with uninitialised data written in the source file with the .data section using ?:

Code: [Select]

.DATA
hStdIn DD ?
hStdOut DD ?
hStdErr DD ?


There should be a command line switch like /bss  in order to force it to create a separate .bss segment for uninitialized data, so if it detects a .bss section in the OBJ file, it will automatically create a separate .bss section in the EXE file if this command line switch is used. The official EXE specification I believe requires a separate section for uninitialized data. And more importantly, it is easier to debug, using software such as OllyDbg if there is a separate memory block dedicated to uninitialized data. It would be nice if such a feature could be included in the next version of GoLink. Consider this posting to be a feature request.

[dedndave]

the bss section is uninitialized data
you don't want to increase the size of the exe
the OS creates the section when it loads the program - filled with 0's
the exe should only have an entry to tell how large it is

[Ben321]

the bss section is uninitialized data
you don't want to increase the size of the exe
the OS creates the section when it loads the program - filled with 0's
the exe should only have an entry to tell how large it is

Combining the initialized and uninitialized sections, by making the in-memory size of the initialized section equal to the sum of the initialized and uninitialized data sections, isn't going "by the book". The uninitialized data section (.bss) is supposed to have its own separate section definition header, but no actual space stored in the EXE file for this section. I prefer these sections to be separate, because not only is it the official correct way to do it, it also (and far more importantly) makes it easier for me to debug my programs. So this is a feature request for a feature that I really REALLY want. The feature in question is a command line switch /bss that would make GoLink create a separate .bss section in the event that OBJ file input has a .bss section in it.

[dedndave]

it's kind of a moot point, really

in the old days of 16-bit DOS, it made a difference because different memory models combined segments in different ways
SMALL model programs would combine and group data segments together to simplify addressing

however, in the world of 32-bit and 64-bit NT based operating environments,
the EXE uses a Flat memory model
so, the text, data, bss, and constant sections are all combined into one "segment"
the only difference between the sections when executing, is the virtual memory page security attributes
the attributes are the same for .data and .bss
of course, .data content is initialized, and the values must be carried in the EXE prior to load
.bss content is not initialized, and need not be contained in the EXE file

[dedndave]

here is a pe/coff file spec PDF

http://masm32.com/board/index.php?topic=240.msg1119

if you follow that thread, you will see a few newer versions
but, the links all appear to be dead, now   :(
the .bss info probably hasn't changed much, though   

[Ben321]

it's kind of a moot point, really

in the old days of 16-bit DOS, it made a difference because different memory models combined segments in different ways
SMALL model programs would combine and group data segments together to simplify addressing

however, in the world of 32-bit and 64-bit NT based operating environments,
the EXE uses a Flat memory model
so, the text, data, bss, and constant sections are all combined into one "segment"
the only difference between the sections when executing, is the virtual memory page security attributes
the attributes are the same for .data and .bss
of course, .data content is initialized, and the values must be carried in the EXE prior to load
.bss content is not initialized, and need not be contained in the EXE file

Even so, I believe there should be a command line switch to cause GoLink to output a .bss section when a .bss section is actually included in the source code. I have a certain expectation, that what goes into the source code ends up in the OBJ file and then the EXE file. I don't like it when the linker decides to combine something that I never told it to (like the .bss and .data sections). Obviously the devs who made GoLink like it the way it is or they wouldn't have made it that way, which is why I'm suggesting a compromise, where the way it works in this regard could be changed with a command line switch. So if I want to use it the way I want to, I can use the switch. If somebody else prefers the way that GoLink has handled this all along, then they can choose to not use that command line switch.