Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (joerg)

Bottom

(1) 2 3 4 ... 101 »

joerg

Re: SFS/02

Posted on: Yesterday 17:45 #1

Home away from home

@walkero
Quote:

I believe the SFS/02 cannot be used to boot from. Either use FFS or SFS/00

Booting requires support for the file system in 2 parts.

Firmware/SLB:
- SLB_v2 (AmigaOne SE/XE/µA1, Sam4x0) supports FFS and SFS, incl. SFS\2. Using back calls to U-Boot code some Linux (ext2fs?) file system as well for booting Linux.
- amigaboot.(ub|of) (X1000, X5000, A1222) supports FFS and SFS, incl. SFS\2, and AFAIK additionally NGF\0, but not NGF\1.
- SmartFirmware (Pegasos2) only supports FFS, not my versions of SFS (SFS\2 not at all, SFS\0 may or may not work, depending on if currently any of my improvements are in use on the partition, which can change on each reboot, i.e. it's random if booting works or not).
- SLB_v2 replacements like ACube's Parthenope (Sam4x0, no idea if it's usable with the very old U-Boot versions of the AmigaOne SE/XE/µA1 as well) only support FFS and Linux file systems, not my versions of SFS (SFS\2 not at all, SFS\0 only partially and randomly).
- On classic Amigas (A4000[T], A3000[T], A1200) the "Firmware/BIOS" for booting AmigaOS 4.x is AmigaOS 3.x, a compatible m68k AmigaOS 3.x version of the file system is required and has to be installed in the RDB. FFS and SFS are available, NGFS isn't.

AmigaOS 4.x:
Both my diskboot in old versions (Hyperion is no longer allowed to use it), and the replacement mounter.library in current versions, should work with any AmigaOS file system which is installed as a kickstart module.
Using disk based file systems (in L:) obviously can't be used for booting.

Topic | Forum

joerg

Re: clib2 vs newlib perfomance issues

Posted on: 7/1 16:48 #2

Home away from home

@kas1e
As I wrote several times already the I/O implementations, and several other parts, of clib2 are simply crap. IIRC even the libnix code was much better, at least for the quite limited parts it supports.

You only have 2 options:
- Re-implement all clib4 parts from scratch and remove any code from clib4, not only the I/O related parts, which were based on clib2 sources.
- Throw away the whole junk and restart from scratch, porting a usable C library like newlib, uClib, AROS C library, etc., (a glibc port is next to impossible, a NetBSD libc port way too much work, and my OS4 port of ixemul incomplete and too complicated to install for casual users...), instead.

If you have a snprintf() benchmark compare clib2, clib4, newlib, libnix, ixemul and IUtility->SNPrintf() results... Maybe additionally vclib (like libnix rather limited) using VBCC.
Except for clib4, which didn't exists yet, I had support for all 4 C libraries in my gcc specs file, and I used VBCC, or at least vlink, which at that time was much better than the binutils ld, for a lot of my AmigaOS software.

Topic | Forum

joerg

Re: Snork: New Tracing Tool for AmigaOS 4

Posted on: 6/29 15:22 #3

Home away from home

@kas1e
It's an absolute no-go to allocate memory in patched functions, no matter if you use C library (for example malloc()/free()) or exec library (for example AllocVecTags()/FreeVec)()) memory allocation and free functions:
It can break the Forbid() and Disable() states, cause priority inversion, endless loops (if you patch the memory allocation/free functions as well) as well as other dead locks.
You have to pre-allocate all memory required for the IPC before patching the functions, and only a single, pre-allocated memory buffer per patched function isn't enough either: The (patched) functions might be called by different tasks at the same time.

Topic | Forum

joerg

Re: Snork: New Tracing Tool for AmigaOS 4

Posted on: 6/27 15:00 #4

Home away from home

@msteed
Quote:

Of course, if the string pointer is invalid the function you're calling will probably cause a DSI itself as soon as you call it. Still, there's some value to Snork not causing the DSI, even if there's going to be one an instant later anyway.

Some functions may work with invalid string pointers, depending on other arguments the string pointer may not be used at all by the function itself and if it isn't accessed there wont be a DSI.
But Snork would cause a DSI trying to print it.

Topic | Forum

joerg

Re: Snork: New Tracing Tool for AmigaOS 4

Posted on: 6/27 14:34 #5

Home away from home

@kas1e
Quote:

strncpy(output, "NULL", output_size - 1); output[output_size - 1] = '\0';

= strlcpy(output, "NULL", output_size);

strncpy() and strncat() should be replaced by strlcpy() and strlcat().

