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.

I will add something to the commit log.
"Fix 'info auxv' for nto."


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

(gdb) PASS: gdb.base/auxv.exp: continue
info auxv^M
3    AT_PHDR              Program headers for program    0x8048034^M
4    AT_PHENT             Size of program header entry   32^M
5    AT_PHNUM             Number of program headers      8^M
9    AT_ENTRY             Entry point of program         0x8048668^M
6    AT_PAGESZ            System page size               4096^M
7    AT_BASE              Base address of interpreter    0xb0300000^M
12   AT_EUID              Effective user ID              2050^M
13   AT_GID               Real group ID                  3221225482^M
47   ???                                                 0x8047f7d^M
WARNING: Unrecognized tag value: 47   ???
                  0x8047f7d^M

(gdb) FAIL: gdb.base/auxv.exp: info auxv on live process


> On 10/20/2015 03:28 PM, Aleksandar Ristovski wrote:
>> gdb/ChangeLog:
>>
>> 	* nto-procfs.c (sys/auxv.h): Include.
>> 	(procfs_xfer_partial): Implement TARGET_OBJECT_AUXV.
>> 	* gdb/nto-tdep.c (nto_read_auxv_from_initial_stack): New function.
>> 	* gdb/nto-tdep.h (nto_read_auxv_from_initial_stack): New declaration.
> 
> Drop the "gdb/" in the file paths.
> 

Ok, sorry. Used 'mklog' script and didn't remove gdb/.

>> @@ -885,6 +887,40 @@ procfs_xfer_partial (struct target_ops *ops, enum target_object object,
>>      {
...
>> +	  /* Similar as in the case of a core file, we read auxv from
>> +	     initial_stack.  */
> 
> Hmm, where's this "similar" you refer to?  AFAICS, for cores, BFD
> extracts it from the NT_AUVX note.

We don't dump it in the note, we dump initial stack page containing it.

> 
>> +	  initial_stack = procinfo.initial_stack;
>> +
>> +	  /* procfs is always 'self-hosted', no byte-order manipulation. */
> 
> Double-space after period.
> 

Ok.

> Otherwise looks OK.
> 

Attaching the patch with double-space fix and added "what was fixed" in
commit message.


Thank you,

Aleksandar Ristovski