This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/3] (patch 2/4, v2) [nto] Implement TARGET_OBJECT_AUXV.
- From: Aleksandar Ristovski <aristovski at qnx dot com>
- To: Pedro Alves <palves at redhat dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Tue, 20 Oct 2015 12:55:54 -0400
- Subject: Re: [PATCH 2/3] (patch 2/4, v2) [nto] Implement TARGET_OBJECT_AUXV.
- Authentication-results: sourceware.org; auth=none
- Newsgroups: gmane.comp.gdb.patches
- References: <56263FED dot 3050602 at redhat dot com> <1445351294-18179-1-git-send-email-aristovski at qnx dot com> <1445351294-18179-3-git-send-email-aristovski at qnx dot com> <56265BB2 dot 6060204 at redhat dot com> <562660E9 dot 7000000 at qnx dot com> <562665DE dot 1030104 at redhat dot 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