| From: | Aaron Optimizer Digulla |
| Date: | 7 Aug 2000 at 07:27:55 |
| Subject: | Re: AMIOPEN: ixemulng library, tools and global variables |
On Fri, Aug 04, 2000 at 09:16:47AM -0500, Rudi Chiarito wrote:
> On Fri, Aug 04, 2000 at 02:29:26PM +0200, Aaron Optimizer Digulla wrote:
> > #define seterrno(x) \
> > ({ int __value = (x); \
> > __asm__ __volatile__ ("cpy.i %0, [gp+-$14]" \
> > : /* no outputs */ \
> > : "g" (__value) \
> > ); \
> > })
> >
> > Is this code correct ? What other variables can be accessed via
> > gp ? Or is there a better interface to access gp from C ?
>
> "errno=x" would probably be better :)
When I tried to *write* errno in my tool, I got an error. Should I
try again ? How ? Just including errno.h doesn't seem enough.
> If you must poke into errno directly, you should at least use
> PROC_ERRNO instead of -$14.
That's a cut&paste of the disassembled perror.00. I didn't know
that there is such a variable. Is there a list or something ?
> > - Then, I found out that we're going to need own globals, too.
> > How can a tool add global variables to the threads which use the
> > tool ? I suggest to expand the mathtest.c example :-)
>
> Not possible, there's no way to find out how many globals the thread
> is already using. Create a shared library if a library requires
> statics.
Is there an example for this ?
> > - If I want to test the tool without installing it, what must I
> > use in the cmdline for vpcc ? Currently, I'm using
> >
> > vpcc {-Dprefix=}$sys.cwd -T -o $sys.cwd/exec exec.c
> >
> > but how do I adjust the path in the header files (... __attribute__
> > (("qcall ixemulng/exec"));) ? I could use the define prefix in them
> > but when I install those files, everyone who includes them would
> > have to define it as well :-(
Any idea for this one ? Right now, I create a temporary directory
and copy all headers with sed replacing " ixemulng/" by the
absolute path.
> > Are there any plans to pride us with a tool-search-path in the
> > near future ? These absolute paths in the tools suck :-(
> Yes.
Since this is such a burning issue: Can we expect a patch any
time soon ?
> "echo" thinks that the options -D -T -o are for it's attention, it
> doesn't understand them. Use "--" to tell it not to look any
> further for switches.
>
> echo -- vpcc etc. etc.
Then please make echo write the message "Unknown option -D". That
would give a hint what's wrong :-)
> > - rm -f should never return with an error. Right now, I cannot
> > use "rm -f *.o" if there is no file matching .o (or better: I have
> > to write "-rm -f *.o" in the makefile so it doesn't abort). This is
> > a small incompatibility to unix which should be simple to fix (never
> > return with an error because of file not found when -f is given).
>
> This is not a bug in "rm", "rm -f" doesn't return an error. It is
> the shell that's complaining.
Yes, I figured something like this.
> Amiga 1.0:/$ rm -f *.super.secret
> shell: *.super.secret: no matches
>
> Shells like zsh and tcsh seem to report the same error:
>
> [yax@ciccillo /tmp]$ rm -f *.super.secret
> rm: No match.
> [yax@ciccillo /tmp]$ echo $shell
> /bin/tcsh
>
> while bash doesn't. Basically, it looks like the shell should hardcode a
> check for "rm" when no match occurs. That's ugly, but then it's Unix. ;)
Bash just passes "*.super" to the software (try echo *.super to see this)
when nothing matches. Can the Ami shell be changed to do the same ?
This is a major pain when writing Makefiles:
must become
because if one pattern doesn't match, the whole command is not
executed :-(