This is the mail archive of the gdb@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: ARM EABI Linux, breakpoints cause SIGILL and target dies


Nicholas Sherlock wrote:

> So, I patched this line in infrun.c which is supposed to check that
> the SIGILL was caused by a breakpoint:
> 
>       if (breakpoint_inserted_here_p (get_regcache_aspace (regcache),
> 				      regcache_read_pc (regcache)))
> 
> And changed it to:
> 
>       if (ecs->ws.value.sig == TARGET_SIGNAL_ILL ||
> breakpoint_inserted_here_p (get_regcache_aspace (regcache),
> 				      regcache_read_pc (regcache)))
> 
> Now the signal is corrected reinterpreted as SIGTRAP:
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x000081f6 in main () at test.c:4
> 4         printf("Hello, world!\n");
> 
> But the break address is incorrect, it's halfway through the code for
> calling printf:
> 
>     81f4:       f24b 60a4       movw    r0, #46756      ; 0xb6a4
>     81f8:       f2c0 0004       movt    r0, #4
>     81fc:       f000 fce8       bl      8bd0 <_IO_puts>

This is quite odd; it reports a breakpoint in the middle of a
Thumb-2 instruction.  On ARM, the *kernel* is supposed to adjust the
PC so that it points to the start of the breakpoint instructions.

If this does not work correctly for some reason, this would explain
both why GDB doesn't recognize the situation *and* also why the
kernel doesn't recognize the breakpoint instruction to convert the
signal into a SIGTRAP.

> So now I'm trying to fix the code for adjusting the PC after the trap.

GDB is not supposed to do any adjusting on ARM, this is done by the kernel;
see e.g. arch/arm/traps.c:

asmlinkage void __exception do_undefinstr(struct pt_regs *regs)
{
        unsigned int correction = thumb_mode(regs) ? 2 : 4;
        unsigned int instr;
        siginfo_t info;
        void __user *pc;

        /*
         * According to the ARM ARM, PC is 2 or 4 bytes ahead,
         * depending whether we're in Thumb mode or not.
         * Correct this offset.
         */
        regs->ARM_pc -= correction;


Do you see any differences either here in traps.c, or in one of the
entry-*.S assembler files, between your two kernels?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


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