Recent Posts

Pages: [1] 2 3
1
General Discussion / Re: Olavo de Carvalho
« Last post by bogdanontanu on April 21, 2017, 09:33:36 PM »
Hi  mineiro,

Yes I am ok, thanks for asking.
Just a lot of work and study as you can guess.

Thanks for the hint. I will check him if I have the time ;)
2
General Discussion / Olavo de Carvalho
« Last post by mineiro on April 20, 2017, 11:44:29 PM »
Hello sir Bogdan, I hope you're fine, well, a long time without post, I suppose that you're studying a lot.
I'm just posting this to tell you about sir "Olavo de Carvalho", he's a brazilian philosopher, writer and journalist, and years ago he was on your land, RomÍnia.
Maybe you can have interest on their publications, and you can also find their passage on your country too.
He's the type of guy that read 80 books per month, like a guru you know. He opened my eyes to many situations, including how the world is now.
hugs.
3
Sol_Asm / Re: The LARGEADDRESSAWARE option
« Last post by bogdanontanu on September 26, 2016, 11:28:25 PM »
Hi Vortex,

Yes, I will add this option

Thank you for the attached example ;)
4
Sol_Asm / The LARGEADDRESSAWARE option
« Last post by Vortex on September 17, 2016, 07:39:47 PM »
Hi Bogdan,

Could you add the LARGEADDRESSAWARE option to SolAsm? It's about the GlobalMemoryStatus API function to report the correct memory status :

Quote
If the executable is linked using the /LARGEADDRESSAWARE linker option, then the GlobalMemoryStatus function will return the correct amount of physical memory in both members.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa366586%28v=vs.85%29.aspx

Attached is an example project.
5
Sol_Asm / Re: writing to data or bss section variables
« Last post by mineiro on August 13, 2016, 10:57:06 PM »
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.
6
Sol_Asm / Re: writing to data or bss section variables
« Last post by bogdanontanu on August 13, 2016, 05:44:39 PM »
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

7
Sol_Asm / Re: writing to data or bss section variables
« Last post by bogdanontanu on August 13, 2016, 09:50:24 AM »
I will also be interested to see how you generated a .so  file with sol_asm ;)

8
Sol_Asm / Re: writing to data or bss section variables
« Last post by bogdanontanu on August 13, 2016, 09:36:44 AM »
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.

9
Sol_Asm / Re: writing to data or bss section variables
« Last post by mineiro on August 12, 2016, 04:50:08 AM »
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
10
Sol_Asm / Re: writing to data or bss section variables
« Last post by bogdanontanu on August 11, 2016, 09:31:02 PM »
Hi mineiro,

I will check this also ;)
Pages: [1] 2 3