This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Put libunwind.a in libgcc_s.so: versioning of _Unwind_*() symbols
> Looking at gthr-gnat.c, I see that it defines a __gnat_install_locks
> function, and the only use is in gcc/ada/adaint.c inside VMS ifdefs. So
> apparently this file is not doing anything important for ia64-linux.
gthr-gnat.c is no longer needed at all, except on VMS.
> The question then is what does it do. Well, it defines
> gthread_mutex_{,un}lock functions that do nothing. If you link with
> these instead of the pthread versions, then obviously, you will never
> run into pthread bugs because you aren't calling pthread locking
> routines. Also, just as obviously, multi-threaded programs that require
> locking won't work anymore. This seems like a potential problem to me.
No, you missed the fact that gthr-gnat.c is using pointers to functions,
and provides a gnat_install_locks, which is called with appropriate
locking routines by the GNAT tasking run time when tasking is used.
> There is another question of why we don't get link errors when we aren't
> using gthr-gnat.c. Where do the __gthread_mutex* functions come from in
> that case? I am puzzled. I haven't tried doing builds and looking at
> them to see what is going on.
Because no file is referencing these symbols.
> On the other hand, gnat-gthr.c is there for apparently all other
> targets, so it probably should be there, even if it seems to be flawed.
No, gthr-gnat.c should only be there at this point for VMS. It would be
removed for all other targets, not added.
Arno