[PATCH] Add support for Xtensa

[Denys Vlasenko]

On 03/25/2013 06:29 PM, Chris Zankel wrote:
> Hi Dimitry,
> 
> On 03/22/2013 06:12 PM, Dmitry V. Levin wrote:
>> On Fri, Mar 22, 2013 at 05:09:23PM -0700, Chris Zankel wrote:
>>> It would be great if you could apply the attached patch to add support
>>> for the Xtensa architecture. Xtensa was added to the kernel a long time
>>> ago, and we have kept local patches for strace for a long time, but it
>>> would be easier to support it in the mainline repository.
>> [...]
>>> diff --git a/linux/xtensa/syscallent.h b/linux/xtensa/syscallent.h
>>> new file mode 100644
>>> index 0000000..2ef4fd8
>>> --- /dev/null
>>> +++ b/linux/xtensa/syscallent.h
>>> @@ -0,0 +1,434 @@
>>> +	{ 0,	0,	printargs,		"spill"		}, /* 0 */
>>> +	{ 0,	0,	printargs,		"xtensa"	}, /* 1 */
>>> +	{ MA,	0,	printargs,		"SYS_2"		}, /* 2 */
>>> +	{ MA,	0,	printargs,		"SYS_3"		}, /* 3 */
>>> +	{ MA,	0,	printargs,		"SYS_4"		}, /* 4 */
>>> +	{ MA,	0,	printargs,		"SYS_5"		}, /* 5 */
>>> +	{ MA,	0,	printargs,		"SYS_6"		}, /* 6 */
>>> +	{ MA,	0,	printargs,		"SYS_7"		}, /* 7 */
>> In this and other similar places, please collapse blocks of undefined
>> syscall entries using "[N1 ... N2] = {}" notation.
> In this patch, I removed the trailing unused entries and change the
> above and one other location to the [N1...N2] = {} notation.
> 
>>
>> [...]
>>>  		tcp->u_arg[i] = ((unsigned long *)&metag_regs.dx[3][1])[-i];
>>> +#elif defined(XTENSA)
>>> +	/* arg0: a6, arg1: a3, arg2: a4, arg3: a5, arg4: a8, arg5: a9 */
>>> +	static const int xtensaregs[MAX_ARGS] = { 6, 3, 4, 5, 8, 9 };
>>> +	for (i = 0; i < nargs; ++i)
>>> +		if (upeek(tcp, REG_A_BASE + xtensaregs[i], &tcp->u_arg[i]) < 0)
>>> +			return -1;
>>>
>>> Is there any reason to upeek one register at a time instead of fetching
>>> the whole set using PTRACE_GETREGS or PTRACE_GETREGSET?
>>>
>>>
> I checked again, but couldn't find a good way to use the regset
> directly. As a recap, Xtensa is a configurable processor with a
> variable  number of internal registers, and from the register set, it is
> not always clear where the syscall arguments are without knowing the
> configuration dependent register count. Goal is to fix it with
> getregset, which is currently not supported, so we can eventually
> deprecate the upeek method.

Is there a plan to implement PTRACE_GETREGSET (in kernel)
for this arch?

-- 
vda