Bug 244152

+++ This bug was initially created as a clone of Bug #243816 +++

Escalated to Bugzilla from IssueTracker

-- Additional comment from tao on 2007-06-12 00:10 EST --
Hi Folks,

Wehn doing analysis using the ESP and EIP values in ps under 64-bit RHEL 4.4. I
seem top only see the low 32-bits of the addreses when using "ps -e -o eip,esp".

Should this have been extended or  are there plans to introduce new namely
fields so as not to break perceived API's?

Thanks for your help.

Kind regards,

Ken.
This event sent from IssueTracker by csnook  [SEG - Base OS]
 issue 115947

-- Additional comment from tao on 2007-06-12 00:10 EST --
Just to confirm, so far as I can tell it's indeed the case here and I
don't see any obvious way to change the behavior nor alternate variables
for it. Passing up for review.

<snip>
[root@dl585 ~]# ps -e -o pid,eip,esp
  PID      EIP      ESP
    1 7cbbf8f5 ffffffff
    2 00000000 00000000
    3 00000000 00000000
<snip>
 4307 7cbb9272 ffffffff
 6839 7cbb9272 ffffffff
 8419 7cb8f7a2 ffffffff
 8509 ffffe405 ffffffff
 8761 7cbb9272 ffffffff
</snip>

Nor is it any different on RHEL5:

<snip>
[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST
2007 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]#  ps -e -o pid,eip,esp
  PID      EIP      ESP
    1 a62c6b93 ffffffff
    2 00000000 00000000
    3 00000000 00000000
<snip>
28385 00000000 00000000
28386 00000000 00000000
28389 aafa3b93 ffffffff
29357 a62bfc80 ffffffff
30741 00000000 00000000
</snip>



Issue escalated to Support Engineering Group by: fhirtz.
Internal Status set to 'Waiting on SEG'

This event sent from IssueTracker by csnook  [SEG - Base OS]
 issue 115947

-- Additional comment from tao on 2007-06-12 00:10 EST --
The kernel puts the 64-bit value in /proc/<pid>/stat.
Issue moved from 'SEG - Kernel' to 'SEG - Base OS' by: streeter
This event sent from IssueTracker by csnook  [SEG - Base OS]
 issue 115947

-- Additional comment from tao on 2007-06-12 00:10 EST --
ps deliberately casts those values to unsigned int and formats them to 8
digits.  I'm not sure if that's a bug or that's deliberate to avoid
breaking scripts.  I'll check with our maintainers.

Category set to: Applications::Functions
Ticket type set to: 'Problem'

This event sent from IssueTracker by csnook  [SEG - Base OS]
 issue 115947

-- Additional comment from tao on 2007-06-12 00:19 EST --
Excerpts from output.c in the procps source package:

return snprintf(outbuf, COLWID, "%08x", (unsigned)(pp->kstk_eip));

return snprintf(outbuf, COLWID, "%08x", (unsigned)(pp->kstk_esp));

Clearly this is an intentional cast to a 32-bit integer.  Either we need
to change this to an unsigned long, or we need to introduce eip64 and
esp64 fields so users can get this info conveniently in ps.


Issue escalated to RHEL 4 Base OS by: csnook.
Internal Status set to 'Waiting on Engineering'

This event sent from IssueTracker by csnook 
 issue 115947

-- Additional comment from tsmetana on 2007-06-13 07:44 EST --
I have prepared a patch that adds eip64 and esp64 specifiers that output 16
characters wide columns with 64bit pointers.

-- Additional comment from pm-rhel on 2007-06-13 08:04 EST --
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.