flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2 |
Author |
|
LocoDelAssembly 26 Sep 2006, 02:44
Seems that I'll never get it work, 4 hours trying, 4 hours!!!
Even using "-rpath /home/oem/Desktop/test/" doesn't work, throws "bash: ./shared-lib-test: No such file or directory ". My last attempt was this: Quote: root@athlon64:/home/oem/Desktop/test# ld -m elf_i386 -shared -o shared-lib.so shared-lib.o But I'm still geting the "bash: ./shared-lib-test: No such file or directory" message (but the file exists of course). Here the readelf -a shared-lib-test [edit] <Removed to improve screen space>[/edit] PS: Note that if I link statically I can execute shared-lib-test without problems (linking against shared-lib.o instead of shared-lib.so), but it's not shared in that case... [edit] Here the definitive sequence to get it work on Ubuntu 64-bit Dapper Drake (6.06.1 LTS) Quote: fasm shared-lib.asm Note that this is for testing, you have to follow a diferent procedure in order to install the shared library (check the link that Tomasz posted below). Regards [/edit] Last edited by LocoDelAssembly on 26 Sep 2006, 16:04; edited 1 time in total |
|||
![]() |
|
Tomasz Grysztar 26 Sep 2006, 07:33
The way you linked it, to execute the program correctly you have to run it like:
Code: /lib/ld-linux.so.2 --library-path . shared-lib-test Or better, link the test program like this: Code: ld -dynamic-linker /lib/ld-linux.so.2 -o shared-lib-test shared-lib-test.o shared-lib.so and then execute with command: Code: LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./shared-lib-test PS. See http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html for some info. |
|||
![]() |
|
LocoDelAssembly 26 Sep 2006, 16:15
Quote: PS. See http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html for some info. I read it yesterday but seems that I got it wrong... Using "ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o shared-lib-test shared-lib-test.o shared-lib.so" shared-lib-test works using /lib/shared-lib.so or /lib32/shared-lib.so and using "ld -m elf_i386 -rpath . -dynamic-linker /lib/ld-linux.so.2 -o shared-lib-test shared-lib-test.o shared-lib.so" works with ./shared-lib.so . No need to use LD_LIBRARY_PATH in both cases ![]() Thank you a lot!! PS: I edited my previous posts [edit] Tested in the 32-bit version, works too [/edit] |
|||
![]() |
|
Tomasz Grysztar 26 Sep 2006, 18:49
Strange news: I don't know how it was actually working, but I discovered that there was a bug that caused the generated code to be not really PIC. [Maybe ld can make shared library even from non-PIC code, by choosing some random fixed base address for it? That needs investigating.]
I fixed the bug and added the PLT operator at the same time. You use it just like: Code: call PLT printf to call the external procedure via PLT. You can also do something like: Code: extrn 'printf' as _printf printf = PLT _printf and be able the to simply call the "printf" label, while assembler will make this call work through the Procedure Linkage Table. Well, it appears I have to rewrite the first post with more information how to get this all working. A new thread perhaps? |
|||
![]() |
|
LocoDelAssembly 26 Sep 2006, 19:29
aaahh, I forgot to tell something more, using "objdump -D shared-lib-test" I saw that it resolves using the same technique that MASM uses when you call an API (calling a jmp). However the jmp is not a "jmp dword ptr" like MASM but a "jmp rel32".
Do you mean that or I'm still getting it wrong? ![]() [edit] I just found this http://www.iecc.com/linker/linker10.html . Nice explanation [/edit] |
|||
![]() |
|
Tomasz Grysztar 26 Sep 2006, 20:38
No, it was about relocations in shared-lib.o, not shared-lib-test (and the latter is created by ld and not fasm, anyway).
|
|||
![]() |
|
FlashBurn 27 Sep 2006, 06:21
Thanks, I now will have a deeper look into the elf specifications and will see if I will get shared library support for my os working!
|
|||
![]() |
|
pelaillo 29 Sep 2006, 22:50
Quote:
Now I understand why a PIC version of my example (posted here) wasn't working. I arrived nowhere and then move the focus away. Maybe is time to fix it. ![]() |
|||
![]() |
|
LocoDelAssembly 07 Aug 2008, 00:26
Tomasz Grysztar wrote: Well, it appears I have to rewrite the first post with more information how to get this all working. A new thread perhaps? Could you? Because: Code: format ELF section '.text' executable public main extrn printf main: push msg call PLT printf add esp, 4 ret msg db "Hello World", 0xA,0 ;---- ;flat assembler version 1.67.28 (16384 kilobytes memory) ;libcdemo.asm [10]: ; call PLT printf ;error: invalid use of symbol. PS: Note the incorrect version number 1.67.28 |
|||
![]() |
|
Tomasz Grysztar 11 Nov 2008, 13:50
It's going to be fixed finally in 1.67.29.
|
|||
![]() |
|
reyuki 26 Jan 2025, 08:38
is there a PIC example for ELF64?
I tried to create a shared library of this code: Code: format ELF64 SYS_write = 1 STDOUT_FILENO = 1 section '.text' writeable executable public print print: mov eax, SYS_write mov edi, STDOUT_FILENO mov rsi, buff_ptr mov edx, buff_len syscall ret buff_ptr db "Lorem ipsum", 0xa buff_len = $-buff_ptr however, the linker complain it must be "position independent code", and it's first time I heard about it: Code: $ ld -shared shared-lib.o ld: shared-lib.o: relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC ld: failed to set dynamic section sizes: bad value I think the error occurs because the buff_ptr used in the print for some reason is 0x0 instead of its actual address/offset (is this how .o file behave? if I specify it as executable file in the format directive, it doesn't behave like this), and it seems make it PIC will somehow resolve the 0x0 address issue? |
|||
![]() |
|
bitRAKE 26 Jan 2025, 08:58
Using "lea rsi, [buff_ptr]" would make the reference RIP-relative, and hence the code would be position independent. Prior the reference was an absolute address - which would require relocation or a fixed address.
|
|||
![]() |
|
reyuki 26 Jan 2025, 09:19
Ah I see, thanks for the explanation!
so, when I instruct fasm to generate executable it will use absolute addressing and thus its reference address is fixed, while I instruct fasm to just generate object file it will leave the reference address to 0x0 to tell the linker that its value need to be relocated for obvious reason. hopefully I understand it properly. I'll link some sources that also helped me while I'm confused with this new stuff: - stackoverflow - other thread on this forum Last edited by reyuki on 26 Jan 2025, 09:43; edited 2 times in total |
|||
![]() |
|
revolution 26 Jan 2025, 09:22
fasm doesn't change the output. If you use lea for a code address in 64-bit mode then fasm uses RIP-relative addressing. This is always the case regardless of the output format chosen.
|
|||
![]() |
|
bitRAKE 26 Jan 2025, 09:23
Your understanding is correct. Although, I believe fasm can also emit relocation information for ELF executables - I haven't looked into it specifically.
|
|||
![]() |
|
Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.