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@xxxxxxx>
>> 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@xxxxxxxxxx
> https://listman.redhat.com/mailman/listinfo/crash-utility
> Contribution Guidelines: https://github.com/crash-utility/crash/wiki
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/crash-utility
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
