Re: [Crash-utility] [RFC PATCH 03/15] Make "sym -m" option print symbols in address order
On 2023/05/25 11:44, HAGIO KAZUHITO(萩尾 一仁) wrote:
On 2023/05/24 16:10, lijiang wrote:
> On Thu, May 11, 2023 at 12:35 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
> wrote:
>
>> To "sym -m" print the symbols of a module in address order.
>> (but "sym -l" and "sym -M" still print modules in text
address order.)
>>
>>
> The current text address order is better to me, basically it can keep the
> same order with the definition mod_mem_type, which looks more natural. For
> example:
> crash> sym -m kvm |grep MODULE
> ffffffffc136e000 MODULE TEXT START: kvm
> ffffffffc13e0000 MODULE TEXT END: kvm
> ffffffffc1ceb000 MODULE DATA START: kvm
> ffffffffc1d6b000 MODULE DATA END: kvm
> ffffffffc291a000 MODULE RODATA START: kvm
> ffffffffc296c000 MODULE RODATA END: kvm
> ffffffffc11cf000 MODULE RO_AFTER_INIT START: kvm
> ffffffffc11d1000 MODULE RO_AFTER_INIT END: kvm
sorry, apparently I misunderstood your comments.
Does this mean that sorting memory types in a module by address is
unnecessary?
>
> And the internal output in each module memory type is sorted by address as
> below:
Yes, I see this.
> crash> sym -m kvm
> ffffffffc136e000 MODULE TEXT START: kvm
> ffffffffc136e000 (T) __pfx___traceiter_kvm_userspace_exit
> ffffffffc136e010 (T) __traceiter_kvm_userspace_exit
> ffffffffc136e050 (T) __pfx___traceiter_kvm_vcpu_wakeup
> ffffffffc136e060 (T) __traceiter_kvm_vcpu_wakeup
> ffffffffc136e0b0 (T) __pfx___traceiter_kvm_set_irq
> ffffffffc136e0c0 (T) __traceiter_kvm_set_irq
> ffffffffc136e110 (T) __pfx___traceiter_kvm_ioapic_set_irq
> ffffffffc136e120 (T) __traceiter_kvm_ioapic_set_irq
> ffffffffc136e170 (T) __pfx___traceiter_kvm_ioapic_delayed_eoi_inj
> ...
> ffffffffc13df650 (t) kvm_x86_exit
> ffffffffc13df650 (T) cleanup_module
> ffffffffc13e0000 MODULE TEXT END: kvm
>
> In addition, the sym -m option will be consistent with the styles of sym
> -l/-M options,
What does this mean?
This patch's "sym -m" is already consistent with the "sym -l|-M"
options:
crash-6.4> sym -m cdrom | grep MODULE
ffffffffc084d000 MODULE RO_AFTER_INIT START: cdrom
ffffffffc084e000 MODULE RO_AFTER_INIT END: cdrom
ffffffffc08da000 MODULE TEXT START: cdrom
ffffffffc08e1000 MODULE TEXT END: cdrom
ffffffffc0aa3000 MODULE RODATA START: cdrom
ffffffffc0aa8000 MODULE RODATA END: cdrom
ffffffffc0b04000 MODULE DATA START: cdrom
ffffffffc0b0b000 MODULE DATA END: cdrom
crash-6.4> sym -l | grep MODULE
...
ffffffffc084d000 MODULE RO_AFTER_INIT START: cdrom
ffffffffc084e000 MODULE RO_AFTER_INIT END: cdrom
ffffffffc08da000 MODULE TEXT START: cdrom
ffffffffc08e1000 MODULE TEXT END: cdrom
ffffffffc0aa3000 MODULE RODATA START: cdrom
ffffffffc0aa8000 MODULE RODATA END: cdrom
ffffffffc0b04000 MODULE DATA START: cdrom
ffffffffc0b0b000 MODULE DATA END: cdrom
...
and really simplify the code.
Does this mean that we can remove lm->address_order and related code?
btw, this facility is helpful to speed up searching addresses in some
codes, e.g. patch 05/15. I think this is a good preprocessing.
Given that, I tend to print
> modules in *text address order* and do not need to change it.
So you mean.. if we have these modules (just an example),
addr
modA TEXT 3
DATA 1
modB TEXT 4
DATA 2
"sym -M" with the current patch prints:
addr
modB DATA 2
TEXT 4
modA DATA 1
TEXT 3
Your preference is like this, correct?
addr
modB TEXT 2
DATA 4
modA TEXT 3
DATA 1
If correct, I prefer to sorting memory types in a module, because the
types are merely memory types and they do not have a natural order. It
would be more helpful for us to sort them in a module at least, to
search for a symbol or address with the "sym" options.
Thanks,
Kazu
>
> ok, thanks. If we need to sort all of module symbols, we can use sort
> command as I wrote in 0/15.
>
> > crash> sym -M | grep MODULE | sort # displayed in address order
>
> Thanks,
> Kazu
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://listman.redhat.com/mailman/listinfo/crash-utility
> Contribution Guidelines: https://github.com/crash-utility/crash/wiki