[Crash-utility] Support for crash running on an ARM 32 bit host analyzing ARM 32 bit crash files? Looking unlikely. :(
Hi Dave: I tried to build crash-utility to run on a 32 bit ARM to analyze 32 bit ARM crash dumps. On looking at the Make file it appeared that ARM is supported. # # Supported targets: X86 ALPHA PPC IA64 PPC64 SPARC64 # TARGET and GDB_CONF_FLAGS will be configured automatically by configure # I was a bit disappointed. ☹ Any hope (in the future perhaps)? -piet -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] Faster iteration on list of struct.field
Dave Anderson wrote on Thu, Feb 06, 2020: > 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. I would tend to agree with that, struct -r with multiple members might be somewhat parsable but if someone can do that they can dump the whole struct and parse it anyway, so let's go with only one number. On the good news though, this whole caching isn't going to be immediately needed. I just finished the first part of this (allowing struct -r with a member), and struct -r is already infinitely faster than struct; so getting the offset wasn't the slow part: - with a small 100-elements file, I'm already going down from 12s to near-instant on this old laptop. - I didn't wait for 1000-elements to finish normally but it's just about one second with -r, which is acceptable enough for me. Caching might make it another order of magnitude faster but for now I'm happy to wait a couple of minutes for my 100k elements list, it's better than not finishing in half an hour :) Following up with patch, with a couple of remarks: - I had to change member_to_datatype() to use datatype_info() directly instead of MEMBER_OFFSET(), to fill dm->member_size. I'm not sure if this will have any side effects, but things like 'struct foo.a,b' still work at least. You might have a better idea of what to check. - I'm only passing ANON_MEMBER_QUERY to member_to_datatype() in the non-raw case. I'm not quite sure why we couldn't get the member size if it's an anon union/stuct, but I'm not sure how one would name an anonymous field in the first place here? Anyway, one would get invalid data structure reference message there if they do. It might be better to always pass the argument and then check for SHOW_RAW_DATA set with dm->member_size still being 0 after call to give another more appropriate error if you think people might hit that. Anyway, thanks for the advices. -- Dominique -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
[Crash-utility] [PATCH] allow struct -r with a single member-specific output
---
symbols.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/symbols.c b/symbols.c
index f04e8b5..f030179 100644
--- a/symbols.c
+++ b/symbols.c
@@ -6617,17 +6617,17 @@ do_datatype_addr(struct datatype_member *dm, ulong
addr, int count,
i = 0;
do {
if (argc_members) {
+ if (argc_members > 1 && flags & SHOW_RAW_DATA)
+ error(FATAL,
+ "only up to one member-specific
output allowed with -r\n");
/* This call works fine with fields
* of the second, third, ... levels.
* There is no need to fix it
*/
if (!member_to_datatype(memberlist[i], dm,
- ANON_MEMBER_QUERY))
+ (flags & SHOW_RAW_DATA)
? ANON_MEMBER_QUERY : 0))
error(FATAL, "invalid data structure
reference: %s.%s\n",
dm->name, memberlist[i]);
- if (flags & SHOW_RAW_DATA)
- error(FATAL,
- "member-specific output not
allowed with -r\n");
}
/*
@@ -6636,9 +6636,13 @@ do_datatype_addr(struct datatype_member *dm, ulong addr,
int count,
if (flags & SHOW_OFFSET) {
dm->vaddr = addr;
do_datatype_declaration(dm, flags | (dm->flags
& TYPEDEF));
- } else if (flags & SHOW_RAW_DATA)
+ } else if (flags & SHOW_RAW_DATA) {
+ if (argc_members) {
+ addr += dm->member_offset;
+ len = dm->member_size;
+ }
raw_data_dump(addr, len, flags &
STRUCT_VERBOSE);
- else if ((flags & DEREF_POINTERS) && !dm->member) {
+ } else if ((flags & DEREF_POINTERS) && !dm->member) {
print_struct_with_dereference(addr, dm, flags);
} else {
if (dm->member)
@@ -6849,7 +6853,7 @@ member_to_datatype(char *s, struct datatype_member *dm,
ulong flags)
{
dm->member = s;
- if ((dm->member_offset = MEMBER_OFFSET(dm->name, s)) >= 0)
+ if (datatype_info(dm->name, s, dm) >= 0)
return TRUE;
if ((flags & ANON_MEMBER_QUERY) &&
--
2.24.1
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] Faster iteration on list of struct.field
- 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@redhat.com > https://www.redhat.com/mailman/listinfo/crash-utility > -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
