|Priority:||4 - Normal|
|Created by:||Former user|
|Reported by:||Former user|
|Assigned to:||Former user|
Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2019-04-17T16:00:57.593Z)
2019-04-25 Queen of Jordan (Release Date: 2019-04-25)
I noticed that some kernel module's ctfdump -c output was awry:
$ ctfdump -c ./platform/i86xpv/kernel/drv/amd64/balloon | more /* Types */ typedef 0��p���0��0��<; typedef struct cpu_ht cpu_ht_t; ...
$ ctfdump -c -p ./kernel/amd64/genunix ./platform/i86xpv/kernel/drv/amd64/balloon | more /* Types */ typedef void (*callback_func_t)(struct as *, void *, uint_t); typedef struct cpu_ht cpu_ht_t; ...
I had tested the parent case, but clearly something broke at some point.
There's a few places where we need to correctly initialise strings, so when we fail to look up the type in the missing parent, we will default to "unknown_t". In addition, we'll complain if we had a parent but it wasn't specified.
I ran ctfdump -c across all of the kernel output and checked a few of them to make sure all the 'unknown_t's were there as expected (as well as OS-7700 testing)
OS-7689 ctfdump -c goes off the rails with a missing parent
OS-7694 ctfdump -c drops last type
OS-7700 GCC7-derived CTF can double qualifiers on arrays
OS-7733 should ignore DW_TAG_subprogram with DW_AT_declaration tags
Reviewed by: Robert Mustacchi <email@example.com>
Reviewed by: Jerry Jelinek <firstname.lastname@example.org>
Reviewed by: Jason King <email@example.com>
Approved by: Jerry Jelinek <firstname.lastname@example.org>