Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[Rolf Eike Beer]

The last message I had for the crash below is:

Running /var/tmp/portage/sys-devel/gdb-7.12.1/work/gdb-7.12.1/gdb/testsuite/gdb.base/bp-permanent.exp ...

[  909.754182] Backtrace:
[  909.756303] 
[  909.756303] 
[  909.756303] Bad Address (null pointer deref?): Code=6 (Instruction TLB miss fault) regs=000000007c818a50 (Addr=0000000000000000)
[  909.756303] CPU: 0 PID: 5191 Comm: bp-permanent Not tainted 4.13.8 #2
[  909.756303] task: 000000007c8183d0 task.stack: 000000007aad8000
[  909.756303] 
[  909.756303]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
[  909.756303] PSW: 00000000000001000000011100001111 Not tainted
[  909.756303] r00-03  000000000004070f 00000000f8f07840 00000000000106bb 00000000f8f07880
[  909.756303] r04-07  00000000f815bc70 00000000000e87a0 0000000000000000 00000000000e8818
[  909.756303] r08-11  0000000000000000 0000000000000000 000000000000006c 0000000000000000
[  909.756303] r12-15  0000000000000000 0000000000000000 0000000000080a74 00000000000e83f8
[  909.756303] r16-19  00000000000c85c8 00000000000cbad8 00000000000c99e8 00000000f815bc70
[  909.756303] r20-23  00000000000120bc 0000000000000004 ffffffffffffe520 0000000000012022
[  909.756303] r24-27  00000000000120bc 00000000000105d8 00000000000120b8 0000000000012000
[  909.756303] r28-31  00000000000120b8 0000000000000001 00000000f8f078c0 00000000f8bffa9f
[  909.756303] sr00-03  00000000010a1800 00000000010a1800 0000000000000000 00000000010a1800
[  909.756303] sr04-07  00000000010a1800 00000000010a1800 00000000010a1800 00000000010a1800
[  909.756303] 
[  909.756303] IASQ: 00000000010a1800 00000000010a1800 IAOQ: 0000000000000000 0000000000000004
[  909.756303]  IIR: 43ffff80    ISR: 0000000010240000  IOR: 000000a43fb07880
[  909.756303]  CPU:        0   CR30: 000000007aad8000 CR31: ffffffffffffffff
[  909.756303]  ORIG_R28: 0000000000000000
[  909.756303]  IAOQ[0]:           (null)
[  909.756303]  IAOQ[1]: 0x4
[  909.756303]  RP(r2): 0x106bb
[  909.756303] Backtrace:
[  909.756303] 
[  909.756303] Kernel panic - not syncing: Bad Address (null pointer deref?)
[  909.756303] ---[ end Kernel panic - not syncing: Bad Address (null pointer deref?)

This is actually the second place where it breaks, before that I had the same 
with this test (twice):

Running /var/tmp/portage/sys-devel/gdb-7.12.1/work/gdb-7.12.1/gdb/testsuite/gdb.base/async.exp ...

It's a Gentoo system, the kernel has been built with gcc 6.4.0.

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[John David Anglin]

On 2018-01-25 3:59 AM, Rolf Eike Beer wrote:
> [  909.756303] Kernel panic - not syncing: Bad Address (null pointer deref?)
> [  909.756303] ---[ end Kernel panic - not syncing: Bad Address (null pointer deref?)
>
> This is actually the second place where it breaks, before that I had the same
> with this test (twice):
Would you post the PIM dump of the most recent HPMC in the service 
menu?  Also needed
is the assembler dump of the routine where the HPMC occurred in your 
kernel.  You need the
64-bit version of objdump for this.

There's no info in the posted register dump about the panic other than 
it was probably generated
by the exception.

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[Rolf Eike Beer]

John David Anglin wrote:
> On 2018-01-25 3:59 AM, Rolf Eike Beer wrote:
>> [  909.756303] Kernel panic - not syncing: Bad Address (null pointer 
>> deref?)
>> [  909.756303] ---[ end Kernel panic - not syncing: Bad Address (null 
>> pointer deref?)
>> 
>> This is actually the second place where it breaks, before that I had 
>> the same
>> with this test (twice):
> Would you post the PIM dump of the most recent HPMC in the service
> menu?

The service menu does not give any information, as in this older bug: 
https://bugs.gentoo.org/481768

> Also needed
> is the assembler dump of the routine where the HPMC occurred in your
> kernel.  You need the
> 64-bit version of objdump for this.

I have put the kernel on 
https://opensource.sf-tec.de/c8000-kernel.tar.xz

Eike

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[Helge Deller]

On 25.01.2018 16:36, Rolf Eike Beer wrote:
> John David Anglin wrote:
>> On 2018-01-25 3:59 AM, Rolf Eike Beer wrote:
>>> [  909.756303] Kernel panic - not syncing: Bad Address (null pointer deref?)
>>> [  909.756303] ---[ end Kernel panic - not syncing: Bad Address (null pointer deref?)
>>>
>>> This is actually the second place where it breaks, before that I had the same
>>> with this test (twice):
>> Would you post the PIM dump of the most recent HPMC in the service
>> menu?
> 
> The service menu does not give any information, as in this older bug: https://bugs.gentoo.org/481768

FWIW, I've tested the testcase from 
 https://bugs.gentoo.org/481768
on a debian system:
Linux panama.osuosl.org 4.14.0-2-parisc64-smp #1 SMP Debian 4.14.7-1 (2017-12-28) parisc64 GNU/Linux
gdb was version 7.12-6+b1

On debian I can not reproduce the crash.

With this sequence:
(gdb) break gdb-crash.c:14
(gdb) run
(gdb) set tp = {0,0}

tp isn't initialized yet before you reach line 25, and as such it points to random memory.
I you try to set tp, it depends on what happens (but agreed, it shouldn't
crash the kernel).

The Debian kernel hasn't any additional hppa-specific patches.  

>> Also needed
>> is the assembler dump of the routine where the HPMC occurred in your
>> kernel.  You need the
>> 64-bit version of objdump for this.

I wonder why there isn't any kernel backtrace...
Does gentoo uses special compiler-optimization flags?

> I have put the kernel on https://opensource.sf-tec.de/c8000-kernel.tar.xz

I'd suggest you put some debugging code in your kernel, e.g. in
compat_ptrace_request() in kernel/ptrace.c.
I think gdb uses PTRACE_POKEDATA to set some userspace memory of a process.
It's generic code, so I wonder why it should crash on parisc.

You may look at compat_arch_ptrace() in arch/parisc/kernel/ptrace.c too, but
it doesn't touch memory as far as I can see...

Helge

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

Am Freitag, 26. Januar 2018, 23:31:46 schrieb Helge Deller:
> On 25.01.2018 16:36, Rolf Eike Beer wrote:
> > John David Anglin wrote:
> >> On 2018-01-25 3:59 AM, Rolf Eike Beer wrote:
> >>> [  909.756303] Kernel panic - not syncing: Bad Address (null pointer
> >>> deref?) [  909.756303] ---[ end Kernel panic - not syncing: Bad Address
> >>> (null pointer deref?)
> >>> 
> >>> This is actually the second place where it breaks, before that I had the
> >>> same>> 
> >>> with this test (twice):
> >> Would you post the PIM dump of the most recent HPMC in the service
> >> menu?
> > 
> > The service menu does not give any information, as in this older bug:
> > https://bugs.gentoo.org/481768
> FWIW, I've tested the testcase from
>  https://bugs.gentoo.org/481768
> on a debian system:
> Linux panama.osuosl.org 4.14.0-2-parisc64-smp #1 SMP Debian 4.14.7-1
> (2017-12-28) parisc64 GNU/Linux gdb was version 7.12-6+b1
> 
> On debian I can not reproduce the crash.
> 
> With this sequence:
> (gdb) break gdb-crash.c:14
> (gdb) run
> (gdb) set tp = {0,0}
> 
> tp isn't initialized yet before you reach line 25, and as such it points to
> random memory. I you try to set tp, it depends on what happens (but agreed,
> it shouldn't crash the kernel).
> 
> The Debian kernel hasn't any additional hppa-specific patches.

I'm using vanilla, so nothing on my side either.

> >> Also needed
> >> is the assembler dump of the routine where the HPMC occurred in your
> >> kernel.  You need the
> >> 64-bit version of objdump for this.
> 
> I wonder why there isn't any kernel backtrace...

This was with "dmesg -n 8". Without it has shown only the "Bad address" and 
"end Kernel panic" lines, which is IMHO bad by itself.

> Does gentoo uses special compiler-optimization flags?

I have none.

> > I have put the kernel on https://opensource.sf-tec.de/c8000-kernel.tar.xz
> 
> I'd suggest you put some debugging code in your kernel, e.g. in
> compat_ptrace_request() in kernel/ptrace.c.
> I think gdb uses PTRACE_POKEDATA to set some userspace memory of a process.
> It's generic code, so I wonder why it should crash on parisc.
> 
> You may look at compat_arch_ptrace() in arch/parisc/kernel/ptrace.c too, but
> it doesn't touch memory as far as I can see...

I will not be able to touch any of this until at least mid of next week. If 
you want to give it a try, check gdb 7.12.1 testsuite. It was one of the first 
tests that hit this.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[Helge Deller]

Hi Rolf,

On 27.01.2018 18:42, Rolf Eike Beer wrote:
> Am Freitag, 26. Januar 2018, 23:31:46 schrieb Helge Deller:
>> On 25.01.2018 16:36, Rolf Eike Beer wrote:
>>> John David Anglin wrote:
>>>> On 2018-01-25 3:59 AM, Rolf Eike Beer wrote:
>>>>> [  909.756303] Kernel panic - not syncing: Bad Address (null pointer
>>>>> deref?) [  909.756303] ---[ end Kernel panic - not syncing: Bad Address
>>>>> (null pointer deref?)
>>>>>
>>>>> This is actually the second place where it breaks, before that I had the
>>>>> same>> 
>>>>> with this test (twice):
>>>> Would you post the PIM dump of the most recent HPMC in the service
>>>> menu?
>>>
>>> The service menu does not give any information, as in this older bug:
>>> https://bugs.gentoo.org/481768
>> FWIW, I've tested the testcase from
>>  https://bugs.gentoo.org/481768
>> on a debian system:
>> Linux panama.osuosl.org 4.14.0-2-parisc64-smp #1 SMP Debian 4.14.7-1
>> (2017-12-28) parisc64 GNU/Linux gdb was version 7.12-6+b1
>>
>> On debian I can not reproduce the crash.
>>
>> With this sequence:
>> (gdb) break gdb-crash.c:14
>> (gdb) run
>> (gdb) set tp = {0,0}
>>
>> tp isn't initialized yet before you reach line 25, and as such it points to
>> random memory. I you try to set tp, it depends on what happens (but agreed,
>> it shouldn't crash the kernel).
>>
>> The Debian kernel hasn't any additional hppa-specific patches.
> 
> I'm using vanilla, so nothing on my side either.
> 
>>>> Also needed
>>>> is the assembler dump of the routine where the HPMC occurred in your
>>>> kernel.  You need the
>>>> 64-bit version of objdump for this.
>>
>> I wonder why there isn't any kernel backtrace...
> 
> This was with "dmesg -n 8". Without it has shown only the "Bad address" and 
> "end Kernel panic" lines, which is IMHO bad by itself.
> 
>> Does gentoo uses special compiler-optimization flags?
> 
> I have none.
> 
>>> I have put the kernel on https://opensource.sf-tec.de/c8000-kernel.tar.xz
>>
>> I'd suggest you put some debugging code in your kernel, e.g. in
>> compat_ptrace_request() in kernel/ptrace.c.
>> I think gdb uses PTRACE_POKEDATA to set some userspace memory of a process.
>> It's generic code, so I wonder why it should crash on parisc.
>>
>> You may look at compat_arch_ptrace() in arch/parisc/kernel/ptrace.c too, but
>> it doesn't touch memory as far as I can see...
> 
> I will not be able to touch any of this until at least mid of next week. If 
> you want to give it a try, check gdb 7.12.1 testsuite. It was one of the first 
> tests that hit this.

As I said before, I can't reproduce this on debian.
gdb does not (and never has) crash(ed) the system, as can be seen in the various build logs:
 https://buildd.debian.org/status/logs.php?pkg=gdb&arch=hppa
e.g.:
 https://buildd.debian.org/status/fetch.php?pkg=gdb&arch=hppa&ver=7.12-6%2Bb1&stamp=1507997688&raw=0

Helge

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[John David Anglin]

On 2018-01-27 1:41 PM, Helge Deller wrote:
> As I said before, I can't reproduce this on debian.
> gdb does not (and never has) crash(ed) the system, as can be seen in the various build logs:
>   https://buildd.debian.org/status/logs.php?pkg=gdb&arch=hppa
I just built binutils-gdb trunk successfully.

Dave

-- 
John David Anglin  dave.anglin@bell.net

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 448 bytes --]

Am Donnerstag, 25. Januar 2018, 09:59:03 CEST schrieb Rolf Eike Beer:
> The last message I had for the crash below is:
> 
> Running
> /var/tmp/portage/sys-devel/gdb-7.12.1/work/gdb-7.12.1/gdb/testsuite/gdb.bas
> e/bp-permanent.exp ...

I just have been told it's still happening with the gdb 8.3 testsuite on the 
Gentoo test machine:

Linux hake 4.19.52-gentoo #2 Tue Jun 18 13:51:01 EDT 2019 parisc PA8600 (PCX-W
+) 9000/785/C3600 GNU/Linux

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

Am Sonntag, 30. Juni 2019, 12:05:46 CEST schrieb Rolf Eike Beer:
> Am Donnerstag, 25. Januar 2018, 09:59:03 CEST schrieb Rolf Eike Beer:
> > The last message I had for the crash below is:
> > 
> > Running
> > /var/tmp/portage/sys-devel/gdb-7.12.1/work/gdb-7.12.1/gdb/testsuite/gdb.ba
> > s
> > e/bp-permanent.exp ...
> 
> I just have been told it's still happening with the gdb 8.3 testsuite on the
> Gentoo test machine:
> 
> Linux hake 4.19.52-gentoo #2 Tue Jun 18 13:51:01 EDT 2019 parisc PA8600
> (PCX-W +) 9000/785/C3600 GNU/Linux

This seems to be a minimal reproducer:

https://481768.bugs.gentoo.org/attachment.cgi?id=361728

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[Helge Deller]

On 30.06.19 15:43, Rolf Eike Beer wrote:
> Am Sonntag, 30. Juni 2019, 12:05:46 CEST schrieb Rolf Eike Beer:
>> Am Donnerstag, 25. Januar 2018, 09:59:03 CEST schrieb Rolf Eike Beer:
>>> The last message I had for the crash below is:
>>>
>>> Running
>>> /var/tmp/portage/sys-devel/gdb-7.12.1/work/gdb-7.12.1/gdb/testsuite/gdb.ba
>>> s
>>> e/bp-permanent.exp ...
>>
>> I just have been told it's still happening with the gdb 8.3 testsuite on the
>> Gentoo test machine:
>>
>> Linux hake 4.19.52-gentoo #2 Tue Jun 18 13:51:01 EDT 2019 parisc PA8600
>> (PCX-W +) 9000/785/C3600 GNU/Linux
>
> This seems to be a minimal reproducer:
> https://481768.bugs.gentoo.org/attachment.cgi?id=361728

It doesn't crash for me on debian (other kernel, other userspace, older gdb).
But there is something fishy anyway.
It seems the "set tp = {0,0}" doesn't work as expected.
gdb prints the set zero-values correctly, but it doesn't seem to be stored correctly to memory.
"set tp.a = 10" does work though.

Helge

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[Helge Deller]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

>> This seems to be a minimal reproducer:
>> https://481768.bugs.gentoo.org/attachment.cgi?id=361728

That's a REALLY nasty bug!
I see at least two issues here: A Linux kernel bug and a gdb (userspace) bug.

The kernel bug is, that a userspace process (running gdb) is able to crash the machine.
The attached patch does fix the crashes by preventing userspace to change IAOQ values to point to the gateway page.
This is what made the kernel crash, which probably happened, when the kernel tried to switch_to() the process.
I'm still trying to figure out if there is a better patch, e.g. in the switch_to() function or similar.
So, I don't think it's the final patch.
Anyway, this patch can help to figure out what's else going wrong.

Then, the second issue is:
In gdb this crashes the machine: "set tp = { 0,0 }".
Correct would be: "set *tp = { 0,0 }", which does NOT crash the kernel and works correctly.
So, for the first test it seems that gdb tries to create a temporary variable on the stack for "tp" in the user process.
For that gdb analyzes the code and thus somehow starts executing the attached process.
I think some gdb-expert might be able to fix this, esp. since gdb now prints:
: The program being debugged stopped while in a function called from GDB.
: Evaluation of the expression containing the function
: (malloc) will be abandoned.
: When the function is done executing, GDB will silently stop.
Maybe gdb tries to call the "malloc" function to allocate memory?

gdb uses ptrace() to control the attached process. So, adding a
  printk("PTRACE_REQUEST_PARISC  req=0x%lx  addr=0x%lx  data=0x%lx\n", request, addr, data);
to arch_ptrace() in arch/parisc/kernel/ptrace.c helps to debug what gdb does.

Helge

[-- Attachment #2: p1 --]
[-- Type: text/plain, Size: 1371 bytes --]

diff --git a/arch/parisc/kernel/ptrace.c b/arch/parisc/kernel/ptrace.c
index a3d2fb4e6dd2..1b1af8a6508f 100644
--- a/arch/parisc/kernel/ptrace.c
+++ b/arch/parisc/kernel/ptrace.c
@@ -167,6 +175,14 @@ long arch_ptrace(struct task_struct *child, long request,
 		if ((addr & (sizeof(unsigned long)-1)) ||
 		     addr >= sizeof(struct pt_regs))
 			break;
+		/* Do not allow userspace to set IAOQ to gateway page. */
+		if (addr == PT_IAOQ0 || addr == PT_IAOQ1) {
+			if (data < GATEWAY_PAGE_SIZE) {
+				ret = 0; // return sucess to not disturb gdb
+				// printk("UGH!!!!!!!!!!!!!!!!!!!!\n");
+				break;
+			}
+		}
 		if ((addr >= PT_GR1 && addr <= PT_GR31) ||
 				addr == PT_IAOQ0 || addr == PT_IAOQ1 ||
 				(addr >= PT_FR0 && addr <= PT_FR31 + 4) ||
@@ -281,6 +297,14 @@ long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
 			addr = translate_usr_offset(addr);
 			if (addr >= sizeof(struct pt_regs))
 				break;
+			/* Do not allow userspace to set IAOQ to gateway page. */
+			if (addr == PT_IAOQ0 || addr == PT_IAOQ1) {
+				if (data < GATEWAY_PAGE_SIZE) {
+					ret = 0; // return sucess to not disturb gdb
+					// printk("UGH!!!!!!!!!!!!!!!!!!!!\n");
+					break;
+				}
+			}
 			if (addr >= PT_FR0 && addr <= PT_FR31 + 4) {
 				/* Special case, fp regs are 64 bits anyway */
 				*(__u64 *) ((char *) task_regs(child) + addr) = data;

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[Helge Deller]

Hi Rolf,

On 02.07.19 17:59, Helge Deller wrote:
>>> This seems to be a minimal reproducer:
>>> https://481768.bugs.gentoo.org/attachment.cgi?id=361728
>
> That's a REALLY nasty bug!

I think I finally fixed the issues for 32- and 64-bit kernels.

Can you please test the three patches in my ptrace-bugfix3 git tree?
https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/log/?h=ptrace-bugfix3

Helge

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[Rolf Eike Beer]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

Helge wrote:
> Hi Rolf,
> 
> On 02.07.19 17:59, Helge Deller wrote:
> >>> This seems to be a minimal reproducer:
> >>> https://481768.bugs.gentoo.org/attachment.cgi?id=361728
> > 
> > That's a REALLY nasty bug!
> 
> I think I finally fixed the issues for 32- and 64-bit kernels.
> 
> Can you please test the three patches in my ptrace-bugfix3 git tree?
> https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/log/
> ?h=ptrace-bugfix3

I applied them on top of 5.2.0 and tested it on my C8000, it survived the 
whole gdb 8.1.2 testsuite. The results are horrible, but the machine is still 
up and running, just a couple of these:

[ 4481.730278] INEQUIVALENT ALIASES 0x41000000 and 0x42e81000 in file kill-
detach-inferiors-cmd
[ 8944.224759] INEQUIVALENT ALIASES 0x41ed2000 and 0x4171c000 in file multi-
attach

So feel free to add my Tested-by.

Eike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[John David Anglin]

[-- Attachment #1.1: Type: text/plain, Size: 715 bytes --]

On 2019-07-17 1:52 p.m., Rolf Eike Beer wrote:
> I applied them on top of 5.2.0 and tested it on my C8000, it survived the 
> whole gdb 8.1.2 testsuite. The results are horrible, but the machine is still 
> up and running, just a couple of these:
Sadly, it hasn't been maintained for years.
>
> [ 4481.730278] INEQUIVALENT ALIASES 0x41000000 and 0x42e81000 in file kill-
> detach-inferiors-cmd
> [ 8944.224759] INEQUIVALENT ALIASES 0x41ed2000 and 0x4171c000 in file multi-
> attach
Theoretically, these could crash machine.  It would be useful to try to debug how they occur.
I would guess it's a mmap issue.  It shouldn't happen with linker.

Dave

-- 
John David Anglin  dave.anglin@bell.net



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Running the gdb 7.12.1 testsuite breaks kernel 4.13.8 on C8000

[Helge Deller]

On 17.07.19 19:52, Rolf Eike Beer wrote:
> Helge wrote:
>> Hi Rolf,
>>
>> On 02.07.19 17:59, Helge Deller wrote:
>>>>> This seems to be a minimal reproducer:
>>>>> https://481768.bugs.gentoo.org/attachment.cgi?id=361728
>>>
>>> That's a REALLY nasty bug!
>>
>> I think I finally fixed the issues for 32- and 64-bit kernels.
>>
>> Can you please test the three patches in my ptrace-bugfix3 git tree?
>> https://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git/log/
>> ?h=ptrace-bugfix3
>
> I applied them on top of 5.2.0 and tested it on my C8000, it survived the
> whole gdb 8.1.2 testsuite.

Great. Thanks for testing.

> The results are horrible, but the machine is still
> up and running, just a couple of these:
>
> [ 4481.730278] INEQUIVALENT ALIASES 0x41000000 and 0x42e81000 in file kill-
> detach-inferiors-cmd
> [ 8944.224759] INEQUIVALENT ALIASES 0x41ed2000 and 0x4171c000 in file multi-
> attach

Usually those are uncritical.

> So feel free to add my Tested-by.

I'll do.

Helge