Ticket #99 (closed defect: fixed)
Can yasm have sections (in a bin file) with local ORG en $ statements?
| Reported by: | mhx@… | Owned by: | |
|---|---|---|---|
| Priority: | P1 | Milestone: | |
| Component: | Core | Version: | 0.5.0 |
| Severity: | normal | Keywords: | |
| Cc: |
Description
I don't know if this is a bug or a feature request ...
Can yasm have sections (in a bin file) with local ORG and $ statements?
What I'd like to do is assemble some bytes, put their addresses in a data table, and in that table also build some linked list(s). To build the lists, I need to know where exactly the data is in that data table.
Below is an example. It won't assemble because AFAIK one can't use $ with %assign.
In MASM I could do this by using the "=" statement to temporarily store the $ from the code segment (and restore it afterwards). Also, in MASM switching to another segment will have $ report offsets from the base of that segment.
%assign codeptr 100h %assign dataptr 200h SECTION .text ORG codeptr dq $ dq 1 dq 2 dq $ %assign codeptr $ SECTION .data ORG dataptr dq $ dq 11h dq 22h dq $ %assign dataptr dataptr+4*8 SECTION .text ORG codeptr dq $ dq 3 dq 4 dq $ %assign codeptr $ SECTION .data ORG dataptr dq $ dq 33h dq 44h dq $ %assign dataptr dataptr+4*8
Attachments
Change History
comment:2 Changed 3 years ago by amand.tihon@…
When creating ELF files from scratch, this bug is pretty annoying.
With x86_64 binaries under linux, the code segment must be mapped on 0x400000 and the data segment is mapped on 0x600000. Having multiple ORG directive (even if only one per section) would greatly help.
Example :
BITS 64
SECTION .text
org 0x400000
; Elf Header blurb
entry_point dd _start
; more header blurb
_start:
; some code here...
xor edi, edi
mov eax, 60
syscall ; exit, return code = 0
SECTION .data
org 0x600000
some_data dd 42
In this short program, the value at "entry_point" should clearly be in the 0x400000 range, but the second ORG statement come in the way, and the value is in the 0x600000 range instead.
Probably for the exact same reason, some size calculations ($ - $$) don't work as expected.
Version is yasm 0.5.0.1591
comment:3 Changed 3 years ago by peter@…
- Status changed from new to closed
- Resolution set to fixed
Fixed in [2010]. The syntax is not multi-ORG but rather uses special section attributes to indicate where the data is loaded (LMA) or executed (VMA). The syntax is NASM-compatible.
Your example would be written as follows with the support added in [2010]:
BITS 64
SECTION .text vstart=0x400000
; Elf Header blurb
entry_point dd _start
; more header blurb
_start:
; some code here...
xor edi, edi
mov eax, 60
syscall ; exit, return code = 0
SECTION .data vstart=0x600000
some_data dd 42
See [2010] for a summary of features for now; I'll be adding full documentation to the yasm user manual in the next day or two.

Your example is a bit confusing, as Yasm will combine the multiple .text sections into a single continuous section (and likewise the multiple .data sections) in the order given in the file, so it's not necessary to "save and restore" the code position and data position. You can assign the current position to a symbolic name using EQU (e.g. thispos EQU $), but you can only EQU once.
You're right in that Yasm doesn't support multiple ORG, much like NASM doesn't. NASM-style multi-section binary support is planned for Yasm (see #71), which has better support for explicit positioning of sections into the file, but that seems like overkill for your example (unless you really must have the .data section start at 200h in the file, rather than immediately after the .text).