My aim is to load and relocate two executables into a single, allocated memory area. The information I've found in my old RKMs, AmigaDOS manual, google and elsewhere doesn't provide enough detail for me so I'm asking here.

First, understand that this will only work for m68k executables. See the InternalLoadSeg autodoc. You need to provide a function array.

First pointer is to a function to read data from the filehandle. It is given arguments similar to dos.library/Read(). Next are the allocation and free functions. These are the functions you need to hack. Basically you need to make your own functions that work on the single allocated memory area. You could use Allocate() and Deallocate() on your custom MemHeader for instance.

Under MorphOS you likely want to use struct EmulLibEntry gates to pass the control to PPC native functions.

The call itself will appears as:
Code:

Note that at InternalUnLoadSeg you must pass a pointer to the same free function!

I don't have any C example code at hand right now, but if m68k assembly will do, check BlizKick source code.

[ Edited by Piru on 2011/1/25 11:08 ]

Thanks for that. But I'm only interested in PPC executables and I thought InternalLoadSeg() would have been a much better solution than the work-around I'm considering... I've had no trouble using LoadSeg() with PPC programs so I figure first, allocate a 16MB block of memory, go through the remaining memory list and allocate everything, release the first block and then just use LoadSeg() to get those two executables into the same space. Not nice but it'd probably work.

Quote:
Loading ELF executables requires seeking, something which InternalLoadSeg doesn't provide.

Quote:
While extremely hacky, in theory this should work, assuming you use the proper API to query the free memory areas (SYSTEMINFOTYPE_FREEBLOCKS).

However, I still wouldn't recommend this.

May I ask why is it necessary to load two executables like this?

I've started writing an assembly debugger that uses a branch instruction as a breakpoint. Currently the debugger and debugee (?) are modified with a different pair of branch instructions for each debugee instruction that gets single stepped. So far I just have a limited proof of concept and, the few times I've loaded an external program as the debugee, I've just been lucky that it's been in the 16MB range of the branch instruction.

I know that either the LR or CTR could be used to branch anywhere in memory but the debugee may want to use those registers and working around that seemed like it would get messy. Moreso...

To be honest, when I came up with this approach, I'd lost sight of the fact that modern systems have so much more memory than classic Amigas. But I figure that a debugger that's limited to working with programs that fit into 16MB is better than nothing.

I am currently 16000km away from my source code but for OS4Emu I wrote my own ELF loader to handle OS4 executables. It is messy approach but gives you more freedom to work with the data. IIRC it was wrapped around InternalLoadSeg() but it was only done to get automatic SegTracker support for loaded programs. But my memory is very hazy about this since I havent looked into this code for years.

I even went so far I wrote small mini-PPC emulator since I had to follow some branch instructions... it worked quite nicely :)

If you wish to go for your own ELF loader I can dig out source code to you when I am back in Finland (three more weeks in a paradise!).

I'd be interested in that - before I actually started this project I was thinking along the lines of a custom ELF loader. But it sounds like InternalLoadSeg() can do more than just work with 68k programs. I've had an email response from someone else on this topic and they provided some source code so I've got a new round of experimentation ahead to find out what the possibilities are.

After a bit of inspiration and thought I may have a better approach to branching into a debuggee program. I'm pretty sure the debugger can do without having to load the debuggee to a particular address. Rather, the debugger could let LoadSeg() do it's job but then allocate some memory (one or two KB) within a 32MB vicinity of the .text or code segment of the debuggee - the closer the better. I know there is an AllocAbs() function but I don't know how to determine if a particular address / block is free before trying to AllocAbs(). How is this done?

edit: Re-checking replies to previous questions... I think I know the answer. Also found where the MemList is too.

[ Edited by ausPPC on 2011/3/9 11:08 ]