Re: [Crash-utility] [RFC PATCH 02/15] Support "sym -l|-M|-m" options
On 2023/06/02 12:46, lijiang wrote:
On Fri, Jun 2, 2023 at 8:59 AM HAGIO KAZUHITO(萩尾 一仁)
<k-hagio-ab(a)nec.com>
wrote:
> On 2023/05/30 15:37, lijiang wrote:
>> On Thu, May 25, 2023 at 10:36 AM HAGIO KAZUHITO(萩尾 一仁) <
> k-hagio-ab(a)nec.com>
>> wrote:
>>
>>>>
>>>> The variable "j" should be defined as enum mod_mem_type.
>>>
>>> hmm, so can we change the enums to macros for now?
>>>
>>>
>> Here, the enums are more flexible than macros, once the kernel changes
> the
>> enums, crash-utility is easy to follow up kernel changes.
>
> Sorry, I couldn't imagine this.
> How can we use enum flexibly to follow up kernel changes, for example,
> when MOD_FOO=1 is inserted?
>
>
Good question. Let me give an example:
long mod_foo;
long mod_data;
enumerator_value("MOD_FOO", &mod_foo);
or
enumerator_value("MOD_DATA", &mod_data);
Doesn't this use enum in crash?
The enumerator_value() can always get the correct result from the current
vmcore/kcore, if I understand correctly.
Yes, I also think about using enumerator_value(), when we need it.
But I'm not sure how much they change in future, so I would like
to implement it simply for now. Macros can follow up small changes.
And when the day comes, we can change the macros like
#define MOD_DATA (st->enum_mod_data)
or something.
But it seems that the macro doesn't have the similar function to get the
value from gdb. And the weakness is that the value may have conflict with
the existing macros. For example:
-#define ORC_TYPE_CALL 0
+#define ORC_TYPE_CALL ((machdep->flags & ORC_6_4) ? 2 : 0)
#define ORC_TYPE_REGS 1
#define ORC_TYPE_REGS_IRET 2
Yes, but we use only ORC_TYPE_CALL so far, so I just kept the others
as they are. If needed, they can be changed with macros.
(they should be removed, but it's discussed on another thread :)
It feels like to me macros can be used a bit flexibly, e.g. like [1].
>
> [1] https://listman.redhat.com/archives/crash-utility/2023-May/010683.html
>
>>
>> #define MOD_TEXT 0
>>> #define MOD_DATA 1
>>> ...
>>>
>>> I don't see enum's good point here in crash.
>>>
>>>
>> If the value is out of the enums ranges, it may have a warning from the
>> compiler, just a guess, not confirmed.
>
> I tried this, but couldn't get a warning and find such an option.
> Maybe this isn't what you mean?
>
>
I got a warning with g++ based on your test case:
$ g++ -o enum enum.c
enum.c: In function ‘int main(int, char**)’:
enum.c:9:29: error: invalid conversion from ‘int’ to ‘test_enum’
[-fpermissive]
9 | enum test_enum x = 10;
| ^~
| |
| int
BTW: crash-utility may be built by various/different compilers.
gcc and clang don't emit a warning. Can g++ compile crash?
Thanks,
Kazu
>
> Thanks.
> Lianbo
>
>
>> $ cat enum.c
>> #include <stdio.h>
>> enum test_enum {
>> a,
>> b = 5,
>> c,
>> };
>> int main(int argc, char *argv[])
>> {
>> enum test_enum x = 10;
>> printf("x = %d\n", x);
>> printf("a = %d b = %d c= %d\n", a, b, c);
>> return 0;
>> }
>> $ cc -Wall -o enum enum.c
>> $ ./enum
>> x = 10
>> a = 0 b = 5 c= 6
>>
>> Thanks,
>> Kazu
>>
>>