This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2 1/2] Refactor sigcontextinfo.h



On 15/08/2019 14:56, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 15/08/2019 11:36, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> On 15/08/2019 10:53, Florian Weimer wrote:
>>>>> * Adhemerval Zanella:
>>>>>
>>>>>>> So I strongly urge you to add a test like the one below.  I can commit
>>>>>>> it separately after your patch.  I still need to verify that it builds
>>>>>>> on all architectures.
>>>>>>
>>>>>> I will integrate your tests if you are ok with that, however it requires some
>>>>>> changes.
>>>>>
>>>>> Thanks.  What kind of changes?
>>>>>
>>>>> SA_SIGINFO is missing from sa_flags.  I've already fixed that.
>>>>>
>>>>>> I will double check it on some different architectures also.
>>>>>
>>>>> It works on aarch64, i386, x86-64, s390, s390x, ppc64le.  I planned to
>>>>> test ppc and ppc64 as well, but could not get a Beaker machine yet.
>>>>
>>>> I can check on alpha, hppa, sh4, arm, m68k, sparc, and ia64. Both ia64 and
>>>> sparc does not pass a ucontext_t as third argument, so these are the ones
>>>> I would like to double-check.
>>>
>>> Sounds good.  The tests (with the SA_SIGINFO fix applied) builds
>>> everywhere using build-many-glibcs.py.
>>
>> The check call backtrace with in a signal handle, so it needs to be
>> built with -fasynchronous-unwind-tables (testing on sparc showed that
>> without this option it can't get a full stacktrace, I think some ABIs
>> have the same issue).
> 
> Oh, right.  Wouldn't raise.c have to be compiled in this way?

It is not strictly necessary for the test, since it will hit the expected PC 
just before the raise call. However on some ABIs, sparc for instance,
backtrace stops right before the raise call.

> 
> (We should really build all of glibc with asynchronous unwind tables.)

Does libgcc_s require asynchronous unwind tables to correctly unwind? Or does
it need just for PTHREAD_CANCEL_ASYNCHRONOUS, where the unwind happens in the
signal handler instead of the syscall entry?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]