writing to data or bss section variables

[mineiro]

Hello sir Bogdan, I hope you're fine.
I'm being able to write on variables into data or bss section by using registers but not using direct value.

Code: [Select]

.use64
section "text" class_code alias ".text"
section "data" class_data alias ".data"
section "bss"  class_bss  alias ".bss"

.entry _start

.bss
test dq ?

.data
tst dq 0

.text
_start:
  mov [test], 0  ;<---
  mov [tst], 0   :<---

  mov rdi,0
  mov rax, 60
  syscall
 
/*
sol_asm2 mov0.solasm mov0.o -elf64
ld -m elf_x86_64 -o mov0 mov0.o
rm list.o
*/I'm able to 'xor eax,eax' or 'xor rax,rax' and after mov zeroed register to tst or test variable. But if I try direct number on that variables, on bss section solasm give me some errors while assembling and on data section assemble fine but when I execute program I'm receiving segmentation fault.
thanks.

[bogdanontanu]

Hi mineiro,

Thanks for testing this.

I will check it out and fix it

[mineiro]

Can you check this too, not sure if this is my fault but I'm being unable to write a literal string inside some structure.
I perceived that when using duplicated names some mistakes happen. Like same name on variable and after defined as a literal string.

Code: [Select]

.use64
section "text" class_code alias ".text"
section "data" class_data alias ".data"
section "bss"  class_bss  alias ".bss"

struct person
name rq 1
age rq 1
ends

struc literal
header rb 1   ;dq ?
ends

.entry _start

.data
align 16
tst db "test",0
test db "tst",0 ;<--If I change test to tt works fine

align 16
_name0 person {
name = tst
age = 10
}

align 16
_name1 person {
name = test
age = 20
}

myheader literal {
header = "E" ;<--**Can not take string here: "E", but hexadecimal values are OK
}

.text
_start:
mov rax,_name0
mov rax,_name1
mov rdi,0
mov rax, 60
syscall
 
/*
sol_asm2 struc0.solasm struc0.o -elf64
ld -m elf_x86_64 -o struc0 struc0.o
rm struc0.o
*/
Again, thanks Sir.

----edited---
On code below appears that it's happening an avalanche on structure. Code below needs glib and libc libraries, but if you assembly probably the same error happens to you.

Code: [Select]

.use64
section "text" class_code alias ".text"
section "data" class_data alias ".data"
section "bss"  class_bss  alias ".bss"

struct GSList
data dq ?
next dq ?
ends

struct person
name dq ?
age dq ?
ends

;include g.inc
extern g_list_append lin64
extern g_list_first lin64
extern g_print lin64
extern g_slist_length lin64
extern g_slist_append lin64
extern g_slist_free lin64
extern g_slist_prepend lin64
extern g_slist_remove lin64
extern g_slist_remove_all lin64
extern g_slist_last lin64
extern g_slist_nth lin64
extern g_slist_nth_data lin64
extern g_slist_next lin64

;include c.inc
extern exit lin64

.entry _start

.bss
align 16
list rs GSList,1
;list rq 1

align 16

.data
align 16
one db "one",0
align 16
two db "two",0
align 16
three db "three",0
align 16
now db "The list is now %d items long",10,0
align 16
last db "The last item is '%s'",10,0
align 16
item db "index %d have string %s",10,0

align 16
avatar db "mineiro",0
align 16
pseudo person { avatar , 10 } ;<-comment this line and works fine

.text
_start:
  xor rax,rax
  mov [list.data],rax
  mov [list.next],rax
  invoke g_slist_length,[list.next]
  invoke g_print,now,rax
 
  invoke g_slist_append,[list.next],one
  mov [list.next],rax
  invoke g_slist_prepend,[list.next],three
  mov [list.next],rax
  invoke g_slist_append,[list.next],two
  mov [list.next],rax
  invoke g_slist_prepend,[list.next],three
  mov [list.next],rax
  invoke g_slist_prepend,[list.next],three
  mov [list.next],rax
  invoke g_slist_append,[list.next],two
  mov [list.next],rax
  invoke g_slist_length,[list.next]
  invoke g_print,now,rax

  invoke g_slist_remove,[list.next],two
  mov [list.next],rax
  invoke g_slist_length,[list.next]
  invoke g_print,now,rax
 

  invoke g_slist_remove_all,[list.next],three
  mov [list.next],rax
  invoke g_slist_length,[list.next]
  invoke g_print,now,rax

  invoke g_slist_last,[list.next]
  invoke g_print,last,[rax]

  invoke g_slist_nth,[list.next],1
  invoke g_print,item,1,[rax]

  invoke g_slist_nth_data,[list.next],0
  invoke g_print,item,0,rax

