This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug sanitizer/81066] sanitizer_stoptheworld_linux_libcdep.cc:276:22: error: aggregate ‘sigaltstack handler_stack’ has incomplete type and cannot be defined
- From: "fw at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 09 Jul 2017 16:35:53 +0000
- Subject: [Bug sanitizer/81066] sanitizer_stoptheworld_linux_libcdep.cc:276:22: error: aggregate ‘sigaltstack handler_stack’ has incomplete type and cannot be defined
- Auto-submitted: auto-generated
- References: <bug-81066-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066
--- Comment #8 from Florian Weimer <fw at gcc dot gnu.org> ---
(In reply to Khem Raj from comment #7)
> (In reply to Florian Weimer from comment #6)
> > (In reply to Khem Raj from comment #5)
> > > +#ifndef __stack_t_defined
> > > +struct stack_t;
> > > +#endif
> >
> > Where does __stack_t_defined come from? If this is the definition from the
> > glibc headers, that's really brittle because it's totally internal.
>
> infact it is from bits/types/stack_t.h so you are right. sanitizers redefine
> a lot
> of stuff from libc. So we can not include signal.h without such quirks
I think you should change the signature of internal_sigaltstack. Something
like
void internal_sigaltstack(void *, size_t);
should work, due to the way the function is used. Then you'll need to
reference the stack_t type only within its implementation (at which point, I
assume, it is safe to include glibc's <signal.h>).
As far as I understand the interface, there is no need to keep the actual
stack_t object around while the alternative signal stack is in use.