Le 19/08/2016 à 13:14, Holger Brunck a écrit :
On 19/08/16 13:03, Christophe Leroy wrote:
Le 17/08/2016 à 17:27, Holger Brunck a écrit :
On 16/08/16 19:27, christophe leroy wrote:
Le 15/08/2016 à 18:19, Dave Hansen a écrit :
On 08/15/2016 07:35 AM, Holger Brunck wrote:
I tried this but unfortunately the error only occurs while remote debugging.
Locally with gdb everything works fine. BTW we double-checked with a 85xx ppc
target which is also 32-bit and it ends up with the same behaviour.
I was also investigating where I have to move the line in the struct task_struct
and it turns out to be like this (diff to 4.7 kernel):
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 253538f..4868874 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1655,7 +1655,9 @@ struct task_struct {
struct signal_struct *signal;
struct sighand_struct *sighand;
+ // struct thread_struct thread; // until here everything is fine
sigset_t blocked, real_blocked;
+ struct thread_struct thread; // from here it's broken
sigset_t saved_sigmask; /* restored if set_restore_sigmask() was used */
struct sigpending pending;
Wow, thanks for all the debugging here!
So, we know it has to do with signals, thread_info, and probably only
affects 32-bit powerpc. Seems awfully weird. Have you checked with any
of the 64-bit powerpc guys to see if they have any ideas?
I went grepping around for a bit.
Where is the task_struct stored? Is it on-stack on ppc32 or something?
The thread_info is, I assume, but I see some THREAD_INFO vs. THREAD
(thread struct) math happening in here, which confuses me:
.globl ret_from_debug_exc
ret_from_debug_exc:
mfspr r9,SPRN_SPRG_THREAD
lwz r10,SAVED_KSP_LIMIT(r1)
stw r10,KSP_LIMIT(r9)
lwz r9,THREAD_INFO-THREAD(r9)
CURRENT_THREAD_INFO(r10, r1)
lwz r10,TI_PREEMPT(r10)
stw r10,TI_PREEMPT(r9)
RESTORE_xSRR(SRR0,SRR1);
RESTORE_xSRR(CSRR0,CSRR1);
RESTORE_MMU_REGS;
RET_FROM_EXC_LEVEL(SPRN_DSRR0, SPRN_DSRR1, PPC_RFDI)
But, I'm really at a loss to explain this. It still seems like a deeply
ppc-specific issue. We can obviously work around it with an #ifdef for
your platform, but that's awfully hackish and hides the real bug,
whatever it is.
My suspicion is that there's a bug in the 32-bit ppc assembly somewhere.
I don't see any references to 'blocked' or 'real_blocked' in assembly
though. You could add a bunch of padding instead of moving the
thread_struct and see if that does anything, but that's really a stab in
the dark.
Just to let you know, I'm not sure it is the same issue, but I also get
my 8xx target stuck when I try to use gdbserver.
If I debug a very small app, it gets stuck quickly after the app has
stopped: indeed, the console seems ok but as soon as I try to execute
something simple, like a ps or top, it get stuck. The target still
responds to pings, but nothing else.
If I debug a big app, it gets stuck soon after the start of debug: I set
a bpoint at main(), do a 'continue', get breaked at main(), do some
steps with 'next' then it gets stuck.
I have tried moving the struct thread_struct thread but it has no impact.
that sounds a bit different to what I see. Is your program also mutli-threaded?
Maybe you could try with the program I use to reproduce the error:
--- snip -----
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
void * th_1_func()
{
while (1) {
sleep(2);
printf("Hello from thread function 1)\n");
}
}
int main() {
int err;
pthread_t th_1, th_2, th_3;
err = pthread_create(&th_1, NULL, th_1_func, NULL);
if (err != 0)
printf("pthread_create\n");
err = pthread_create(&th_2, NULL, th_1_func, NULL);
if (err != 0)
printf("pthread_create\n");
err = pthread_create(&th_3, NULL, th_1_func, NULL);
if (err != 0)
printf("pthread_create\n");
while(1) {}
return 0;
}
--- snap ---
Then copy it to your target and start it with the gdbserver. If you let it run
from your host with gdb and try to stop it e.g in the sleep call and then try to
single step it you might see the error. But as I said in this thread the
behaviour might be different depending on your kernel configuration as I
encountered different behaviour when enabling FTRACE or SCHED_STAT.
Best regards
Holger
Hi
I just tried it on an 885 and on an 8323, it work properly on both targets.
You can see below the Debug Option that are active on my 8323 target.
thanks for trying it.
Could you completely disable FTRACE? As it also works on my side when I have
FTRACE enabled.
Best regards
Holger
I have now disabled completly FTRACE, the behaviour is still OK.
Christophe