;invoke g_slist_next,[list.next],0
  mov rax,[list.next]
  mov rax,[rax+GSList.next]
  invoke g_print,item,1,[rax]

  invoke g_slist_free,list
  invoke exit,0

/*
sol_asm2 gslist1.solasm gslist1.o -elf64
ld -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -L/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu -lglib-2.0 -lc -o gslist1 gslist1.o
rm gslist1.o
*/


[bogdanontanu]

Yes, I will check this too

[bogdanontanu]

Hi mineiro,

There is a new version here:
http://www.oby.ro/sol_asm/files/sol_asm_2016_08_01_v36_34.zip

It fixes a lot of relocations issues for ELF64 / Linux

[mineiro]

Thank you sir Bogdan.
Downloading sol_asm now.
Be in peace brother.

[mineiro]

Hello, it's meeeee   
Well, new issues Bogdan.
I'm not on my computer so can't send a source code testcase, but, I was looking for encoding of some instructions, can you check?
mov rax,[r12]
I have tried with others registers too like r13,r14,15 and same problem.

I think this other issue is relocation but on data section I have created 5 variables, like
 one db 'one',0
going to five.
After I create a reference of these variables as pointers, like
pointers dq one,two,three,four,five
The issue appeared like below:
szpointers dq (($-pointers)/8)
It's generating on passes correct value but on execution not.

Oh ye, I remember other think, you know when we are subclasssing on Windows O.S., so we offer as a parameter of a function the procedure that will deal(handle) with that manipulations? Well, this procedure is inside same code ok. I don't have tried this on windows, only on linux, but, if we make a reference to that procedure as being outside source code (like extern) it does not work. An pseudo example can be:
invoke hash_function,mystring1,mystring2,strlen
So, I'm talking about that strlen function as parameter, but not strlen writed by me, instead this, strlen that O.S. offers inside .dll
An other pseudo example
invoke myfunction,MessageBoxExa, ... .
This remove overhead on code. This happens on fastcall calling convention.

Thanks.

[bogdanontanu]

Hi mineiro,

I will check this also

[mineiro]

Thanks.

You have said on other topic about ideas to be implemented on linux side, well, I have some ideas.
On windows side, sol_asm offers a way to import functions from dinamic libraries (.dll). DLL's are just MZ files being Pe,Pe+, ... , and this type of file depending how it's configured can generate .exe, .dll, .sys, .scr, ... .
On linux side and object file it's an ELF header, an executable it's an ELF header, a dinamic library it's an ELF too, a module (driver) too, just fields change. The only exception is a static library that is just a concatenated of object files. So, I think that sol_asm can have options to generate an executable or a dinamic library.

I have sucessfully created a dinamic library example using sol_asm, appears that 'public' and 'export' have same meanings, I'm still checking.
A suggestion is change lin64 to cdecl, and by checking command line (-elf switch) know if calling convention is to 32 or 64 bits. But it's just a suggestion. Linux have as solid base C language.

Again, 10x

[bogdanontanu]

Thanks.

You have said on other topic about ideas to be implemented on linux side, well, I have some ideas.
On windows side, sol_asm offers a way to import functions from dinamic libraries (.dll). DLL's are just MZ files being Pe,Pe+, ... , and this type of file depending how it's configured can generate .exe, .dll, .sys, .scr, ... .
On linux side and object file it's an ELF header, an executable it's an ELF header, a dinamic library it's an ELF too, a module (driver) too, just fields change. The only exception is a static library that is just a concatenated of object files. So, I think that sol_asm can have options to generate an executable or a dinamic library.

