Re: NASM pe segfaults, RosAsm dissassembles the PE and runs it withoutsegfaulting

Frank Kotler wrote:

If anyone's into analysing Nasm's "-f win32" behavior... There's an
issue with "vsize" (I think that's the name of the field) in the
*object* header. Does it or does it not include .bss size? My
understanding is that MS documents "no" but *used* to do it "yes". When
MinGW "ld" first came out, they did it "as documented", and considered
Nasm "buggy"... but they "came around" (I understand).

I suppose you are speaking about SizOfImage. But this value is calculated
by the linker and not the assembler (or can NASM directly generate exe files).
All information I have found, says that it has to include all sections
(and therefore also the .bss). Otherwise there wouldn't be memory allocated
for the .bss. Which MS document says "no"?


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

Peering Inside the PE: A Tour of the Win32 Portable Executable File Format
Matt Pietrek March 1994
Matt Pietrek is the author of Windows Internals (Addison-Wesley, 1993). He works at Nu-Mega
Technologies Inc., and can be reached via CompuServe: 71774,362
This article is reproduced from the March 1994 issue of Microsoft Systems Journal.

DWORD SizeOfImage
This appears to be the total size of the portions of the image that the loader has to worry
about. It is the size of the region starting at the image base up to the end of the last section.
The end of the last section is rounded up to the nearest multiple of the section alignment.

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

From: THe Portable Executable File Format from Top to Bottom
Randy Kath, Microsoft Network Technology Group, June 12, 1993

SizeOfImage. Indicates the amount of address space to reserve in the address space
for the loaded executable image. This number is influenced by
SectionAlignment. For example, consider a system having a fixed page size of 4096
bytes. If you have an executable with 11 sections, each less than 4096 bytes, aligned
on a 65,536-byte boundary, the SizeOfImage field would be set to 11 * 65,536 =
720,896 (176 pages). The same file linked with 4096-byte alignment would result in
11 * 4096 = 45,056 (11 pages) for the SizeOfImage field. This is a simple example in
which each section requires less than a page of memory. In reality, the linker
determines the exact SizeOfImage by figuring each section individually. It first
determines how many bytes the section requires, then rounds up to the nearest
page boundary, and finally it rounds page count to the nearest SectionAlignment
boundary. The total is then the sum of each section's individual requirement.

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

http://msdn.microsoft.com/msdnmag/issues/02/02/PE/default.aspx
An In-Depth Look into the Win32 Portable Executable File Format

SizeOfImage contains the RVA that would be assigned to the section following the last
section if it existed. This is effectively the amount of memory that the system needs
to reserve when loading this file into memory. This field must be a multiple of the
section alignment.

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

http://msdn.microsoft.com/msdnmag/issues/02/03/Loader/
What Goes On Inside Windows 2000: Solving the Mysteries of the Loader

The job of LdrpAllocateDataTableEntry is to allocate this object and initialize the
ImageBase field using three values: the HMODULE handle returned by NtMapViewOfSection,
the ImageSize field using the SizeOfImage value found in the portable executable (PE)
file's optional header, and the TimeDateStamp from the equivalent field in the PE file
header. If the memory allocation fails, the routine returns a NULL pointer. LdrpMapDll
then removes the file mapping, closes the section handle, and fails, returning STATUS_NO_MEMORY.

-------------------------------------------------------------------------------------------------
.

Relevant Pages

  • Re: Problem with ASP on Webserver
    ... Entrek's TOOLBOX is a lot better for memory stuff. ... the script we sometimes ... (Accept-Language:) ...
    (microsoft.public.windowsce.platbuilder)
  • Re: some questions
    ... I think you believe that the program loader loads the PE header into ... windows does infact usually load the PE header to memory. ... You can use GetModuleHandleto get your image load address (it isn't ... the program loader doesn't simply load all the bytes of a PE ...
    (alt.lang.asm)
  • Re: Dynamic Disassembler (determine main() location at runtime)
    ... Once you have the PE header, it is simple to determine the section header VA's by parsing the image header itself. ... The memory manager sets pages as executable based on the section header for a region, which describes the protection flags for that region. ... The current dead space seems to be 0x00 and 0xCC on ... Windows SDK MVPhttp://www.nynaeve.net"Jeffrey Walton" wrote in message ...
    (microsoft.public.win32.programmer.kernel)
  • Re: execve() and heap memory
    ... We can divide the memory given to the address space of a unix process into ... process memory space between the high end of the 'bss' and the low end ... the 'stack'. ... as a 'heap', or even left empty. ...
    (comp.unix.programmer)
  • Re: Ive got a lot of beginner questions :(
    ... Depending on the host system's design the .data section is marked read+write and the .text section is marked either read+execute or just execute. ... The only information that is associated with this section is it's size, and when the executable is loaded and run, blank memory is allocated to accomidate the size that .bss is supposed to be and that memory is marked as read+write, just like .data. ... but it would not make a pointer. ...
    (comp.lang.asm.x86)