kgdb for ppc64 now available

Geoff Levand geoffrey.levand at am.sony.com
Thu Oct 6 07:06:15 EST 2005


Anton Blanchard wrote:
> Hi,
> 
>>For those interested, kgdb now supports ppc64 SMP.  On powermac only
>>an Ethernet connection is supported currently, but generic 8250 UART
>>PCI cards will be supported soon.
> 
> 
> Nice! A few comments:
> 
> +       { 0x0300, 0x0b /* SIGSEGV */ },         /* data access */
> +       { 0x0400, 0x0a /* SIGBUS */  },         /* instruction access */
> 
> 0x380 data segment miss is not in the list of traps.
> 

OK, I put it in as such:

	{ 0x0380, 0x0b /* SIGSEGV */ },		/* data SLB access */

I guess this is better than the default SIGHUP, unless you think there's 
a better one to map to.

> +       return kgdb_handle_exception(0, computeSignal(regs->trap), 0, regs);
> 
> We should use TRAP(regs) instead of regs->trap since the bottom bits may
> not be zero for an exception that only saves a partial register set.

Thanks.

> @@ -2,7 +2,7 @@
>  # Makefile for the linux ppc64 kernel.
>  #
> 
> -EXTRA_CFLAGS   += -mno-minimal-toc
> +#EXTRA_CFLAGS  += -mno-minimal-toc
>  extra-y                := head.o vmlinux.lds
> 
>  obj-y               := setup.o entry.o traps.o irq.o idle.o dma.o \
> 
> Is there a problem with compiling arch/ppc64/kernel -mno-minimal-toc?

There doesn't seem to be any reason for this.  I think it just slipped in 
when someone was hunting for a bug...

> I notice x86-64 is using the new die hooks, Im about to convert xmon
> over to it and once that is done it will make sense to move kgdb and kdb
> across.

Please let me know when you've done this so I can see what's needed.

> In regs_to_gdb_regs it would be nice to send out the dar, dsisr and
> perhaps softe (used on iseries and will be useful once we go to soft
> interrupt disable on pseries). Even though we already get the trap
> number delived to gdb via the signal number, it would be useful to dump
> it in the regs since the bottom bits are important (to work out if
> only a partial register set has been saved). That leaves orig_gpr3 and
> result as the only pt_regs not dumped.

gdb as of version 6.3 doesn't support these regs.  There would need to be 
changes there to support these.  If there is a real demand, I don't think 
it would be much effort to do.

> 
> +       /* vr registers not used by kernel, leave zero */
> +       ptr += 64;
> 
> Now that we use altivec in the kernel a bit, it might make sense to dump
> these registers. Not sure yet.
>
> Index: linux-2.6.13/arch/ppc64/mm/fault.c
> @@ -306,6 +307,13 @@ void bad_page_fault(struct pt_regs *regs
>                 regs->nip = entry->fixup;
>                 return;
>         }
> +#ifdef CONFIG_KGDB
> +       if (atomic_read(&debugger_active) && kgdb_may_fault) {
> +               /* Restore our previous state. */
> +               kgdb_fault_longjmp(kgdb_fault_jmp_regs);
> +               /* Not reached. */
> +       }
> +#endif
> 
> We might need a new notify_die hook to cover this case.
> 
> We could use hardware data breakpoint support in kgdb.
> 
> Eventually it would be nice to be able to select debuggers at
> boot/runtime.

I have no current plans for these last items.

Thanks for the comments, all very helpful.

-Geoff




More information about the Linuxppc64-dev mailing list