I have sucessfully created a dinamic library example using sol_asm, appears that 'public' and 'export' have same meanings, I'm still checking.
A suggestion is change lin64 to cdecl, and by checking command line (-elf switch) know if calling convention is to 32 or 64 bits. But it's just a suggestion. Linux have as solid base C language.

Again, 10x

Hi mineiro,

Yes those are good ideas.

In the short run I want to find most bugs and miss features of code or relocations generation for x64  / ELF64 / COFF64 because this part was less tested by me.

In the long run I plan to make sol_asm able to directly generate ELF32/64 executable and directly import from .SO on Linux 32/64 files just like sol_asm can do this on windows and PE32/64 files.

I also plan to make it able to link / import directly from static lib files and perform linking. I might also write a separate linker.

I was thinking to rename / alias "lin64" calling convention to "lnx64".
However I like to allow mixing of calling conventions inside the same file. This mixing is not very usefully in windows/linux where the ABI is enforced by the OS but it might be fun for my own OS.

I am not a big fan of lin64 or win64 x64 fastcall kind of calling conventions and I like to have options available

A -fpic kind of option is maybe also needed for easy .SO generation (or at least a warning that code is not position independent)

I guess that I will also need to add PLT and GOT handling in Linux.

[bogdanontanu]

I will also be interested to see how you generated a .so  file with sol_asm

[bogdanontanu]

Hi mineiro,

There is a new Sol_Asm version that fixes some of the issues with MOV reg,[r12] or MOV reg,[r13] issues
http://www.oby.ro/sol_asm/files/sol_asm_2016_08_13_v36_38.zip

[mineiro]

Hello sir Bogdan, thanks, I will test new version. This post is above old version ok.

I'm facing some problems when dealing with hll involving structures. I'm not being able to write to xmm register too.
I have a suggestion about procedures.
When calling a function, parameters are passed on registers, if parameters are bigger than 6 on linux64 or 4 on windows64, so on stack.
On entry of function we need something like 'shadow space' used on win64. I know we can use global variables or local variables, this is why it's just a suggestion.
If user don't need that stack frame (shadow space), he simple don't put arg inside function scope or just create a regular label.

Follows a code testcase:
issue.solasm

Code: [Select]

.use64
section "text" class_code alias ".text"
section "data" class_data alias ".data"
section "bss"  class_bss  alias ".bss"

;changed to suit as an example.
STRUC ETH_PACKET
    packet_ptr              dq      ?
    packet_id               dq      ?
    packet_mac_src          rq      16
    packet_mac_dest         rq      16
ENDS

STRUC ETH_DRV
    drv_id                  dq      ?
    drv_name                rq      128
    eth_status              dq      ?
    packets_buff            rs      ETH_PACKET,2
ENDS

sys_exit equ 60

.entry _start

.data
my_driver       rs      ETH_DRV,1

;on entry, [rsp]=argc, [rsp+8]=ptr argv1, ...
.text
_start:
;[shadow space]----------------------------------------------------
  lea rbx,[rsp] ;argc
  mov rbx,[rbx]
  invoke my_proc,56 ;cdecl calling convention
  lea rax,[rsp]
  mov rax,[rax] ;;being overwrited
  cmp rax,rbx ;are not same
;------------------------------------------------------------------
;[structures]------------------------------------------------------
    mov     rsi,my_driver
    mov     rax,[rsi + ETH_DRV.packets_buff.packet_id]
    mov [rsi + ETH_DRV.packets_buff.packet_id],5 ;ok
    .if qword [rsi + ETH_DRV.packets_buff.packet_id] == 5 ;<----- here, its generating cmp qword [rsi],5
    nop
    .endif
;------------------------------------------------------------------
  mov rdi,0 ;native, system calls calling convention
  mov rax,sys_exit ;end this program
  syscall

public my_proc ;helps while debugging, can be done to variables too
proc my_proc lin64 ;cdecl calling convention
arg arg1 ;sub rsp,8 only one argument, max is 6 because others are on stack
  mov [arg1],rdi ;<----- this, a shadow space to store this argument||parameter
;add rsp,8
  ret
