Linux support

[johnsa]

Hi all..

UASM 2.47 will be available tonight in repositories and download packages as all the work and tests are complete.
I've recently updated to Ubuntu 18.04 on my Linux machine to begin work on PLT/GOT support.

It appears the situation has gotten even worse than I originally suspected. Code which assembles, links and was working perfectly on 16.04 64bit now fails to run with various relocation type errors.
I believe this is entirely to do with the dynamic linker/loader and mandatory requirements of PLT and GOT now even in executables and not just shared libraries.

I'd love to start with a huge rant about WTF someone was thinking when they came up with this PLT/GOT thing..I honestly don't understand why it exists at all especially in 64bit. With RIP relative addressing, if one were to simply map a copy of a library into each processes address space there should be no need for any of this and the performance degradation and complexity it brings with it.
I fear all of this was to save a few Kb by only mapping the code and creating unique data for each library in the process. As for executables requiring this I'm even more bewildered as to it's existence.

In any case, however big a Piece of Sh1t I think it is, we need to support it and I wanted to start getting an open discussion going about it with those who are using Linux to come up with an implementation strategy.
I've also suggested to Nidud to get in on the conversation as I'm sure ASMC will be facing the exact same Linux issues, and given how similar the two assemblers are especially under Linux it would make sense to unify the strategy.

Thoughts welcome..

[GoneFishing]

Hello,

(I'm still using 14.04 on my old patephone  and "There's no place in /home" )

My only idea was ( now I've discontinued thinking about it !)  to develop custom linker/loader 
You may stop too
  permanently
  or
  till the happy insight

Cheers!

[KradMoonRa]

Hi,

I have stooped for a wile to try to test fPIE and fPIC link asm code, related some bugs found in gcc and clang. In favor for time necessary to get my hands on macros lib's for uasm integration.

Most of the time hasted compiling new releases of the gcc and clang to test the code, and I have get some info that is imperative both or one of the options with gcc or clang (-fPIC or -fPIE) at symbol link-time, to generate correct relocation's tables.

I have get some references about the problem here https://stackoverflow.com/questions/36968287/why-doesnt-gcc-reference-the-plt-for-function-calls, and here https://stackoverflow.com/questions/2463150/what-is-the-fpie-option-for-position-independent-executables-in-gcc-and-ld.

I remember that I only succeed to run the PIC test in ubuntu 18 with this gcc command at link time (SharedObjectLinkerName :=/usr/bin/g++ -shared -fPIC), this basically to linker create the addresses for the uasm object functions.

And also using:
SYSTEMV - default call-convention for new linux kernel releases.

And this:

Code: [Select]

option casemap:none
ifndef __x64__
.686P
.model flat
option stackbase:esp ; RSP or RBP are supported options for the stackbase.
else
.X64P
option stackbase:rsp ; RSP or RBP are supported options for the stackbase.
endif
option win64:15 ; 11-15 for RSP and 1-7 for RBP.
option frame:auto
No idea why i'm using this in ubuntu 18, but if I don't declare-it, I get some segment fault error's at runtime.

Not tested fPIE, I think the problem its the same and related to linux kernel standard's, not full implemented in older or bugged compiler's linker's.