Guess what, SEH again, but in Win64 context, which is completely
different matter from Win32. At lowest level this one boils down to
putting so called imagerel references, or in practical terms
relocations of type ADDR32NB, 0x0003, into .pdata and .xdata
segments. Two possibilities. 1. implement say 'wrt ..imagerel' or 'wrt
..imagebase'. 2. silently enforce ADDR32NB relocations in .pdata and
.xdata segments.
This is basically not a bug report, but a feature request.
It's desired to be able to link .obj modules compiled with 'nasm -f
win32' with Microsoft 'link /safeseh'. As well as to register symbols
(commonly subroutine's entry points or even external symbols) as "safe
handlers." In order to achieve this, several points are required.
First of all, object module has to have absolute symbol named @feat.00
with value of 1. This can actually be achived by adding 'absolute 1'
and '@feat.00:' to source code, but it's desirable that it's
autogenerated for win32 modules.
Handler registration is essentially symbol's *index* in current
module's symbol table in .sxdata, segment with 0x200 segment flags, an
"info" segment. It's also essential that symbol has type 0x20 (see
below). All this is depicted in following framgents of 'objdump -xD'
output:
Sections:
Idx Name Size VMA LMA File off Algn
0 .sxdata 00000004 00000000 00000000 0000003c 2**2
CONTENTS, READONLY, DEBUGGING
SYMBOL TABLE:
...
[ 5](sec -1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000001 @feat.00
[ 6](sec 0)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000000 _handler
...
<.sxdata>
0: 06 00 00 00
Note [6] and (ty 20) in _handle line in SYMBOL TABLE. "06 00 00 00" in
.sxdata is little-endian 6, _handler's index. This is what makes up
"registration." It's impossible to achieve this with current nasm
facilities and it's probably appropriate to introduce a directive for
it, 'safeseh _handler' is probably most natural choice.
When using temporaries in macros, given them a unique prefix to avoid
namespace collisions when using one macro inside another.
Move the WSAA*() macros from outelf32/outelf64 to a separate header
file.
Clean up remaining build warnings. None of this should affect code
operations. The only warnings which were actually relevant might have
been the ones in ldrdf.c, but it's not clear if anyone ever uses that.
Fix one missed change from "type" to "size". May want to look through
all the other backends as well for similar issues.
This would generate the wrong section lengths, with obviously bad results.
Our size arguments are 64-bit values, but we don't need that range for
anywhere where we need a switch. OpenWatcom can't deal with them
(sigh), so cast them to (int) for now.
Address data is always int64_t even if the size itself is smaller;
this was broken on bigendian hosts (still need testing!)
Create simple "write sized object" macros.
Fix alignment handling in the Mach-O format. The patch is from the
bug report, mangled to apply to the current source base. I have no
way to test this, so I'm going to have to assume it's correct.
Don't combine type and size into a single argument; *every* backend
immediately breaks them apart, so it's really just a huge waste of
effort. Additionally, it avoids using short immediates in the
resulting code, which is a bad thing.
OpenWatcom doesn't like 64-bit switch arguments; the change to 64-bit
type arguments caused that to happen in outmacho.c. Hack around it
for now; however, realistically speaking the whole bit stealing thing
is probably a bad idea, especially since virtually all CPUs handle
short immediates better than long ones.
Proper use of bool and enum makes code easier to debug. Do more of
it. In particular, we really should stomp out any residual uses of
magic constants that aren't enums or, in some cases, even #defines.
Both C and C++ have "bool", "true" and "false" in lower case; C
requires <stdbool.h> for this, in C++ it is an inherent type built
into the compiler. Use those instead of the old macros; emulate with
a simple typedef enum if unavailable.
Concentrate compiler dependencies to compiler.h; make sure compiler.h
is included first in every .c file (since some prototypes may depend
on the presence of feature request macros.)
Actually use the conditional inclusion of various functions (totally
broken in previous releases.)
Per SF bug report 1351586:
The COFF spec suggests that the "Virtual Size" field (which
immediately follows the name field inside a section header) be set to
0 for an object file.
By contrast (as documented in comment #4 at the beginning of its
outcoff.c file) NASM sets it to a particular non-0 value.
MASM 6.15 matches NASM for both 16- and 32-bit object files,
i.e. emits non-0 values.
MASM 8 (from VS 2005 Beta) matches the COFF spec for 64-bit object
files, i.e. emits 0.
GAS matches the COFF spec for 32-bit object files (MinGW or Cygwin),
i.e. also emits 0.
Older versions of GNU ld seem to honor said "Virtual Size" field
whereas newer versions do not. As a result those older versions
generate "bloated" image files.
Since the COFF spec and the real world seem to disagree for this case,
it might make sense to add a method for selecting between the two to
NASM.
Date: 2005-11-28 15:39
Sender: nasm64developer
Logged In: YES
user_id=804543
MASM 8 (from VS 2005 Beta) also matches the COFF spec for 16- and
32-bit object files, i.e. emits 0.
That said, NASM should always emit 0 too. Therefore I am turning this
from a support request into a bug.
Minor fixes to make it possible to compile with MS Visual C++ 2005.
Unfortunately, MSVC++ is not fully C99 compliant; in particular, it
doesn't handle interspersed declarations and other code. Furthermore,
it chokes on some expressions in outelf64.c, which fortunately can be
easily substituted with simpler expressions.
Finish the perfect hash tokenizer, and actually enable it.
Move stdscan() et al to a separate file, since it's not needed in any
of the clients of nasmlib other than nasm itself.
Run make alldeps.
