Re: [gccsdk] af_unix socketpair
Hi Lee, > > Does sockets only exist in the current task? If I do > > "wimp_start_task", can I use my socket in the new task? > > No, although the underlining OS socket is I believe system wide, > Unixlib refers to them by file descriptor and these are allocated > locally within each task rather than system wide as Linux might do, so > you can't pass the file descriptors between tasks. Unix (Linux) allocates file descriptors within a process, that's why they all start at zero and the lowest unused one within the process is allocated. But I think you know that and it's terminology where we differ. An FD is an index into the process's FD table and that entry references an element in the kernel's single file table, FT. Unix can pass a file descriptor from one process to another. What's really being passed is the reference to the kernel's FT entry. Thus the FT entry may be referenced by a different FD in the receiving process, e.g. 42 becomes 314. > You may be able to pass the underlying OS socket between tasks, but > Unixlib in the task you pass it to would not be aware of it; I don't > think Unixlib can adopt an existing OS socket. So if Unixlib wanted to grow the ability to mimic Unix in this regard, it would be by supporting the SCM_RIGHTS ancillary message over a Unix domain socket. See unix(7) on Linux. -- Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] FILE structure
Hi Ronald, > In trying to implement wget's own support lib there was a requirement > for an implementation of freading(). Here's glibc's description. https://manned.org/__freading.3 > It looks like some extra system flag would need to be set on every > read, and negated on a write. That may be needed anyway as a side effect of tracking a buffer's state, e.g. https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/refill.c;h=87a715b848b0009624f3fc76d938ef49a35bc282;hb=HEAD#l33 -- Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] wget 1.19.1 tries to write a logfile
Hi Theo,
> It is still worth commenting on upstream bug trackers - they won't
> know what RISC OS is, but if the bug is not a RISC OS specific one
> then the bug report is still relevant.
It might be that RISC OS triggers it in a similar way to the odd set up
on that bug report.
src/log.c:
955 static void
956 check_redirect_output (void)
957 {
958 #ifndef WINDOWS
959 /* If it was redirected already to log file by SIGHUP, SIGUSR1 or -o
parameter,
960* it was permanent.
961* If there was no SIGHUP or SIGUSR1 and shell is interactive
962* we check if process is fg or bg before every line is printed.*/
963 if (!redirect_request_signal_name && shell_is_interactive &&
!opt.lfilename)
964 {
→ 965 if (tcgetpgrp (STDIN_FILENO) != getpgrp ())
966 {
967 /* Process backgrounded */
→ 968 redirect_output (true,NULL);
969 }
I haven't run this code, but I wonder if 965 is true. If Kevin is happy
to modify the source and re-build then he might be able to tell that 968
executes.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] pthread shutdown in atexit
Hi Alan, > I have a mysterious crash in a SDL based program when it attempts to > do a pthread_wait in an atexit handler. The error is: pthreads: > ***fatal error, aborting*** pthread_yield called with context > switching disabled. > > My guess is this means that GCC is shutting down the threads system > before the atexit handler is being called. Are you calling atexit(3) before or after your initialise pthreads? I'd call it after as the registered functions are called in reverse order so if pthreads is registering one itself to "shutdown" then you want that called after yours. Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Is there activity here?
Hi Dave, > ... and, if there is: have I failed to notice it, or did it not > arrive in my inbox? http://www.riscos.info/pipermail/gcc/2017-May/thread.html -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] RO support being removed from curl
Hi, Jeremy wrote: > The pull-request for doing so is already submitted, see link below. The email is https://curl.haxx.se/mail/archive-2017-05/0004.html and the PR is https://github.com/curl/curl/pull/1463 with https://github.com/curl/curl/pull/1463/commits/85b3072d422d0c25cb8c5d724206bebcc222f149#diff-10de2e0e2a5a0a4f65bb973cfd304c5aL34 being the interesting bit listing the environment variables. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
[gccsdk] (no subject)
Hi Michael, > Getting drown by emails from bugzilla. I emailed a couple of Theo's personal addresses earlier today, and I've now emailed Peter to turn on list moderation until they stop being generated. Hopefully, they'll be stemmed soon. -- Cheers, Ralph. (Just another subscriber.) https://plus.google.com/+RalphCorderoy ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] OS_GBPB heeby jeebies
Hi Gavin, > You are a genius. Thanks. I'm often told I "full of it". ;-) But it was not I that pointed this out, but Nick Burrett. http://www.riscos.info/pipermail/gcc/2015-September/006473.html > I guess I had not properly appreciated what 'const' meant. I recommend Chris Lattner's three posts on what a C compiler can assume; I think you may be surprised. It starts with http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] OS_GPBP conundrum
Hi Gavin, > static const int rdir_buf[RDIR_BUFLEN/sizeof(int)]; ... > lua_pushstring(L, (char *)(_buf[6])); /* name */ > lua_pushinteger(L, rdir_buf[5]); /* file type */ > return 2; /* number of returned values */ ... > The 'name' part comes out OK, but the 'ftype' is always zero, and I > just cannot see why. Sounds like rdir_buf is being re-used, but only the first 24 bytes of it, trampling the filetype, but not the filename, before the push. Do you see filetype in rdir_buf[5] when you lua_pushinteger() above? If so, what happens between the push of the correct filetype and the pull where it's wrong? If not, show us the OS_GPBP 12 call? Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] OS_GBPB heeby jeebies
Hi Gavin, > > ^ shouldn't that be static int? Wouldn't the const imply that the > > buffer never changes This is the problem. > The buffer doesn't change. It's its contents that change. I will try > removing the const. The buffer is its contents. As an array rather than a pointer the address of its first element will never change with or without the const. The const is saying the elements' values are constant. Constant at zero since it's a static and not initialised to anything else. > Why are the filetypes coming out as zero, rather than some other > value? Because the compiler can assume the contents of a static const array that's not initialised to anything are zero and doesn't need to load from memory; check the assembler. Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Unable to get the pipe function to work
Hi Lee, > I have yet to find any documentation on the web that defines the order > of return. The order of return after fork(2) is defined as being not determinable, i.e. correct code has to cope with either order or even simultaneous return since another CPU might be brought it to run one of them. With Linux 2.2 and 2.4 the parent returned first, with 2.6 it's the child up until 2.6.32 when it switched once again. Other Unix operating systems may not even be consistent within a version. vfork(2)'s raison d'être meant the parent didn't run until the child was finished or overwritten with execve(2). Nowadays, that's not true and can't be assumed. Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] exec() possibly a problem
Hi Ron, My useage here is in fact wrong, it appears that command and args are wrapped in single quotes for a subshell. (Also done in a shellscript) No, that's too simplistic. Unix shells like dash follow http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html in their processing of the backslash escape, and single and double quotes. $ $PATH/sh -c 'printf hello...\\n' hello... $ all good Simplifies things, now just the \\n being needed across the new process. I've only skimmed this thread to date, but be aware that there are three processes parsing that command above. The dash shell that's printed the `$ ' prompt. The sh you explicitly start. And the printf that's either a built-in to the shell or a separate executable that's processing the argv[] its main has been passed. All three of them are happy to interpret a backslash-escape in some circumstances. As an example, double quotes, which allow more interpolating, aren't necessary above. Another layer of single quotes can be used, with them mechanically being escaped, e.g. $ sh -c 'printf '\''hello...\n'\' hello... $ Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] GCC 4.7.4 Rel 1 Dev 2014-01-08: Text file execute permission bit
Hi Ben, I thought about that too (i.e. check on Alias$@RunType_XYZ), but then we have text files with execute permission bit set too. I'm not sure whether it going to be worthwhile. As you say, most data filetypes has RunType variables assigned, so that's no use to distinguish executables from data files. From another perspective, if I can *Foo from a shell and it runs then does it matter it opens an editor for Foo, if that's how the RunType is defined? For Tab-completion at a prompt, I'd want Foo included in the possbilities? On Linux, one could make a PNG executable and define a suitable http://en.wikipedia.org/wiki/Binfmt_misc to make an ASCII approximation cat(1) to the TTY. :-) Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] GCC 4.7.4 Rel 1 Dev 2014-01-08: Text file execute permission bit
Hi John, I think it would be better to derive this from RISC OS filetype, i.e. test on Obey, Absolute, ELF, Module, Utility (any others?). If you allowed Obey, why not BASIC? And then, why not Lua, REXX, Python etc - how would the code know whether to treat an arbitrary filetype as executable? Waht about if there's a RunType variable defined for that filetype? My RISC OS memory is hazy but that might be an option. Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] unixlib directory iteration doesn't work on Fat32FS
Hi Matthew, The telldir function has to return a long int which says where we currently are in reading the directory and these special subdirectories. The seekdir function has to take that value and turn it back into a GBPB position in the directory and in the corresponding subdirectory if we are in the middle of one. Given the DIR that these functions use is opaque, it seems to me it could store an array of every unique (dir, sub) RISC OS position ever returned by telldir(), with telldir returning the index, and seekdir() plucks the tuple from that index. I don't see anything in the POSIX man page that suggests telldir results have an ordering, merely they can be passed back to seekdir. No clean-up of the list is possible until the whole DIR is scrapped with closedir(), but it's unlikely to be a problem in practice. Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Help with gas
Hi Gavin, I am making a serious effort (again) to get to grips with gcc4_1_2r2. I am trying to assemble a short piece of ARM code with gcc -o sys.o sys.s Try one of gcc -c sys.s gcc -c -o sys.o sys.s I keep getting an error: : In function 'crt1_data': crt0.S:(.data+0x14): undefined reference to 'main' collect2: ld returned 1 exit status make: *** [sys.o] Error 1 Without -c for `compile only' the C compiler kicks off the linker/loader, the `ld' in the output, to produce a finished executable. ld observes the C runtime tries to call main() but no main() is defined. Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] stderr 2 file advantage
John wrote: Very bizar, looks like a real bug somewhere but someone needs to dig into this as I don't think we can just guess it based on above facts only. Perhaps there's something up with stderr, file descriptor 2, and that causes the first signal the handling of which wobbles because it would like to use stderr? Is there something on RISC OS like strace(1) now? On Linux, one can see tar doing things like GET_FD on FD 2 early on, with, for example, an opening of /dev/null if it's a bad file descriptor. tar -xvf foo.tar 2- Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] killpg function not implemented
Hi Alan, In the short term is there a workaround I can use to provide the functionality? I assume I would need to use the kill function and somehow finding the processes in the same group. Perhaps the implementation of kill(2) has this already? Linux's killpg(2) says On Linux, killpg() is implemented as a library function that makes the call kill(-pgrp, sig). which is how I traditionally think it was done, pre-killpg(). Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Different behaviour between scl and unixlib
Hi Jan-Jaap, while ((read = fscanf(file, %10[^\n]%c, buffer, lastchar)) != EOF) fscanf(3) here says %[ matches a non-empty sequence. That matches the behaviour I see on Linux, no gccsdk involved. $ printf 'foo\nbar\n\nxyz\n' | ./fscanf | sed 4q read: 2: 'foo', lastchar = 10 read: 2: 'bar', lastchar = 10 read: 0: 'bar', lastchar = 10 read: 0: 'bar', lastchar = 10 $ Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Development roadmap proposal
Hi John, 5. Since several of years there is a new kid around the block in 'free' compiler land : LLVM http://www.llvm.org/. Basically it is a compile infrastructure/JIT/code transformer/code analyser/etc of which one of its usecases is just compile C/C++ with apparently respectful or even impressive results. The C/C++ frontend is still a bit immature and not 100% ready for cross-compile purposes but I've already been playing a bit with it (gccsdk/branches/joty/llvm) to get a better understanding what this could mean as RISC OS compiler. Out of curiosity, were you playing with llvm-gcc, which is GCC for the front-end and LLVM for the back-end, or Clang, their new C/C++/Objective C/etc. compiler that doesn't use GCC and is aimed at being a faster compiler, more cleanly implemented? http://llvm.org/cmds/llvmgcc.html http://clang.llvm.org/ Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Problems building crosscompiler
Hi Jan-Jaap, I renamed /usr/bin/autoconf to /usr/bin/autoconf2.64 and made /usr/bin/autoconf a symlink to /usr/bin/autoconf2.59 but I got the exact same problem. I then did the same to /usr/bin/autoreconf* but I'm not so sure that that will have the desired effect. How about getting the source tar for the desired version and ./configure it with a --prefix of some temp. directory, e.g. /tmp/jjac. Build and install. Then ensure /tmp/jjac/bin is up the front of your PATH when you want to do stuff that needs it. Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Further ArcEm development (or not)
Hi Peter,
The ArcEm CVS has been static for quite some time.
Last change 2009-09-25?
Sorry yes. cvs log does things in a unhelpful order. I've been
using SVN too long.
Yes, I found it annoying when I went to look.
$ cvs log |
sed '/^date: /!d; s#/.. .*##; s/.* //; y#/#-#' |
sort -r | uniq -c |
pr -t3
2 2009-09 72 2006-02 2 2003-08
21 2008-11 35 2006-01 123 2003-05
2 2008-10 7 2005-12 35 2003-04
5 2008-05 1 2005-11 29 2002-08
15 2008-04 7 2005-10 50 2002-06
1 2007-04 2 2005-08 105 2002-05
7 2007-01 7 2005-07 21 2002-03
1 2006-10 15 2005-02 6 2002-02
16 2006-09 25 2005-01 1 2002-01
1 2006-05 26 2004-12 8 2001-11
38 2006-04 15 2004-11 133 2001-10
45 2006-03 9 2003-10
$
Do you have any specific plans for ArcEm here?
No. Just fixing whatever thing's got in the way the next time I dust it
off and go to use it. But I've not done much on it in some time, others
come along and run with it for a while, and I expect this'll keep
happening.
My biggest frustration with RPCEmu is still the issue of RONs.
The Spoon site links to where 3.60 and 3.71 can be downloaded. I find a
bigger problem with later ROM images is that some are taken after
they've been patched by the boot process. As I now understand it, the
list of SHA1 digests at http://inputplus.co.uk/ralph/#acornem has an
error. The correct digest for '4.02 (10 Aug 1999)' is
37acd8573da51493beb0fa6eef29623ce382822f; thanks to Eric Rucker for
sacrificing his RiscPC's CMOS to determine that. Any other corrections
welcome.
Debugging error reports from people who say they're running, e.g. 4.02,
may be hampered if they're starting with a patched ROM image or patch it
on booting.
I suspect the biggest future problem for RPCEmu is the one that bit
arcem; copy-and-paste expansion of code. For arcem it was to port to
more platforms. There's lots of identical, or worse almost identical,
code that should be platform independent, or worked on to be made
platform independent, that isn't. Now if I want to change a P.I. line
or two I have multiple copies to change having gone to the effort of
making sure the change is correct in all cases and bearing in mind some
of the changes I then can't compile and test. In the end, I don't
bother.
With RPCEmu.c this has happened with the interpreted versus dynarec ARM.
I'm spotting little improvements here and there and instead of making
them twice am trying to factor out common code where possible. Really,
the build process needs changing a bit so both variants are compiled but
only one linked in. At the moment I have to run './configure make
all check' in all four variants of --enable-{debug,dynarec} before
submitting a patch to Peter Howkins.
There are other Archimedes emulators that seem to have vanished for
example.
Yes, but they were never on SourceForge.
The mailing lists work fine and have a decent archive interface on
mail-archive.com. (sf.net's is awful.) Why break all those ties?
I don't see any benefits.
In fairness, the ArcEm mailing list isn't really used any more. The
argument could be make for combining its traffic with that of RPCEmu.
It is used. Someone new subscribes and asks for help and gets
responses. 2008-10 is the last example on the user list.
http://www.mail-archive.com/arcem-u...@lists.sourceforge.net/
http://www.mail-archive.com/arcem-de...@lists.sourceforge.net/
I think there's probably folks interested in arcem, perhaps because they
did work on it, that are still subscribed and want to be yet have no
interest in lots of current chat about the more actively developed
RPCEmu.
riscos.info's wiki already links to arcem.sf.net, perhaps a page for
it is all that's needed if you're concerned about it being
forgotten?
Perhaps.
I agree the arcem.sf.net web site needs to indicate there's no current
development but feel free to come along and play around. However,
Acorn users will be used to coming across web sites where the last news
entry is last century and yet still realise there may be useful stuff
there.
Cheers,
Ralph.
___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
Re: [gccsdk] Further ArcEm development (or not)
Hi Chris, On Tue, 06 Oct 2009 20:26:31 -0700, Peter Naulls wrote: What I'll likely do then is close down the Sourceforge page. I'll import the ArcEm CVS into riscos.info SVN for historic value (if anyone really wants write access, just let me know a user name/password). It's possible I might make a final release, and bring the HTML pages/ manual to riscos.info and link them into the wiki. I'll see also if I can get a mailing list snapshot. I don't see any need to move it. Perhaps a copy of the source could be kept elsewhere in case sf.net closes the project down though. Yes. SourceForge keep backups themselves but only for restoring after hardware failure, so they do suggest projects keep their own backups of their data, e.g. SCM and mailing lists. http://sourceforge.net/apps/trac/sourceforge/wiki/Backup%20your%20data http://sourceforge.net/apps/trac/sourceforge/wiki/Using%20rsync%20for%20backups#CVS Perhaps that's something riscos.info could offer. Knowing there's a centralised, say weekly, backup of sf.net Acorn projects, e.g. arcem, and riscose, would be nice. Cheers, Ralph. ___ GCCSDK mailing list gcc@gccsdk.riscos.info Bugzilla: http://www.riscos.info/bugzilla/index.cgi List Info: http://www.riscos.info/mailman/listinfo/gcc Main Page: http://www.riscos.info/index.php/GCCSDK
