Ticket #99 (closed defect: fixed)

Opened 1 year ago

Last modified 8 months ago

Can yasm have sections (in a bin file) with local ORG en $ statements?

Reported by: mhx@iae.nl Assigned to:
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

02/15/07 00:32:02 changed by peter@tortall.net

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).

08/24/07 10:47:30 changed by amand.tihon@alrj.org

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

11/14/07 00:37:20 changed by peter@tortall.net

  • 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.

Add/Change #99 (Can yasm have sections (in a bin file) with local ORG en $ statements?)