RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 834260 - struct command should accept option -o even with address specified
Summary: struct command should accept option -o even with address specified
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: crash
Version: 6.2
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Dave Anderson
QA Contact: Guangze Bai
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-21 11:29 UTC by Stanislav Kozina
Modified: 2015-02-08 21:38 UTC (History)
3 users (show)

Fixed In Version: crash-6.0.9-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 08:34:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0317 0 normal SHIPPED_LIVE crash bug fix and enhancement update 2013-02-20 20:54:59 UTC

Description Stanislav Kozina 2012-06-21 11:29:27 UTC
Description of problem:

When printing structure, it would be beneficial to get address of each field in the structure directly without manual adding the address + offset.

Version-Release number of selected component (if applicable):

# rpm -qf `which crash`
crash-5.1.8-1.el6.x86_64
megatron$ rpm -qf `which crash`
crash-6.0.5-0.x86_64

How reproducible:

Always.

Steps to Reproduce:
1. net | grep eth0
2. struct -o net_device ffff880312458020 | head -n 5
3.
  
Actual results:

crash> struct -o net_device ffff880312458020 | head -n 5
struct: -o option not valid with an address argument
struct: -o option not valid with an address argument
struct net_device {
  name = "eth0\000\000\000\000\000\000\000\000\000\000\000", 
  name_hlist = {
    next = 0x0, 

Expected results:

crash> struct net_device 0xffff880312458020 | head -n 5
struct net_device {
  [0xffff880312458020] name = "eth0\000\000\000\000\000\000\000\000\000\000\000", 
  [0xffff880312458030] name_hlist = {
    [0xffff880312458030] next = 0x0, 
    [0xffff880312458038] pprev = 0xffff880317be6890

Additional info:

This would be pretty handy when it's neccessary to follow links in the structures.

Comment 1 Stanislav Kozina 2012-06-21 11:30:59 UTC
> Expected results:
> 
> crash> struct net_device 0xffff880312458020 | head -n 5

Ah, here the command would obviously look like:

crash> struct -o net_device 0xffff880312458020 | head -n 5

Sorry about the typo;-/

Comment 2 Dave Anderson 2012-06-21 13:48:22 UTC
When used with an address, the struct command passes the heavy lifting
off to the embedded gdb module, and the output is straight from gdb.

When used with -o, it has gdb print the structure declaration behind the
scenes, and then walks through the output, doing an ugly parsing operation
trying to pick out strucure members, and as it finds them, queries gdb
for the member's offset, and then pushes it out before the member name.
And it's not always fully-functional, as it sometimes it "misses" some members.

Doing the same for the output of a particular structure with data would
be even uglier.  But with persistance it I suppose it could be done, 
although I'm not particularly excited about doing it.  

What would be interesting to consider as an alternative, would be to 
have "struct -o address" basically do what it does now, but instead of
printing the structure.member offset, push out the member's virtual
address -- but without the contents of the structure.  That would be
relatively easy to implement.

Comment 3 Stanislav Kozina 2012-06-21 14:25:46 UTC
(In reply to comment #2)
> When used with an address, the struct command passes the heavy lifting
> off to the embedded gdb module, and the output is straight from gdb.
> 
> When used with -o, it has gdb print the structure declaration behind the
> scenes, and then walks through the output, doing an ugly parsing operation
> trying to pick out strucure members, and as it finds them, queries gdb
> for the member's offset, and then pushes it out before the member name.
> And it's not always fully-functional, as it sometimes it "misses" some
> members.
> 
> Doing the same for the output of a particular structure with data would
> be even uglier.  But with persistance it I suppose it could be done, 
> although I'm not particularly excited about doing it.

Thank you for the explanation of implementation, I was not aware there is such a difference between processing w/o the address.

> What would be interesting to consider as an alternative, would be to 
> have "struct -o address" basically do what it does now, but instead of
> printing the structure.member offset, push out the member's virtual
> address -- but without the contents of the structure.  That would be
> relatively easy to implement.

This might be actually good compromise - it's definitely better than current behavior, and it would give me what am I searching for.

Comment 4 Dave Anderson 2012-06-21 15:08:57 UTC
> This might be actually good compromise - it's definitely better than
> current behavior, and it would give me what am I searching for.

Cool -- I like the idea as well.  I'll look into it...

Comment 5 Dave Anderson 2012-06-21 20:27:04 UTC
Pretty straight-forward fit -- taking a thread_info struct as an
example, here's the current functionality:
  
  crash> thread_info ffff81002a796000
  struct thread_info {
    task = 0xffff81003ed767e0, 
    exec_domain = 0xffffffff802f78e0, 
    flags = 128, 
    status = 1, 
    cpu = 5, 
    preempt_count = 0, 
    addr_limit = {
      seg = 18446604435732824064
    }, 
    restart_block = {
      fn = 0xffffffff80095a52 <do_no_restart_syscall>, 
      arg0 = 0, 
      arg1 = 0, 
      arg2 = 0, 
      arg3 = 0
    }
  }
  crash> thread_info -o
  struct thread_info {
     [0] struct task_struct *task;
     [8] struct exec_domain *exec_domain;
    [16] __u32 flags;
    [20] __u32 status;
    [24] __u32 cpu;
    [28] int preempt_count;
    [32] mm_segment_t addr_limit;
    [40] struct restart_block restart_block;
  }
  SIZE: 80
  crash> thread_info -ox
  struct thread_info {
     [0x0] struct task_struct *task;
     [0x8] struct exec_domain *exec_domain;
    [0x10] __u32 flags;
    [0x14] __u32 status;
    [0x18] __u32 cpu;
    [0x1c] int preempt_count;
    [0x20] mm_segment_t addr_limit;
    [0x28] struct restart_block restart_block;
  }
  SIZE: 0x50
  crash>

And the new functionality looks like:

  crash> thread_info -o ffff81002a796000
  struct thread_info {
    [ffff81002a796000] struct task_struct *task;
    [ffff81002a796008] struct exec_domain *exec_domain;
    [ffff81002a796010] __u32 flags;
    [ffff81002a796014] __u32 status;
    [ffff81002a796018] __u32 cpu;
    [ffff81002a79601c] int preempt_count;
    [ffff81002a796020] mm_segment_t addr_limit;
    [ffff81002a796028] struct restart_block restart_block;
  }
  SIZE: 80
  crash>

Comment 6 Stanislav Kozina 2012-06-22 10:49:17 UTC
Nice, thank you very much!

> And the new functionality looks like:
> 
>   crash> thread_info -o ffff81002a796000
>   struct thread_info {
>     [ffff81002a796000] struct task_struct *task;
>     [ffff81002a796008] struct exec_domain *exec_domain;
>     [ffff81002a796010] __u32 flags;
>     [ffff81002a796014] __u32 status;
>     [ffff81002a796018] __u32 cpu;
>     [ffff81002a79601c] int preempt_count;
>     [ffff81002a796020] mm_segment_t addr_limit;
>     [ffff81002a796028] struct restart_block restart_block;
>   }
>   SIZE: 80
>   crash>

Comment 7 Dave Anderson 2012-06-22 12:45:51 UTC
(In reply to comment #6)
> Nice, thank you very much!
> 
> > And the new functionality looks like:
> > 
> >   crash> thread_info -o ffff81002a796000
> >   struct thread_info {
> >     [ffff81002a796000] struct task_struct *task;
> >     [ffff81002a796008] struct exec_domain *exec_domain;
> >     [ffff81002a796010] __u32 flags;
> >     [ffff81002a796014] __u32 status;
> >     [ffff81002a796018] __u32 cpu;
> >     [ffff81002a79601c] int preempt_count;
> >     [ffff81002a796020] mm_segment_t addr_limit;
> >     [ffff81002a796028] struct restart_block restart_block;
> >   }
> >   SIZE: 80
> >   crash>

All right -- I'll re-work the help page, and queue it up for crash-6.0.8.

Eventually it will arrive in RHEL6 presuming I can get crash onto the 
RHEL6.4 approved components list.

Comment 16 errata-xmlrpc 2013-02-21 08:34:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0317.html


Note You need to log in before you can comment on or make changes to this bug.