From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: n.sherlock@gmail.com (Nicholas Sherlock)
Cc: gdb@sourceware.org
Subject: Re: ARM EABI Linux, breakpoints cause SIGILL and target dies
Date: Mon, 23 Jan 2012 13:29:00 -0000 [thread overview]
Message-ID: <201201231329.q0NDTGAR004332@d06av02.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <CADwwaza3w48QX8SsEicGOxD7ek6jQbY-i_7GiSipWCaQcZWoBw@mail.gmail.com> from "Nicholas Sherlock" at Jan 23, 2012 02:28:34 PM
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
next prev parent reply other threads:[~2012-01-23 13:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CADwwazYuWuicgqL=4JyxbdoN+6MmVg354bD6UTzC=Ew-po8JzA@mail.gmail.com>
2012-01-20 2:45 ` Nicholas Sherlock
2012-01-20 10:45 ` Ulrich Weigand
2012-01-22 23:34 ` Nicholas Sherlock
2012-01-23 1:29 ` Nicholas Sherlock
2012-01-23 13:29 ` Ulrich Weigand [this message]
2012-01-24 2:44 ` Nicholas Sherlock
2012-01-24 3:02 ` Nicholas Sherlock
2012-01-24 13:37 ` Ulrich Weigand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201201231329.q0NDTGAR004332@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb@sourceware.org \
--cc=n.sherlock@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).