On Tue, Oct 25, 2016 at 10:14 PM, Vincent Torri <vincent.to...@gmail.com> wrote: > On Wed, Oct 26, 2016 at 6:42 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: >> On Wed, 26 Oct 2016 04:50:54 +0200 Vincent Torri <vincent.to...@gmail.com> >> said: >>> On Wed, Oct 26, 2016 at 2:17 AM, Carsten Haitzler <ras...@rasterman.com> >>> wrote: >>> > On Tue, 25 Oct 2016 14:32:29 -0700 Cedric BAIL <cedric.b...@free.fr> said: >>> >> On Mon, Oct 24, 2016 at 10:31 PM, Carsten Haitzler <ras...@rasterman.com> >>> >> wrote: >>> >> > On Fri, 21 Oct 2016 15:14:20 -0700 Cedric BAIL <cedric.b...@free.fr> >>> >> > said: >>> >> > >>> >> > i've been mulling this. i followed the feedback so far. basically 2 >>> >> > main >>> >> > things: >>> >> > >>> >> > 1. this is intended to improve performance. especially startup times. >>> >> > 2. this is highly problematic in terms of portability and is going to >>> >> > create lots of code and build paths. >>> >> >>> >> It won't create lots of code and build paths. In fact it doesn't even >>> >> need two build paths. It just needs to uses all .la files for building >>> >> quicklaunch and can be rolled in, in parallel to current system. Just >>> >> the link of the quicklaunch binary would be different. Next step would >>> >> be to make a build option that setup symlink to that binary. Finally >>> >> that option would be the default, likely only afffecting the install >>> >> process. I don't think that create a lots of code (There should be no >>> >> code change) and build paths change at all. >>> > >>> > why are you doing a symlink if its JUST a quicklaunch binary change (that >>> > statically compiles all of efl into it)? >>> > >>> > you are trying to replace all of libevas.so.1, libeina.so.1, etc. with >>> > symlinks TO this quicklaunch binary ... to retain binary compatibility. >>> > you >>> > cant have the .so's AND this ql binary both have the same set of symbols. >>> > asking for trouble there. >>> > >>> > but to USe this binaries HAVE to be PIe and this makes for a non-portable >>> > pain in the arse of creating apps. which is why i did .so's for >>> > quicklaunch >>> > before.. because it also works with dll's on windows. PIE does not. not >>> > that i could find. >>> > >>> >> > 3. this makes debugging and other things a nightmare (ps names are all >>> >> > the same .. well depending on tool etc.) >>> >> >>> >> This is exagerated. Again just need to pass the right command line to >>> >> ps/top and problem is solved. Can easily be documented and we can also >>> >> provide a script that does it until we provide some nicer application >>> >> there. >>> > >>> > i mean simple user debugging. someone runs ps or top and all they see is >>> > 20 >>> > processes called "quicklaunch". because depending on the ps tool it may >>> > use >>> > one proc field or another. so a user goes "quicklaunch process is using N% >>> > cpu or N % ram". what real process is that? they don't know. because >>> > procps >>> > tools will not do what you want and thus the average person will become >>> > confused and find anything using efl like this to be horribly hard to work >>> > with. >>> > >>> > if top, htop, ps, killall, etc. don't work out of the box, it isby >>> > everyone >>> > (except yours) definition... a nightmare. i've messed with this before and >>> > it does not work across all the tools because of where they source command >>> > (and that can change based on config and cmdline options too). >>> > >>> >> > 4. generally the issue of complexity in our build requires for >>> >> > portability etc. >>> >> > >>> >> > #4 isn't something we can solve right now, but has a better solution if >>> >> > #we go >>> >> > for a greater internal redesign. but not today. some other day. we have >>> >> > to live with what we have right now. >>> >> >>> >> Hum ? How ? I don't see how we can have good portability without a >>> >> complex build system. Would be interested to know more by what you >>> >> mean here ! >>> > >>> > we can isolate the portability layers in a much smaller area and always >>> > provide a portable interface wrapped on top of the real os one. currently >>> > our portability code is scattered all through efl. it's not in one place. >>> > by >>> > merging it into one location we'll be able to simplify it too so in the >>> > end >>> > we just have some "efl port sys" lib that provides an "always works" set >>> > of >>> > library calls and everything above that is 100% portable and never changes >>> > platform to platform. >>> > >>> >> > i am always for improvements. but this really makes this method a very >>> >> > very very hard ask to do this. i've thought about it and i think this >>> >> > is >>> >> > far TOO radical a change as it means different execution methods, >>> >> > library >>> >> > production, linking and so much more os by os. it's kind of insane >>> >> > though >>> >> > theoretically doable on *nix. i've checked and PIE seems to be urtterly >>> >> > unportable (windows can't do it based on my reading). the proposal >>> >> > would >>> >> > be workable ONLY if we could do it unversally so it wouldn't bitrot and >>> >> > it'd work. this is actually why quicklaunch did .so's instead of PIE >>> >> > because that WORKS portably.... >>> >> >>> >> Windows is anyway another platform with a lot of specificity. >>> >> Quicklaunch will never work there as there is no equivalent to fork >>> >> anyway. Emulating what PIE allow is also mostly impossible as >>> > >>> > actually it does work. fork works. it's emulated and expensive, bit it >>> > WORKS. it means you have an already "partially launched" app around. if we >>> > had a fork POOL sitting around "ready to go" and they get ipc'd the >>> > command >>> > to run... it'd work the same on windows and on *nix. it'd be faster on >>> > both >>> > because when an app runs, the init/liking phase is already done by a >>> > process that is sitting as a hot spare ready to go. >>> > >>> > so ql dlopen()'s the apps' DLL (as now it has to be a dll and not an exe) >>> > and the app is basically a loadable module. and loadable module dlls WORK >>> > on >>> > windows. >>> >>> i don't know if it can help, but i can load an exe, which has exported >>> symbols in it, in memory with LoadLibrary(), then I can call the >>> exported functions >> >> you can? i looked for ages for PIE -fPIE + windows and found nothing. >> executables are different to binaries at least on *nix where a normal exe is >> not relocatable. a PIE one is. shared libs are PIC to be relocatable in >> memory. >> ASLR relies on relocation. are exe's on windows always relocatable? if so >> then >> loadlibrary on any exe would work and then symbols exposed (cdecl) can be >> found >> of course. but i found nothing about this in my googling. > > maybe what you should have searched for is "rebasing", and not "relocation" ? > > PE files (DLL and exe, which only differ by one bit) are usually > loaded (or mapped) at a prefferred address in memory. if DLL's of a > process are overlapping, the kernel rebases them. Usually, the linkers > are smart enought to avoid this. > > but you can also tell the linker to specify the base address where the > PE file is mapped. In the PE files, all the addresses are relative to > that base address.
I found information about this while looking for ALSR (which implies you need to be able to relocate your binary and every OS is going there). But what I read was stating that even if you can loadlibrary an ALSR binary, you can just fetch data and shouldn't run code as some part may not be initialized correctly as library and binary have different initialization path on Windows. Is it because we only have C library that it will work ? Or is there something special to do ? -- Cedric BAIL ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
