Re: [hatari-devel] Symbol loading for upcoming MINT+ELF program format

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi Thorsten,

Thanks, I merged this along with additional commits fixing invalid memory access crash and formatting for earlier code.

Vincent, could you try whether it works for you, as I do not have any test binaries?


	- Eero

On 29.8.2023 13.23, Thorsten Otto wrote:
On Montag, 28. August 2023 22:41:13 CEST Eero Tamminen wrote:
Please use the same (linux style) formatting as rest of the file.

Ok. New version attached below. I have done that manually, so i hope i didn't
miss anything. If i've seen correctly, that only affects putting curly braces
on the same line as if/else etc?

BTW, there are other parts in the source (from my previous patches for a.out
and Pure-C) that also use a different style. Should those be fixed too?

Elf header processing in symbols_load_binary() is large enough that
contents for the "/* new MiNT+ELF */" block should be in a separate
function.

Hm, it's about the same as the extended a.out processing. And putting that
into a separate function is a bit troublesome, since it accesses lots of
locals from that function. And the compiler would inline that anyway again,
since it is only called once.

and keep only
generic parts in symbols-common.c (which e.g. includes the others).
Comments?

Hm, maybe. But the file is still not too large i think, splitting it would
make it more difficult to read.

NetBSD boot fails earlier than without it

Yes, it did not look into that again. It's difficult to see whats going on
without access to real hw. Unfortunately my try to use the serial port of the
falcon that i once sent to mikro didn't work either (the official version only
has support for the MFP serial)



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/