in 64-bit (AMD64) mode. Intel says these bytes should not be treated as
prefixes, but AMD64 treats them as legacy prefixes, expecting them to come
before the REX byte.
For now, keep the three-byte max instruction length (although it's not truly
correct), as handling the other "3-byte" cases such as R/M spare with no EA
is probably more painful than it's worth to push down to later in the code
generation path.
Reported by: Henryk Richter <henryk.richter@comlab.uni-rostock.de>
svn path=/trunk/yasm/; revision=1094
- PEXTRW
- MOVMSKPD
- MOVMSKPS
- PMOVMSKB
Reported by: Vivek Mohan <vivekm@phreaker.net>
Also, while we're here, fix all CVT* SIMD instructions; they were variously
incorrect (mostly with regards to accepted operands).
New testcase, simd-2, tests all the above (output verified with GNU objdump).
svn path=/trunk/yasm/; revision=1093
Currently requires Perl installed as \Program Files\Perl\bin\perl.
Contributed by: Brian Gladman <brg@gladman.plus.com>
svn path=/trunk/yasm/; revision=1090
use of the ORG macro (several user comments about the lack of this) and the
initial value of the __SECT__ macro (used by ENDSTRUC among other macros).
Fortunately, for all current objfmts, __SECT__ is currently defined as
[section .text], so one common definition can be used for now.
FIXME: remove this workaround when a better solution has been implemented.
svn path=/trunk/yasm/; revision=1087
NASM parser by changing the libyasm yasm_fatal() interface to use va_list
instead of ... variable arguments. Add a yasm__fatal() function that takes
... and calls yasm_fatal().
Bugzilla bug #22
Reported by: mu@tortall.net
svn path=/trunk/yasm/; revision=1086
values into 32bits as necessary. This is the proper fix to "written
length does not match optimized length" in amd64+stabs.
Reported by Jeff Lawson <jlawson-yasm@bovine.net>
svn path=/trunk/yasm/; revision=1084
Previously only "symvalue" stabs did this, causing a mismatched output size
with amd64 and stabs. However since it appears the actual stabs spec always
uses 12 byte stabs, this fix is already obsolete and will be superceded
shortly.
Reported By: Jeff Lawson <jlawson-yasm@bovine.net>
svn path=/trunk/yasm/; revision=1083
"functions" that call down to the module level. Doesn't really change the
internal complexities, just makes it easier to read and write code that
uses it.
svn path=/trunk/yasm/; revision=1080
first parameter (before MOD_Op2Add). Before this change, MOD_Gap0 did not
eat a parameter until AFTER MOD_Op2Add.
Reported by: Edouard Gomez <ed.gomez@free.fr>
svn path=/trunk/yasm/; revision=1076
reporting functions that take a parameter for the line to be displayed in
addition to the the line used for sorting. This allows the "previously
defined" message to use the standard errwarn line resolution functions.
The resulting error messages look like gcc output.
Reported by: Edouard Gomez <ed.gomez@free.fr>
svn path=/trunk/yasm/; revision=1074
pcmp* family. The first three had some operand encoding problems, and pcmp*
was typoed as pacmp*.
Reported by: Edouard Gomez <ed.gomez@free.fr>
svn path=/trunk/yasm/; revision=1072
- Removal of backslash() - why was this okay?
- Addition of pp_get_include_path_ptr() - we (will eventually) do this a
different way in yasm.
svn path=/trunk/yasm/; revision=1064
As yasm has evolved, various minor additions have been made to libyasm to
support the new features. These minor additions have accumulated, and
some contain significant redundancies. In addition, the core focus of
yasm has begun to move away from the front-end commandline program "yasm"
to focusing on libyasm, a collection of reusable routines for use in all
sorts of programs dealing with code at the assembly level, and the modules
that provide specific features for parsing such code.
This libyasm/module update focuses on cleaning up much of the cruft that
has accumulated in libyasm, standardizing function names, eliminating
redundancies, making many of the core objects more reusable for future
extensions, and starting to make libyasm and the modules thread-safe by
eliminating static variables.
Specific changes include:
- Making a symbol table data structure (no longer global). It follows a
factory model for creating symrecs.
- Label symbols now refer only to bytecodes; bytecodes have a pointer to
their containing section.
- Standardizing on *_create() and *_destroy() for allocation/deallocation.
- Adding a standardized callback mechanism for all data structures that
allow associated data. Allowed the removal of objfmt and
dbgfmt-specific data callbacks in their interfaces.
- Unmodularizing linemgr, but allowing multiple linemap instances (linemgr
is now renamed linemap).
- Remove references to lindex; all virtual lines (from linemap) are now
just "line"s.
- Eliminating the bytecode "type" enum, instead adding a standardized
callback mechanism for custom (and standard internal) bytecode types.
This will make it much easier to add new bytecodes, and eliminate the
possibility of type collisions. This also allowed the removal of the
of_data and df_data bytecodes, as objfmts and dbgfmts can now easily
implement their own bytecodes, and the cleanup of arch's bytecode usage.
- Remove the bytecodehead and sectionhead pseudo-containers, instead
making true containers: section now implements all the functions of
bytecodehead, and the new object data structure implements all the
functions of sectionhead.
- Add object data structure: it's a container that contains sections, a
symbol table, and a line mapping for a single object. Every former use
of sectionhead now takes an object.
- Make arch interface and all standard architectures thread-safe:
yasm_arch_module is the module interface; it contains a create()
function that returns a yasm_arch * to store local yasm_arch data; all
yasm_arch_module functions take the yasm_arch *.
- Make nasm parser thread-safe.
To be done in phase 2: making other module interfaces thread-safe. Note
that while the module interface may be thread-safe, not all modules may be
written in such a fashion (hopefully all the "standard" ones will be, but
this is yet to be determined).
svn path=/trunk/yasm/; revision=1058
changes to the dbgfmt interface, and other assorted updates, including:
* yasm.c now calls df->initialize() and df->generate()
* a dbgfmt bytecode type with associated handling
* yasm_output_reloc_func type for use particularly by dbgfmts
* df: initialize updated; generate, bc_dbgfmt_data_{output|delete|print} added
* null-dbgfmt structure brought in line with these additions
* elf-objfmt made aware of stabs sections, and what to do with them
The bad news:
* just enough stabs output to support line number information in GDB
* GDB identifies function labels off by 3 bytes in my test, but line
numbers remain correct, somehow. Unknown whether stabs-dbgfmt or GDB
at fault.
svn path=/trunk/yasm/; revision=1037
[rip+symbol] in that the latter adds the symbol offset to rip, whereas the
former is the same as [symbol] but uses rip-relative addressing. This is
a minor overload of the WRT operator, but reads well and shouldn't conflict
with the use of WRT against sections.
Doing this currently adds a bit of overhead to all effective addresses in
64-bit mode (a $ symbol reference). This is the cleanest approach I could
figure out; a time/space trade could be made later, such as prescanning for
RIP usage before allocating the symbol.
svn path=/trunk/yasm/; revision=1032
Peter Johnson
Michael Urman