endp

/*
sol_asm issue.solasm issue.o -elf64
ld -m elf_x86_64 -o issue issue.o
rm issue.o
*/
----------------------------------------------------------------------------------
Library have only exit (sair) function, command program will echo argc and argv. Please, this is just a test, I'm learning these things now, so, can have mistakes or errors ok.

sair.solasm

Code: [Select]

.use64
section "text" class_code alias ".text"

;export sair
public sair
.text
align 16
sair:
;mov rdi,0
mov rax, 60 ;sys_exit
syscall

/*
sol_asm2 sair.solasm sair.o -elf64
ld -m elf_x86_64 -shared -o libsair.so sair.o
rm sair.o
*/

command.solasm

Code: [Select]

.use64
section "text" class_code alias ".text"
section "data" class_data alias ".data"
section "bss"  class_bss  alias ".bss"

;windows.obj == linux.o
;windows.dll == linux.so
;windows static.lib == linux static.a
;windows.sys == linux.ko
;windows eol CRLF == linux eol LF == mac eol LFCR??? ;end of line
;windows eos 00 == linux eos 00 ;end of string
;windows cmd line path "\" == linux cmd line path "/" ;path delimiter
;windows .bat||.cmd == linux .sh (on linux is need set execution by typing "chmod +x file.sh)

;rbx,rsp,rbp,r12-r13-r14-r15 calle saved register, preserved between calls
;rdi,rsi,rdx,rcx,r8,r9 dont preserved across calls, (cdecl calling convention, xmm registers ignored into this example)
;r10,r11,rax temp registers, don't saved across calls
;rax-rdx first and possible second return values

extern g_print lin64 ;glib2 function
extern sair lin64 ;sair (exit) function inside libsair.so

.entry _start

.data
elementos db "argc%d is %s",10,0

.text
_start:

  invoke main,[rsp],addr [rsp+8]
  invoke sair,45 ;return value, can be obtained using "echo $?"

public main
proc main lin64 ;this will echo command line parameters
local argc,argv
    mov [argc],rdi ;so we can use these registers for free, they are stored on memory
    mov [argv],rsi
    mov ebx,1
    .while rbx <= [argc]
      mov rdx,[argv]
      mov rdx,[rdx]
      invoke g_print,elementos,rbx ;on family of print functions on linux will print numbers, so rax contain how much xmm registers are used
;it's a good pratice zero rax register for safety by 'xor eax,eax' (more quickly on my tests than 'xor rax,rax' or 'mov rax,0' or 'and rax,0')
      add [argv],8
      inc ebx
    .endw
  ret
endp

;command line below
; -L. == local path to be searched to find libsair.so
; all libraries on linux start with 'lib' name, so on command line while linking we only need (if path environment are ok) -lsair that means libsair.so
; -L == library path
; -I == include path (not used here), used by C .h headers

;doit.sh
/*
sol_asm command.solasm command.o -elf64
ld -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -L/lib/x86_64-linux-gnu -L/usr/lib/x86_64-linux-gnu -L. -lglib-2.0 -lsair -o command command.o
rm command.o
./command one two 3 4 5 ; echo $?
*/
You can change g_print to printf if your system does not have that library, change link switch -lglib-2.0 to -lc
I remember you write into some place about creating our own prologue and epilog macro, can you give some example?

I don't understand C language, so, I'm learning C by osmosis. I'm compiling and disassembling, after checking.
When I don't understand C .h headers, I get an example and full fill all structure variables and after do a dump while debugging to know sizeof members.
some usefull commands
;disassembler
objdump -d -Mintel command
objdump -s command
objdump -d -Mintel libsair.so
;lib dependecy
ldd command
ldd libsair.so
;data,functions, ...
nm command
nm libsair.so

while generating library we can append many object files like
ld -m elf_x86_64 -shared -o libsair.so sair.o other.o another.o ...
static libraries are build using 'ar' comand, I was not able to link using static library for a while, I know that I can extract specific object file inside static library (probably dependecy of variables, ... will be a trouble) but I like the right way.
Well, linux is open source, If I understand C language I will download C source code and study it, but I can't.