Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Ulrich Weigand <uweigand@de.ibm.com>,
	Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v5 00/12] GDB support for more powerpc registers on linux
Date: Fri, 26 Oct 2018 10:57:00 -0000	[thread overview]
Message-ID: <0d36db86-2310-ccc7-6575-d6070692933c@redhat.com> (raw)
In-Reply-To: <20181024175859.67D97D801EB@oc3748833570.ibm.com>

Thanks for the explanations.  That's really all I wanted; we can
always fix things going forward, but it's important for the community
to have these issues written down in case someone in the future
runs into them before they are addressed and we get to debug them.

I'm fine with merging the patchset as is.

On 10/24/2018 06:58 PM, Ulrich Weigand wrote:
> Pedro Franco de Carvalho wrote:
>> Pedro Alves <palves@redhat.com> writes:
>>
>>> I.e., what is the conclusion wrt to the differences in one of the note
>>> sections generated by the kernel for a core file and the one generated
>>> by GDB?  Was that resolved?  Will it be?
> 
> As Pedro mentioned, I believe the implementation in this latest patch
> set as as good as we're going to get, and should result in GDB core
> files that are mostly equivalent to kernel core files (and in the
> minor details where they're not, I'd argue those are kernel bugs that
> should be fixed there).

That's good to hear.

> 
>>> As for the EBB/PMU patch, about gdbserver writing all registers in one go
>>> before resuming the inferior, and the error would not being detected at the
>>> time the user tries to write them, did you try making gdbserver flush
>>> the regcache after handling 'G' and 'P' packets?  From the previous
>>> discussion, it sounded like that would work?
> 
> There's really two issues here.  One is that optionally present, but writable,
> registers aren't currently supported well in GDB in my opinion.  The second
> is that the current PowerPC kernel is really buggy with how it handles the
> EBB register set in particular:
> - First of all, there no reason at all why this regset should be optional
>   in the first place; it might as well just be always available.
> - Even so, the test the kernel used to implement the availability check
>   is just broken, it uses the inverse of the test in PTRACE_SETREGSET vs.
>   PTRACE_GETSETRET.
> Because of the latter, I think you'll never be able to complete the
> read-modify-write cycle to write an EBB register via ptrace regsets
> with a current kernel, and so it is effectively read-only anyway.

Are the kernel people aware of these issues?

Thanks,
Pedro Alves


  parent reply	other threads:[~2018-10-26 10:57 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-22 22:33 Pedro Franco de Carvalho
2018-10-22 22:33 ` [PATCH v5 04/12] [PowerPC] Remove rs6000_pseudo_register_reggroup_p Pedro Franco de Carvalho
2018-10-22 22:33 ` [PATCH v5 06/12] [PowerPC] Fix indentation in arch/ppc-linux-common.c Pedro Franco de Carvalho
2018-10-22 22:33 ` [PATCH v5 03/12] Add decfloat registers to float reggroup Pedro Franco de Carvalho
2018-10-22 22:33 ` [PATCH v5 05/12] [PowerPC] Fix two if statements in gdb/ppc-linux-nat.c Pedro Franco de Carvalho
2018-10-22 22:33 ` [PATCH v5 07/12] [PowerPC] Refactor have_ initializers in rs6000-tdep.c Pedro Franco de Carvalho
2018-10-22 22:33 ` [PATCH v5 01/12] Zero-initialize linux note sections Pedro Franco de Carvalho
2018-10-22 22:33 ` [PATCH v5 02/12] [PowerPC] Don't zero-initialize vector register buffers Pedro Franco de Carvalho
2018-10-22 22:54 ` [PATCH v5 10/12] [PowerPC] Add support for EBB and PMU registers Pedro Franco de Carvalho
2018-10-22 22:56 ` [PATCH v5 11/12] [PowerPC] Reject tdescs with VSX and no FPU or Altivec Pedro Franco de Carvalho
2018-10-23 16:05   ` Pedro Alves
2018-10-23 18:46     ` Pedro Franco de Carvalho
2018-10-25 15:45       ` Pedro Alves
2018-10-22 22:58 ` [PATCH v5 09/12] [PowerPC] Add support for TAR Pedro Franco de Carvalho
2018-10-23  2:34   ` Eli Zaretskii
2018-10-23 18:50     ` Pedro Franco de Carvalho
2018-10-22 23:05 ` [PATCH v5 12/12] [PowerPC] Add support for HTM registers Pedro Franco de Carvalho
2019-02-09  5:51   ` Simon Marchi
2019-02-11 19:10     ` Pedro Franco de Carvalho
2018-10-22 23:16 ` [PATCH v5 08/12] [PowerPC] Add support for PPR and DSCR Pedro Franco de Carvalho
2018-10-23 15:37 ` [PATCH v5 00/12] GDB support for more powerpc registers on linux Pedro Alves
2018-10-23 18:42   ` Pedro Franco de Carvalho
2018-10-24 17:59     ` Ulrich Weigand
2018-10-25 20:05       ` Pedro Franco de Carvalho
2018-10-26 11:01         ` Ulrich Weigand
2018-10-26 10:57       ` Pedro Alves [this message]
2018-10-26 11:00         ` Ulrich Weigand
2018-10-26 15:16         ` Pedro Franco de Carvalho
2018-10-29 14:20           ` Regression on old kernels (Re: [PATCH v5 00/12] GDB support for more powerpc registers on linux) Ulrich Weigand

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=0d36db86-2310-ccc7-6575-d6070692933c@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pedromfc@linux.ibm.com \
    --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