GCC Feedback

Peter Naulls peter at chocky.org
Tue Jan 13 06:25:08 PST 2004

Here is an email I was sent.  I've asked him to send further queries to
this list, since none of them are really specific to my version.


Hi Peter,

You may remember that I contacted you last year because we had a customer
using GCC for a large C++ project. They seem to be fairly settled now - we
did switch to using your 32-bit GCC distribution in the end because it
fixes various bugs that they encountered in the last "official" release.
However, I thought you might appreciate this feedback on your version; I
think each point is still relevant to the brand new release.

At some point since the January 2003 release, the file _G_config.h (in
!gcc.lib.gcc-lib.arm-riscos-aof.2_95_4.include.g++3) has, with no
explanation given, gained the line
  #include <unixlib/features.h>
which causes lots of problems if you're trying to do C++ work using the
SharedCLibrary. The STL library (or at least the parts that they have used)
otherwise seem to function fine without the line, so was this a mistake?

Since recent binary distributions are compiled with __FEATURE_PTHREADS
defined, the alloca support routines in libgcc import the symbol
__pthread_running_thread to access their thread-specific workspace.
This presents a problem when working with the SCL instead of UnixLib,
since there is no thread management library; I see that the way this
has been resolved is to export a pointer to a static data block from
the GCC SCL stubs. Apart from introducing yet another difference from
the Norcroft SCL stubs, I think this is undesirable because it precludes
the possibility of using any threading library at all when using alloca
and the GCC SCL stubs. What I'd like to see instead is the alloca support
routines doing a weak import of __pthread_running_thread and dropping
back to using a static data block within libgcc if the symbol is undefined.

Now that you have a pthreads implementation, I suggest that you activate
the pthreads support in the exception handler code, at least in the
UnixLib variant of libgcc. Again, I would ideally like to see the SCL
variant of libgcc detecting somehow whether a threading library is present,
but as a minimum you could provide a __set_eh_context function to allow
external control over the get_eh_context function pointer (at the moment,
I'm editing the symbol table in libgcc binaries to export the
get_eh_context symbol).


Ben Avison
Tematic                                       Tel: +44 (0) 1728 727437
182-190 Newmarket Road                        Fax: +44 (0) 1728 727430
Cambridge, CB5 8HE, United Kingdom            WWW: http://www.tematic.com/

Peter Naulls - peter at chocky.org        | http://www.chocky.org/
GCC for RISC OS                        | http://hard-mofo.dsvr.net/gcc/

More information about the gcc mailing list