CODEWITHSUNDEEP
gccassemblyx86
Reuben Scratton
Reuben Scratton

Reputation: 38707

GCC x86 assembler function tables

I'm writing a 6502 emulator in x86 assembly language. The heart of the emulated machine is a 256-entry table of code pointers for each 6502 opcode :

fns_asm:
.word opasm_brk         // 0x00 BRK
.word opasm_ora_indzx   // 0x01 ORA (,x)
.word opasm_undef
.word opasm_slo_indzx   // 0x03: SLO (,x)
.word opasm_nop_zp      // 0x04: NOP zp
...

opasm_brk:
< implementation of BRK instruction >

opasm_ora_indzx
< implmentation of ORA instruction >

... etc ...

The problem is that the compiled shared library (.so) fails to load at runtime. The error reported on x86 Android is:

dlopen("/data/app/com.myapk/lib/x86/lib6502.so", RTLD_LAZY) failed: dlopen failed: cannot locate symbol "" referenced by "lib6502.so"

Note the empty symbol name, very unhelpful!

I've worked out that my function table is to blame... if I change fns_asm to be a zero-entry table, or to have a single entry with a constant rather than a label (i.e. ".word 0") then the .so loads fine. It's the referencing of labels with .word directives that causes things to go wrong.

What am I doing wrong?

Upvotes: 0

Views: 480

Answers (1)

Michael
Michael

Reputation: 58437

The documentation for .word in the GAS manual says:

The size of the number emitted, and its byte order, depend on what target computer the assembly is for.

I haven't found an authoritative source for the size of a .word for different targets. However, the term word in the context of an x86 system means 16 bits (in Intel's manual, in the section Fundamental Data Types, they say "a word is 2 bytes (16 bits)").

Assuming that you're not writing an emulator to be run in 16-bit real mode you probably wanted your function table entries to be 32-bit. The appropriate pseudo-op to use for that when targetting x86 systems is .long.

Upvotes: 2

Related Questions