General Category > Sol_Asm

writing to data or bss section variables

<< < (2/3) > >>

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

mineiro:
Hello, it's meeeee   :P
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:

--- Quote from: 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

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page