This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH][SH] Signal handler unwinding for SH-Linux
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Chung-Lin Tang <cltang at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org, Thomas Schwinge <thomas_schwinge at mentor dot com>
- Date: Wed, 2 May 2012 14:51:48 -0700
- Subject: Re: [PATCH][SH] Signal handler unwinding for SH-Linux
- References: <4F9CF631.9080807@codesourcery.com>
Chung-Lin,
> 2012-04-29 Chung-Lin Tang <cltang@codesourcery.com>
>
> * sh-linux-tdep.c: Include trad-frame.h and tramp-frame.h.
> (sh_linux_sigtramp_cache): New function.
> (sh_linux_sigreturn_init): New function.
> (sh_linux_rt_sigreturn_init): New function.
> (SH_MOVW,SH_TRAP,SH_OR_R0_R0): New symbols for instruction
> patterns.
> (SH_NR_SIGRETURN,SH_NR_RT_SIGRETURN): New symbols for sigreturn
> syscall codes.
> (sh_linux_sigreturn_tramp_frame): New tramp_frame definition.
> (sh_linux_rt_sigreturn_tramp_frame): Likewise.
> (sh_linux_init_abi): Add init calls to register new tramp_frame
> definitions under 32-bit SH, update comments.
Overall, this looks good to me. I do not know about SH specifically,
so I will take your word on the specific location and layout of the
sigcontext structure.
Just a small minor comment: All new functions and globals should
be documented. Usually, when we implement a "virtual method" (a
function destined to be used as a pointer in one of our generic
structures; Eg. sh_linux_sigreturn_init), we do not repeat description.
We just say that this function implements such and such callback
in struct bla bla for such and such situation. The actual documentation
should already be provided at the same location the field itself
is declared.
For instance, one possible description of sh_linux_sigreturn_init
is:
/* Implement struct tramp_frame's "init" callback for signal
trampolines on 32-bit SH. */
--
Joel