Quote:

} else if (input[i] >= 32 && input[i] <= 126) { output[j++] = input[i];

Replace by


} else if ((input[i] >= 32 && input[i] <= 126) || (input[i] >= 160)) {

to add support for international chars, for example the default ISO 8859-15 ones.
Unprintable control chars on AmigaOS, in any supported 8 bit charset, are only 0-31 and 127-159.

Topic | Forum

joerg

Re: Snork: New Tracing Tool for AmigaOS 4

Posted on: 6/25 17:47 #6

Home away from home

@msteed
Quote:

A good deal of caution should be employed when displaying a string parameter. Since one of the uses of the program is debugging, you have to consider that in some cases string pointers may not be valid (illegal values other than NULL or -1),

Using a IExec->TypeOfMem() check could partially help: If it returns 0 it's not a virtual address mapped by the kernel, and accessing it will very likely cause a DSI exception.

Quote:

or may not point at a real NUL-terminated string.

Checking that isn't that easy, but possible as well.
Requires using such checks for each MMU page, if it's mapped or not. On most, or maybe all, OS4 systems the MMU page size is 4KB.

Topic | Forum

joerg

Re: Tracing of callhookpkt()/callhook() and varargs

Posted on: 6/25 15:05 #7

Home away from home

@kas1e
Quote:

Btw, what about Printf(), DebugPrintF(), etc ?

IIRC DebugPrintF() has everything internal and doesn't use other functions, the rest probably still ends in using IExec->RawDoFmt(), or once loaded the locale.library replacement of RawDoFmt() (with the additional features supported by ILocale->FormatString(): argument positioning, localized number formats, etc.).

Topic | Forum

joerg

Re: NULL, 0xFFFFFFFF and Exec: Real vs QEMU

Posted on: 6/24 17:21 #8

Home away from home

@broadblues
Quote:

It's not uncommon for a few special values for strings, we mainly get away with this due to the signed 32 bit memory space, so 0xFFFFFFFF will "never" be a valid pointer to a string.

That's not the case for AmigaOS 4.x anymore, it has an unsigned 32 bit, 4 GB address space.
I guess you are referring to the very strange, but on AmigaOS 4.x obsolete and no longer used, exec AllocEntry() function which did set bit 31 of the address on errors.
But even on AmigaOS 4.x a pointer to 0xFFFFFFFF (-1) or 0xFFFFFFFE (-2) can never be valid, even if something is mapped there (the A1 SE/XE/µA1 might have had something U-Boot related there), because accessing odd, and on some PPC CPUs even only 2 byte aligned, addresses for 4 byte/32 bit accesses are invalid and cause a CPU exception. Of course wrap arounds like the 0xFFFFFFF[EF]->0x0000000[0-2] one cause a CPU exception as well.

Topic | Forum

joerg

Re: Tracing of callhookpkt()/callhook() and varargs

Posted on: 6/24 15:39 #9

Home away from home

@kas1e
Simply only patch the non-varargs versions of the functions instead, in this case CreateNewProc()/CreateNewProcTagList() (not sure why there are 2 names for it, it may be the same?)
The varargs functions simply call the non-varargs ones, not only in dos but in all OS4 libraries.

In AmigaOS 1.x-3.x the varargs versions of the functions weren't included in the libraries yet, but in the compiler includes, as macro, inline asm, #pragma, etc. instead

Topic | Forum

joerg

Re: wb2filer v0.8

Posted on: 6/23 15:11 #10

Home away from home

@kas1e
As Georg wrote in the other thread you have to check for both NULL (empty title) and (STRPTR)~0 (don't change the current title) before trying to print the title text.

As for QEmu not crashing:
Maybe it has something mapped at (0xFFxy0000-)0xFFFFFFFF, for example an emulated PCI device your real hardware doesn't have, or maybe QEmu doesn't emulate all CPU exceptions with all special cases like this one (if interpreted as 32 bit value like STRPTR accessing 0xFFFFFFFF causes accesses to the bytes at 0xFFFFFFFFF, 0x00000000, 0x00000001 and 0x00000002), which is very likely as well.

Excessive debug output, if it's send to the serial port and not the memory debug buffer, might make the system fail because of timing issues caused by the delays of the serial I/O. For example using a debug kernel with debuglevel=15 or higher.
But just 20 lines/sec. shouldn't be able to cause problems.

Topic | Forum

joerg

Re: How to use clib4 (natively)?

Posted on: 6/22 9:55 #11

Home away from home

@Chris
Quote:

libnix is more sane but IIRC is missing quite a bit of stuff.

clib2 is preferable to both, especially as it's not trying to be UNIX.

Gunther's libnix doesn't try to be UNIX/POSIX compatible either.
Only ixemul did try that, incl. functions like (ix_)vfork(|2|_setup_child)(), etc. A vfork() implementation is partially possible on AmigaOS, with several restrictions, but implementing a fork() function is impossible on any version of AmigaOS.
libnix is a very simple and limited C library, enough for most native AmigaOS software, but not usable for porting UNIX software to AmigaOS.

Topic | Forum

joerg

Re: How to use clib4 (natively)?

Posted on: 6/22 9:17 #12

Home away from home

@kas1e
If you insist on using a crap single-system C library instead of something much better and multi-platform (doesn't have to be newlib, there are others, but less advanced ones, as well) at least merge clib4 with the AROS C library to get a few more developers on board.

Just browsed the clib4 sources a bit, and there is still a lot, way too much, crap from clib2 remaining.
Very simple example:
https://github.com/AmigaLabs/clib4/blob/master/library/stdio/lock.c
Just replacing the old, and probably only used for the AmigaOS 1.x-3.x compatibility of clib2, semaphores (based on Forbid()/Permit()!) by OS4 mutexes (based on atomic increment/decrement instructions) should result in a noticeable speed improvement.

Topic | Forum

joerg

Re: need clarify about libdl and all dlopen/dlclose calls

Posted on: 6/22 8:43 #13

Home away from home

@Hans
Quote:

EDIT: And the libdl.a on os4depot causes missing IElf symbol errors. Non-functional...

If elf.library support isn't included in libauto simply open it and the IElf interface yourself.
libdl.a is probably simply redirecting the functions to IElf->DLOpen(), DLSym() and DLClose().
But as I wrote it can only work for very simple shared objects/plugins which don't need to call functions from the statically linked main executable nor from statically linked libraries.

Topic | Forum

joerg

Re: need clarify about libdl and all dlopen/dlclose calls

Posted on: 6/21 19:20 #14

Home away from home

@Hans
Quote:

Removing libdl.a was a mistake.

No.
While it still might be possible to use dlopen(), etc. from libdl.a (or more directly IElf->DLOpen(), DLSysm(), DLClose() from elf.library) to load .so plugins, it's impossible for such .so plugins to call functions in the main executable on AmigaOS if the main executable wasn't build with -use-dynld.
For example the audio, video, PDF, etc. plugins of my AmigaOS 4.x port of OWB, only theoretically supported since nobody ever implemented those plugins, depend on back-calls of functions in the main executable.

Topic | Forum

joerg

Re: How to use clib4 (natively)?

Posted on: 6/21 17:45 #15

Home away from home

@flash
Quote:

The question is.. you have great skills and deep knowledge of AmigaOS internals, so I wonder why you don't join Andrea and others developers to build an open source alternative to all this mess?

Re-implementing an AmigaOS 4.x port of newlib: Not possible for me because of my contract and NDA with Hyperion.

clib2/clib4: Doesn't make any sense for me, clib2 was completely replaced by newlib (or at least should have been, according to my newlib contract).
Fixing the most serious bugs in clib2 and adding missing features, instead of porting newlib, would have been an option about 20 years ago, but the developer of clib2 rejected any improvements I suggested.
In the end I never used clib2 for any of my AmigaOS 4.x software, but ported and used libnix instead for all of my early AmigaOS 4.x software, before I did the newlib port.

Topic | Forum

joerg

Re: How to use clib4 (natively)?

Posted on: 6/21 17:01 #16

Home away from home

@balaton
Quote:

Why does it need to be reimplemented? Couldn't you just release it under a similar licence as the rest of newlib then others could update it without having to start from scratch.

My AmigaOS 4.x port of newlib was contract work for Hyperion, and the only one I was payed for completely.
Hyperion has an exclusive licence for my AmigaOS 4.x parts of newlib.
Hyperion could release it as open source, unfortunately I can't.

The benefits of using a portable multi-platform C library like newlib, in which at least 99% of the code is system independent and worked on by developers of other systems as well, compared to AmigaOS-only C libraries like clib2 or clib4 with only a single developer working on it should be obvious.

Topic | Forum

joerg

Re: How to use clib4 (natively)?

Posted on: 6/21 16:06 #17

Home away from home

@Chris
Quote:

I use it for the OS3 port of NetSurf. The alternatives would never have worked.

Using ixemul should still work, even if the last working m68k versions (47.x/48.x) are more than 25 years old by now.
Just don't try to use the newer versions from Bernd Rösch, they are broken in several ways.
I used ixemul for my AmigaOS 3.9/m68k port of OWB.

Topic | Forum

joerg

Re: How to use clib4 (natively)?

Posted on: 6/20 17:16 #18

Home away from home

@kas1e
Quote:

find someone to improve the closed-source newlib,

Sigh. I've posted it several dozens times already, and this time it's the last one: Newlib is open source: https://www.sourceware.org/newlib/
Only the very small AmigaOS 4.x specific parts I implemented are closed source.
Work required for re-implementing all of my AmigaOS 4.x parts, depending on the skills of the developer, about 25-100 man hours, which is much less than the time already spend on clib4...

Topic | Forum

joerg

Re: How to use clib4 (natively)?

Posted on: 6/20 17:04 #19

Home away from home

@kas1e
Quote:

Native building is great and appropriate, especially for code using native OS4 APIs. However, it’s not practical for porting large modern projects that consume gigabytes and rely on constantly evolving build environments.

Not modern any more, about 15 years ago, but I never used a cross-compiler for any of my AmigaOS 4.x development, incl. OWB.
And yes, it was very slow, a complete rebuild of it on an A1XE or even worse on my Sam440ep (too few RAM, paging involved) had to be started on an evening to have some results, at best, on the next morning...

Topic | Forum

joerg

Re: How to use clib4 (natively)?

Posted on: 6/20 16:52 #20

Home away from home

@Hans
Quote:

Having multiple runtime libraries is messy.

Yes, and that was one of the reason I insisted to add a clause in my newlib contract that support for clib2 has to be removed from adtools (at least in all versions of it distributed by Hyperion).
But, just like for nearly everything else, Hyperion broke the contracts...

Topic | Forum

Top

(1) 2 3 4 ... 101 »