| Re: [hatari-devel] Support for loading GNU-style symbols from a.out executables |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 11/09/2017 03:17 AM, Thorsten Otto wrote:
On Donnerstag, 9. November 2017 00:50:05 CET Eero Tamminen wrote:
The section address can be determined only when the program is loaded
Yes, of course. But the output of the tool should at least be consistent,
either section based, or all text-based. I think this is currently not the
case.
I've changed this, all the symbols output by gst2ascii are now TEXT
relative. That way one needs to give only TEXT offset to symbols
command when loading symbols from ASCII file generated by gst2ascii.
I also don't know how to produce an executable with GST symbols that are
text based to test that, maybe that is only possible with some other linker.
I've seen different VBCC/Vlink versions with different behaviors.
That might be bug though, as initially Vlink supported a.out and
DRI/GST support was later addition.
You can know that only after OS has loaded the program.
Actually, for atari, not. You can't load atari programs other than with
continguous text/data/bss sections.
I checked Compedium and indeed I should have remembered that.
There is no relocation information that would tell you which instructions
have to be patched. I've seen lots of programs that use pc-relative
addressing in the text segment to addresses defined in the data segment.
That can only be done if the pc-offset is already known at compile time,
or the instruction is changed when loading the program using some
relocation information, which is not the case for Atari.
Right, good point.
or would it be within spec if OS would put them into wildly different
addresses.
Thats only possible if both the file format and the OS are supporting this. For
gemdos executables, this is not the case, since the relocation information
only allows to relocate absolute addresses.
There are fields in the a.out header that would allow to do so (the a_troffset
and a_droffset), but those are not written by our a.out-mintprg binutils
format, and are also not used by gemdos Pexec() (they are still present in the
object files, and are used by the linker to perform the calculations mentioned
above, but not in the final executable).
So unless some program uses a propietary format, some custom linker to produce
it, and some custom loader, there is no way to load gemdos executables with
sections at arbitrary addresses. One of the reasons which makes implementing
real shared libs for atari almost impossible.
Now that Hatari supports MMU, I assume one could run also Linux
under it. Linux uses nowadays ELF for dynamically loaded libs,
but I assume a.out is still supported too. Supporting Linux
a.out binaries would need few additional changes in Hatari
debugger though. :-)
- Eero