Do we have an execpl replacement?

Hello everyone,

as the title says, do we have an execpl replacement?

I know that Chris y. have execvp replacement (https://github.com/chris-y/git2/blob/m ... src/common/compat/amiga.c), but do we have repacements for execpl and other function of unistd?

12.NGFSBoot:>

CLIB2 yes:

objdump -t sdk:clib2/lib/libunix.a | grep exec
unistd_execl.o: file format elf32-amigaos
00000000 l df *ABS* 00000000 unistd_execl.c
00000000 g F .text 0000023c execl
00000000 *UND* 00000000 execve
unistd_execle.o: file format elf32-amigaos
00000000 l df *ABS* 00000000 unistd_execle.c
00000000 g F .text 000002d0 execle
00000000 *UND* 00000000 execve
unistd_execlp.o: file format elf32-amigaos
00000000 l df *ABS* 00000000 unistd_execlp.c
00000000 g F .text 00000234 execlp
00000000 *UND* 00000000 execvp
unistd_execv.o: file format elf32-amigaos
00000000 l df *ABS* 00000000 unistd_execv.c
00000000 g F .text 0000000c execv
00000000 *UND* 00000000 execve
unistd_execve.o: file format elf32-amigaos
00000000 l df *ABS* 00000000 unistd_execve.c
00000b0c g F .text 00000610 execve
00000000 *UND* 00000000 __execve_environ_init
00000000 *UND* 00000000 __execve_exit
00000000 *UND* 00000000 __execve_environ_exit
unistd_execve_env_exit.o: file format elf32-amigaos
00000000 l df *ABS* 00000000 unistd_execve_env_exit.c
00000000 g F .text 00000004 __execve_environ_exit
unistd_execve_env_init.o: file format elf32-amigaos
00000000 l df *ABS* 00000000 unistd_execve_env_init.c
00000000 g F .text 00000008 __execve_environ_init
unistd_execve_exit.o: file format elf32-amigaos
00000000 l df *ABS* 00000000 unistd_execve_exit.c
00000000 g F .text 00000004 __execve_exit
unistd_execvp.o: file format elf32-amigaos
00000000 l df *ABS* 00000000 unistd_execvp.c
00000000 g F .text 00000338 execvp
00000000 *UND* 00000000 execve

NEWLIB:

12.NGFSBoot:> objdump -t sdk:newlib/lib/libc.a | grep exec
12.NGFSBoot:> objdump -t sdk:newlib/lib/libunix.a | grep exec

Not so much

But if you have a execvp() than you ofcourse have an execlp() seeing as execlp() is the varags version of execvp()

@AmigaBlitter

It good start to read about command.

https://linux.die.net/man/3/execvp

what is suppose to return and so on...

it should be to hard to implemented.

you execute it with command system() its priority easy to use.

http://man7.org/linux/man-pages/man3/system.3.html

all you need to is kind create new command line string, should be too hard, you need some "" symbols around args, and you need to calculate size of buffer from number of args, and number of extra symbols like "", and null terminate symbol \0.

strcpy and strcat can do that, or you use sprintf, sure there are lots more, or you can write your own.

Important to note that exec() is not a very amiga thing. In princliple never returns but even with a drop in replacement, you'll to deal the fact that it *does* return on AmigaOS (when the executed program returns).

@LiveForIt

"all you need "

exec#? (or should that be exec* seeing as it's posiix) are bit harder to do than that... see clib2/abc-shell/perl src code for inspiration.

@AmigaBlitter

I think waitpid is lot more impotent to implement.

https://linux.die.net/man/2/waitpid

at some point the program will exit, and its going to wait for threads to finish, before exiting... this where badly ported programs sucks and fucks up memory and turn the Amiga into a brick.

@broadblues

In that case all you need is dos.library, not exec.library, but using posix stuff make it more portable its part of the SDK should work.

"ftime" is another missing function

@AmigaBlitter

AFAICT ftime() returns basically the same information as gettimeofday() only the fractional seconds part is milliseconds instead of microseconds, so the following simple replacement should work:

@AmigaBlitter

Quote:

The execvp() "replacement" you link to is just a dummy function which prints a message to the program's stdout.

In fact the pipe() function there is also wrong since it uses fopen() when it should be using open() instead.

Instead of:


the code should be:


Though without fork() the pipe() function is of somewhat questionable use, since they are most often used in combination.

The waitpid() function there is also a dummy BTW.

@salass00

There a way to create those function grabbing them from https://github.com/sba1/clib2
or this would be too messy?

@AmigaBlitter

Quote:

Clib2 license allows you to do so as far as I understand it. It wouldn't be messy unless you did it messily.

However, if you need to extract largish lumps of clib2 to add to your port you should consider actually linking against clib2 instead of newlib.

What kind of thing are you porting? If it needs shared object support for mosule loading etc then you are somewhat stuck with newlib, but other wise there's no reason not to use clib2, and can quite a few reasons *to* do it.

abc-shell and the core-utils are linked against clib2 for good reason, for example. (Command argument handling, libunix function requirements etc etc)

@broadblues

I'm porting DosBox X (trying...)







I need an ftime replacement and a few others functions. I currently disabled serial and ftime.

@AmigaBlitter
If you compile your own clib2 you can also activate NULL pointer checking by editing the clib2 stdlib_null_pointer_check.h file.

Found this code on Amiga Wiki page, but seems not working or not updated




Gettime.c: In function 'main':
Gettime.c:39: error: 'struct TimeRequest' has no member named 'tr_node'
Gettime.c:43: error: 'struct TimeRequest' has no member named 'tr_time'
Gettime.c:44: error: 'struct TimeRequest' has no member named 'tr_time'
Gettime.c:78:2: warning: no newline at end of file

@xenic

Thank you for the info

@AmigaBlitter

Replace tr_node with Request and tr_time with Time.
TimerIO->tr_time.tv_micro => TimerIO->Time.Microseconds
TimerIO->tr_time.tv_secs => TimerIO->Time.Seconds

@AmigaBlitter

Quote:

Did you miss the ftime() code that I posted earlier?

If you use timer.device directly you need to convert the time from AmigaOS to UNIX epoch and from local time to GMT, because this is the format that should be returned by the POSIX time functions.

@salass00

Quote:

That's a dead project but I feel like I might have to fix this bug to stop it being continually quoted...

@salass00

Yes, sorry i missed your post.

Thank you