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
"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
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
* Replace ulongs secthead.size, secthead.align, reloc.addr with intnums
* Calculate relocation size with intnums
* Create macros YASM_WRITE_32I_L, YASM_WRITE_64I_L to write 32/64bit
intnums to buffer
This doesn't quite cover everything, particularly due to various calls
to yasm_intnum_get_uint for various bits of processing, but it's close!
Miscellany:
* Fix non-call to elf_reloc_delete()
* Remove unused secthead.addr, secthead_set_addr
* Create macro YASM_WRITE_64Z_L to write zero-extended 32bit value to
64bits of buffer
svn path=/trunk/yasm/; revision=1030
Add elf x86 test case to verify it works properly.
Unsure about elf x86-64 status (relocations segfault my objdump), but
it's no *worse* than last commit.
svn path=/trunk/yasm/; revision=1029
Move more machine-specific items to the backend (EHDR_SIZE) and make it
target machine-dependent there.
Theoretically everything except relocations may work, but since builds
of amd64 with bits=32 can segfault objdump, don't trust it.
Work to support relocations is next; perhaps then it can be tested.
svn path=/trunk/yasm/; revision=1028
Add elf_set_arch function to tell elf backend the machine, allow to deny.
Move arch/machine checking into backend.
svn path=/trunk/yasm/; revision=1026
another test such that linked together they verify that
1. It links properly
2. The constant is loaded properly
3. The function is called properly
shown (probably not proved) by the program exiting with error level 0.
svn path=/trunk/yasm/; revision=1024
module users to ensure the module interface they're using matches the
interface the module was compiled with. The #define YASM_module_VERSION
should be incremented on every functional change to the module interface.
svn path=/trunk/yasm/; revision=1021
differentiate e.g. AMD64 from x86. Doesn't prohibit anything in x86 yet,
but does standardize unsupported warnings across objfmts (most objfmts will
not support all machines and/or all architectures).
svn path=/trunk/yasm/; revision=1020
use of configure.ac's --enable-warnerror, which was set up to disable
conversion errors due to flex's warning-prone generated code. As we no
longer use flex, fix configure.ac to not disable conversion errors.
svn path=/trunk/yasm/; revision=1018
- Switch to bit-based output, including shift capability
- This means the standard intnum output functions can be used for non-byte
oriented archs like LC-3b (implemented)
- Default out of range (overflow) warnings for intnum (bugzilla bug 14)
- Change floating point overflow/underflow errors to warnings
To do (hooks but not implemented):
- Shifting floatnums into destination
- Floatnum destinations larger than floatnum value
- Big endian support for intnum and floatnum
Related simultaneous changes:
- Use bc instead of ep in objfmt output_expr() functions; while bc->line
should == (*ep)->line, in case they differ, we want to use the bc->line
so as not to confuse users.
- lc3b-mp22NC test was not properly offsetting the accessed variables, but
since the variable "sections" started at an aligned offset, the output
was actually correct. The new intnum warnings uncovered this issue, so
fix code to be correct (and not generate warnings).
svn path=/trunk/yasm/; revision=1017
expression line number instead of the start line number (which may be 0,
which isn't nearly as useful as the expression line number).
svn path=/trunk/yasm/; revision=1016
ELF objfmt implementation.
Assumed to be correct for the test cases, but only tested as far as feasible.
Currently only implements 32bit 386 little-endian, but is mostly abstracted
well enough to easily add more machines.
svn path=/trunk/yasm/; revision=1015
intnum folding on and leveling performed would result in terms getting copied
over due to hitting o != i case after i++ but no o++.
Bugzilla: #12.
Reported by: meor@softhome.net
svn path=/trunk/yasm/; revision=1009
- Up internal format size to 128 bit.
- Use full internal format size for all calculations.
- Always store negative numbers using full internal size
(avoids 0xffffffff == -1?? issue)
This fixes many inconsistencies in handling of >32-bit intnums.
svn path=/trunk/yasm/; revision=995
of [ORG] in bin objfmt. Still need to assess impact of self-referential
(invalid) ORG, and how to detect for that condition.
svn path=/trunk/yasm/; revision=990
similar label names).
Test also found a bug in COFF parsing of section options; this will be fixed
and a separate test added explicitly for it.
svn path=/trunk/yasm/; revision=982
- Move config.h and util.h from libyasm (and installed libyasm) to top level.
- Move yasm_* functions from util.h to coretype.h.
- Remove a number of autoconf-related YASM_*_INTERNAL options from libyasm.h.
- Rename YASM_INTERNAL to YASM_LIB_INTERNAL; it now actually means what the
comment describes: enables definitions that violate the yasm_* namespace.
While we're at it, no longer define YASM_LIB_INTERNAL from yasm frontend, so
it's closer to what a real typical libyasm-using application would look like.
svn path=/trunk/yasm/; revision=944
from yasm_keyword (separating same-keyword modules of different types). Update
yasm frontend module loader to handle this.
svn path=/trunk/yasm/; revision=921
key headers in certain situations (config.h when compiling with Visual C++ for
one), and is also more correct in general.
svn path=/trunk/yasm/; revision=887
When -Werror is used, disable -Wconversion, because flex-generated code causes
warnings when calling fwrite() and fread().
svn path=/trunk/yasm/; revision=873
Peter Johnson
Michael Urman