This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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 v5 00/12] GDB support for more powerpc registers on linux


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


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