[Crash-utility] Faster iteration on list of struct.field

[Dave Anderson]

----- Original Message -----
> Dave Anderson wrote on Wed, Feb 05, 2020:
> > > What might make sense is to use the "struct -r" option, which does a raw
> > > memory dump of a data structure.  But for a reason I do not recall, it
> > > prevents that option from being used with a "struct_name.field" argument.
> > > (see line 6628 of symbols.c).  But I don't see why that couldn't be made
> > > to work, though, since the end result is simply a call to
> > > raw_data_dump().
> 
> I'll give this a try tomorrow, probably just needs to add
> dm->member_offset to addr and dump dm->member_size long value, that
> looks straightforward enough.
> 
> > ...and then if you get "struct -r" to work with a "struct_name.field"
> > argument, the next challenge would be the caching aspect of your request.
> > 
> > Currently there's no manner in which command-specific information is
> > cached beyond the execution of a single command.  With "< file", the
> > command gets executed from scratch each time.
> 
> That does look more challenging... Or rather more a matter of taste? a
> kludge probably wouldn't be so bad to put in, but it's probably better
> to have something more generic than making 'datatype_member' static in
> cmd_datatype_common (well, it needs a bit more than that as the argument
> strings won't be useable from one call to the next...)
>  
> I assume the slow part in this will be the member_to_datatype call in
> do_datatype_addr? I'll first confirm that's the only slow bit, if there
> is only one spot to optimize away it might not be so bad.
> 
> But yeah, without caching I don't think it's realistic; and making the
> '< file' construct iterate within the function looks more work than
> trying to make struct cache some info.
> 
> Thanks!

Right, the time-consumer is the call into gdb to get the structure member details.

I'm not following what you mean by "making 'datatype_member' static ...", but
off the top of my head, I was thinking of adding a "tmp_offset" and "tmp_size"
fields to the global offset_table and size_table structures, and adding a new
pc->curcmd_flags bit.  Then, if a command that wants to support such a concept, 
it could:

  (1) check the new pc->curcmd_flags bit, which will always be 0 the first time
      the function gets called by the exec_args_input_file() loop.
  (2) if the new bit is 0, then set OFFSET(tmp_offset) and SIZE(tmp_size)
  (3) set the new flag in pc->curcmd_flags, and continue...

Then during the second and subsequent times through the loop, pc->curcmd_flags
will still be set/unchanged, because restore_sanity() is not called from the 
exec_args_input_flags() loop.

But that scheme falls down if a user requests a comma-separated list of
multiple members (argc_members would be > 1).  Although, it might be better
if the "struct -r' option rejects multiple-member arguments, especially given
that the output would be pretty much unreadable.

Dave


 
 > --
> Dominique
> 
> 
> --
> Crash-utility mailing list
> Crash-utility at redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>