Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Chung-Lin Tang <cltang@codesourcery.com>
Cc: gdb-patches@sourceware.org,	Thomas Schwinge <thomas_schwinge@mentor.com>
Subject: Re: [PATCH][SH] Signal handler unwinding for SH-Linux
Date: Wed, 02 May 2012 21:52:00 -0000	[thread overview]
Message-ID: <20120502215148.GC15555@adacore.com> (raw)
In-Reply-To: <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


  parent reply	other threads:[~2012-05-02 21:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-29  8:58 Chung-Lin Tang
2012-04-29 15:16 ` Yao Qi
2012-05-02 21:52 ` Joel Brobecker [this message]
2012-05-07 13:19   ` Chung-Lin Tang
2012-05-07 15:36     ` Joel Brobecker
2012-05-07 15:44       ` Chung-Lin Tang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120502215148.GC15555@adacore.com \
    --to=brobecker@adacore.com \
    --cc=cltang@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=thomas_schwinge@mentor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox