Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Philipp Rudo <prudo@linux.vnet.ibm.com>
To: "Ulrich Weigand" <uweigand@de.ibm.com>
Cc: gdb-patches@sourceware.org, arnez@linux.vnet.ibm.com (Andreas Arnez)
Subject: Re: [PATCH v2 07/11] s390: Hook s390 into OSABI mechanism
Date: Tue, 05 Dec 2017 17:06:00 -0000	[thread overview]
Message-ID: <20171205180640.6677e975@ThinkPad> (raw)
In-Reply-To: <20171205132055.C7002D80330@oc3748833570.ibm.com>

Hi Uli,

On Tue, 5 Dec 2017 14:20:55 +0100 (CET)
"Ulrich Weigand" <uweigand@de.ibm.com> wrote:

> Philipp Rudo wrote:
> 
> Just a couple of quick comments on the common vs. Linux split.
> 
> > +  set_gdbarch_guess_tracepoint_registers (gdbarch,
> > +					  s390_guess_tracepoint_registers);  
> 
> This is OS-independent as far as I can see.

Ok, I'll move it back.
 
> > +  /* Frame handling.  */
> > +  frame_unwind_append_unwinder (gdbarch, &s390_stub_frame_unwind);
> > +  frame_unwind_append_unwinder (gdbarch, &s390_sigtramp_frame_unwind);
> > +  frame_unwind_append_unwinder (gdbarch, &s390_frame_unwind);
> > +  frame_base_set_default (gdbarch, &s390_frame_base);  
> 
> All of that *except* the sigtramp unwinder is OS-independent.  In fact,
> if move the prolog-based sniffer to common code, you'll see that you no
> longer need to export various internal routines from s390-tdep.c to
> s390-linux-tdep.c.
> 
> This may require swapping the order of the stub and the sigtramp unwinder,
> but that should be harmless.  In the end you should have this sequence:
> 
> - first, in common code, announce all the DWARF-based unwinders
> - then, in Linux ABI code, announce the sigtramp unwinder
> - finally, back in common code, announce all the fallback unwinders

That's not true.  At least for the kernel the unwinders (except the DWARF-based)
failed and I had to write my own one.  Especially the fact that the kernel has 
multiple stack locations and no distinct 'End of Stack' caused problems.

However if I go with your approach and add my unwinder in the kernel ABI code
as default, i.e. that it always catches the call, it should work.  But that
won't be nice code.  That's why I moved them to the Linux ABI.

> >    set_gdbarch_process_record (gdbarch, s390_process_record);
> >    set_gdbarch_process_record_signal (gdbarch, s390_linux_record_signal);  
> 
> The first of these should be generic, only the second is Linux specific
> (that's why there are two different callbacks to begin with!).

Ok, I'll move the first one back.

> > +  /* Miscellaneous.  */
> > +  set_gdbarch_stap_is_single_operand (gdbarch, s390_stap_is_single_operand);
> > +  set_gdbarch_gcc_target_options (gdbarch, s390_gcc_target_options);
> > +  set_gdbarch_gnu_triplet_regexp (gdbarch, s390_gnu_triplet_regexp);  
> 
> Are these really Linux-specific?

No, not really.  They should be common for the architecture for all systems
with working GDB/GCC/BFD. I'll move them to the common file.

Thanks
Philipp


  reply	other threads:[~2017-12-05 17:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-05 12:29 [PATCH v2 00/11] Split up s390-linux-tdep.c Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 03/11] s390: gdbarch_tdep.have_* int -> bool Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 01/11] s390: Remove duplicate checks for cached gdbarch at init Philipp Rudo
2017-12-05 16:16   ` Yao Qi
2017-12-06  9:56     ` Philipp Rudo
2017-12-06 10:28       ` [PATCH v2 01/11] s390: Remove duplicate checks for cached gdbarch@init Ulrich Weigand
2017-12-07  9:18         ` Philipp Rudo
2017-12-07  9:59           ` Yao Qi
2017-12-05 12:29 ` [PATCH v2 07/11] s390: Hook s390 into OSABI mechanism Philipp Rudo
2017-12-05 13:21   ` Ulrich Weigand
2017-12-05 17:06     ` Philipp Rudo [this message]
2017-12-05 17:44       ` Ulrich Weigand
2017-12-06 11:39         ` Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 06/11] s390: if -> gdb_assert for tdesc_has_registers check Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 09/11] s390: Clean up s390-linux-tdep.c Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 05/11] s390: Move tdesc validation to separate function Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 04/11] s390: gdbarch_tdep add field tdesc Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 02/11] s390: Allocate gdbarch & tdep at start of gdbarch init Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 10/11] s390: Add comments to uncommented functions in s390-tdep.c Philipp Rudo
2017-12-05 12:29 ` [PATCH v2 11/11] s390: Add comments to uncommented functions in s390-linux-tdep.c Philipp Rudo

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=20171205180640.6677e975@ThinkPad \
    --to=prudo@linux.vnet.ibm.com \
    --cc=arnez@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=uweigand@de.ibm.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