Bug in setbpt/clearbpt for SPARC/SPARC64?
dvlasenk at redhat.com
Tue Feb 5 16:21:15 UTC 2013
On 02/05/2013 02:52 PM, James Hogan wrote:
> On 05/02/13 13:29, Denys Vlasenko wrote:
>> On 11/28/2012 02:14 PM, James Hogan wrote:
>>> While implementing regset support in strace for the metag architecture,
>>> I think I've noticed a problem in util.c.
>>> For SPARC/SPARC64, arg_setup and arg_finish_change are defined to use
>>> PTRACE_GETREGS and PTRACE_SETREGS. However change_syscall also does a
>>> read-modify-write using PTRACE_GETREGS and PTRACE_SETREGS.
>>> These are then combined in a bad way in setbpt:
>>> if (arg_setup(tcp, &state) < 0
>>> /* reads the registers into state */
>>> || get_arg0(tcp, &state, &tcp->inst) < 0
>>> || get_arg1(tcp, &state, &tcp->inst) < 0
>>> /* reads arguments from state */
>>> || change_syscall(tcp, clone_scno[current_personality]) < 0
>>> /* reads registers again, and changes one of them */
>>> || set_arg0(tcp, &state, CLONE_PTRACE|SIGCHLD) < 0
>>> || set_arg1(tcp, &state, 0) < 0
>>> /* sets argument registers in state */
>>> || arg_finish_change(tcp, &state) < 0)
>>> /* writes back state, presumably undoing change_syscall's hard work. */
>>> Looking at a "git diff v4.7..master util.c", it looks like clearbpt is
>>> doing something similar too.
>>> Is that analysis correct or have I missed something important that would
>>> make it work?
>> setbpt/clearbpt is not supposed to be used when run on any non-ancient
>> Linux kernel. It was a hack used to work around problems with attaching
>> to forked children. Now kernel catches them for us:
> Thanks for the info. How old is "ancient"? It sounds like setbrk and
> clearbrk can become no-ops for new architectures merged into Linux (e.g.
> those exclusively using regsets).
Since Linux 2.5.46
More information about the Strace-devel