Re: [PATCH 2/3] (patch 2/4, v2) [nto] Implement TARGET_OBJECT_AUXV.

Aleksandar Ristovski
2015-10-20T16:55:59Z

On 15-10-20 12:03 PM, Pedro Alves wrote:
> On 10/20/2015 04:42 PM, Aleksandar Ristovski wrote:
>> On 15-10-20 11:20 AM, Pedro Alves wrote:
>>> Does this result in any visible improvement? I assume that
>>> at least, "info auxv" now works [1] [2]. It'd be really nice to have a
>>> blurb in the commit log mentioning what motivated this.
>>
>> Yes, info auxv works on a live process. For the core I have other
>> patches that need to go in first, but the mechanism of getting auxv
>> remains the same; only determining initial stack changes.
>
> OK, but please clarify or drop the misleading comment until
> those patches go in then. Please push with that fixed.

Comment dropped.
--- a/gdb/nto-procfs.c
+++ b/gdb/nto-procfs.c
@@ -934,8 +934,6 @@ procfs_xfer_partial (struct target_ops *ops, enum
target_object object,
if (err != EOK)
return TARGET_XFER_E_IO;

- /* Similar as in the case of a core file, we read auxv from
- initial_stack. */
initial_stack = procinfo.initial_stack;

/* procfs is always 'self-hosted', no byte-order manipulation. */

>
>>
>> I will add something to the commit log.
>> "Fix 'info auxv' for nto."
>
> Thanks.
>
>>> [1] - BTW, if you enable gdb.base/auxv.exp on NTO, does it pass?
>>>
>>
>> It fails since we have AT_* entries that are specific to nto, and get
>> printed as ??? which causes regex to not match. I have it patched
>> internally and print them out, but didn't think it would be acceptable
>> upstream.
>
> Why wouldn't it? If the issue is that the numbers conflict with other
> ports, then it can be handled with a gdbarch method.

We have added tags with neutrino specific meanings. I'll address that
later if that's ok with you.

Thanks,

Aleksandar Ristovski