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

[Aleksandar Ristovski <aristovski@qnx.com>]

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