I think I understand, that the loading of elf files differs form the standard, is because of the fact that calling m68k should/must work, for normal executable. And the same loading behavior is applied to sobjs. And to workaround that .plt and .text section gets ripped apart, the solution is to have .rodata in its own segment.
But must sobjs loading actually be handled like normal executable? Of course it is easier to have the same loading code for both.
What I'm thinking of is, if it is possible for an sobj to have any m68k code? Sobjs are for ppc only, so the only way to "include" m68k code is to call it. In the Migration Guide are all? cases listed how to call m68k code:
* m68k library: needs generated stubs, which are realizes as separate disk-resident file. So no m68k code in the sobjs * m68k Hook function: Theoretically possible, but why should I setup an m68k hook, if I currently developing for ppc. Maybe only used in a bizarre scenario * m68k interrupts: Same as m68k hook. Why use m68 code, if developing happens on ppc * calling emulator: Probably use case, which can happen. But the m68k code would normally be loaded from another file and not be as read only data. In later case the developer could just again use ppc instead of m68k during development.
I think, there aren't any sobjs files having m68k code. And if there are some, than they are very rare and probably do other stuff, which isn't correct programming. I would like to know if someone can prove it wrong. Because if this assumption is valid, sobjs could just be loaded as described by elf. No special handling of .rodata is needed.
On the other hand, the question must be answered if it worth the effort to have two loading mechanism in the elf.library, and if the elf.library knows if its loading an sobj file. If the later is not possible, this all is just an mind game.
2) It doesn't - the .rodata issues affects all binaries. It's just that the solution used for non-dynamic objects cannot be used for dynamic objects (otherwise 24-bit PC-relative jumps in .plt could be out of range, resulting in ISI crashes, which was the case with some of alfkil's elf.library changes, which I have since fixed - I experienced this with the example code that you sent me, which can manifest itself as seemingly random crashes depending on whether .plt ended up in memory in range of .text or not).
Sorry for probably asking the same and the same again, but just to sort everything till death :
If you say that .rodata issue can happen and with .so and with pure binaries, then, why old (current) bintuils in adtools, do put .rodata together with .text for pure binaries, and doing it correctly to put .rodata as separate segment when it comes to handle sobjs ?
I mean, what reassons for that ? It looks like then that elf.library have 2 mechanism of binaries loading : one for pure binaries (where it possible to have .text and .rodata in one segment) and one when you load .so, where it not possible to have .text and .rodata in one segment. That correct ? 2 different pieces of code for 2 different scenarios ?
But then, why there were 2 different ways done at all ? For what benefits ? Why not make .rodata be separate for both types of binaries, and be done with it ? Simple code, simple understanding, everything the same for both types, no "wtf". Or there is some real benefit to have 2 different ways of handling .rodata thing ?
Another reason .rodata should be separated from .text (and .plt) is the way (non-)execuable memory is allocated in AmigaOS 4.x. At least on some CPUs you can't change it after allocation from executable to non-executable, or the other way round. While it doesn't cause problems directly in PPC-only code, without m68k cross calls/EmuTraps, having executable .rodata (const data, strings, etc.), which would be the result of loading the complete section with .text, .plt and .rodata at once, would be a bad idea.
Quote:
* m68k Hook function: Theoretically possible, but why should I setup an m68k hook, if I currently developing for ppc. Maybe only used in a bizarre scenario
If you are developing a PPC library (AmigaOS foobar.library, not libfoobar.a or libfoobar.so) which also exists in a AmigaOS 3.x/m68k version and uses Hooks you will get m68k Hook functions from AmigaOS 3.x/m68k executables using the PPC version of the library on AmigaOS 4.x. The same is theoretically possible for m68k interrupts as well, but unlikely to be used.
But 680x0 programs don’t use .so files, nor do they compile with powerpc .a files. So why is important how 68K had allocated memory, as long as its shared, so it can be used in treads.
and wont it be loadseg job to load 68k programs, not elf loader, unless we are going to add aros 68k binary support any time soon.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Another reason .rodata should be separated from .text (and .plt) is the way (non-)execuable memory is allocated in AmigaOS 4.x. At least on some CPUs you can't change it after allocation from executable to non-executable, or the other way round.
So the best solution would be to always have .rodata section in its own segment , regardless of the type (executable, sjobs). This the elf.library allocate straight a head memory as described by the segments. No fancy splitting needed. And sjobs works, too.
Quote:
If you are developing a PPC library (AmigaOS foobar.library, not libfoobar.a or libfoobar.so) which also exists in a AmigaOS 3.x/m68k version and uses Hooks you will get m68k Hook functions from AmigaOS 3.x/m68k executables using the PPC version of the library on AmigaOS 4.x. The same is theoretically possible for m68k interrupts as well, but unlikely to be used.
Yes, but in this case I‘m not developing a sobj, but a foo.library. Which again doesn’t have a .plt section. So no m6ik code in sobj. BTW can foo.library use sjobs ?
Yes, but I don't know if that was ever used. Except for me, and maybe @Futaura, just testing if it's working. At least I never publicly released such a foo.library using sobjs, and even it was used in a publicly available foo.library it's probably a very rare case you can ignore.
It looks like then that elf.library have 2 mechanism of binaries loading : one for pure binaries (where it possible to have .text and .rodata in one segment) and one when you load .so, where it not possible to have .text and .rodata in one segment. That correct ? 2 different pieces of code for 2 different scenarios ?
The first thing that happens is that the program headers are loaded and normally each segment is then loaded in its entirety. Only if an executable segment contains a .rodata section will that segment be handled differently (the segment is not loaded, but instead it is deferred - when a section from that segment is required, that section is then loaded into a separate block of memory). It had to be done that way for all the reasons given.
Quote:
But then, why there were 2 different ways done at all ? For what benefits ? Why not make .rodata be separate for both types of binaries, and be done with it ? Simple code, simple understanding, everything the same for both types, no "wtf". Or there is some real benefit to have 2 different ways of handling .rodata thing ?
@MightyMax
Quote:
So the best solution would be to always have .rodata section in its own segment , regardless of the type (executable, sjobs). This the elf.library allocate straight a head memory as described by the segments. No fancy splitting needed. And sjobs works, too.
Yes, probably - maybe there is a good reason as to why not, but from first glance I can't see why it would cause any harm, other than increasing the size of the binary, a little. Why did the old binutils not do this? You'd have to ask whoever decided that. Probably nobody thought this would be an issue at the time, when OS4 did not support sobjs at all.
As I mentioned, the 68k cross calls in early code will have been put in .data (as that's what fdtrans originally did) and if it stayed that way there wouldn't have been any of this mess with .rodata. Presumably switching from asm to C for the cross calls influenced them ending up in .rodata instead of .data (mimicking what idltool had been doing since day one). Again, at that time (2005) probably sobjs did not exist in OS4, so nobody could foresee this being an issue.
Obviously, there will never be getting away from elf.library handling .rodata in 2 different ways, as old binaries will always have to be supported, no matter if newer ones put .rodata in a different segment.
I tried my best to get everything correct. Anyone discovering typos, faults, just plain wrong information, in that document is welcome to correct it. Eitehr as PR, or here in this thread, etc.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
