Bug in setbpt/clearbpt for SPARC/SPARC64?

[Denys Vlasenko]

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:
>>> Hi
>>>
>>> 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]) < 0
>>>     || get_arg1(tcp, &state, &tcp->inst[1]) < 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