diff mbox

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

Message ID 5626721A.5060808@qnx.com
State New, archived
Headers

Commit Message

Aleksandar Ristovski Oct. 20, 2015, 4:55 p.m. UTC 
  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.
          /* 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

Comments

Pedro Alves Oct. 20, 2015, 5:12 p.m. UTC | #1 
On 10/20/2015 05:55 PM, Aleksandar Ristovski wrote:

>>>> [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.

Certainly, that's fine.

Thanks,
Pedro Alves
Aleksandar Ristovski Oct. 20, 2015, 5:13 p.m. UTC | #2 
On 15-10-20 12:55 PM, Aleksandar Ristovski wrote:
> 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.
>

Pushed now.

Thank you,

Aleksandar Ristovski
diff mbox

Patch

--- 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;