Re: [Crash-utility] [RFC PATCH 06/15] Support "mod -s|-S" options
On Fri, May 26, 2023 at 4:16 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
wrote:
> Is it possible to reuse the member offset in module memory
patches? I
> noticed that the offset is not used in the calculate_load_order_v3(). If
it
> is doable to reuse the offset, that may avoid modifying the gdb patch? I
> haven't investigated the details.
Modifying the gdb patch will be unavoidable, because the calculation in
gdb/symtab.c is different from the existing one.
And if we reuse the offset member, anyway we need an additional flag or
something to switch the calculation above. So I decided to add the addr
member to clarify its meaning.
Ok, let's keep it. But I saw a warning:
...
symtab.c: In function ‘void gdb_command_funnel_1(gnu_request*)’:
symtab.c:7519:64: warning: ‘%lx’ directive writing between 1 and 16 bytes
into a region of size between 10 and 73 [-Wformat-overflow=]
7519 | sprintf(buf, " -s %s
0x%lx", secname, lm->mod_section_data[i].addr);
| ^~~
symtab.c:7519:54: note: directive argument in the range [1,
18446744073709551615]
7519 | sprintf(buf, " -s %s
0x%lx", secname, lm->mod_section_data[i].addr);
| ^~~~~~~~~~~~~~
>> + for (j = MOD_TEXT; j < MOD_MEM_NUM_TYPES; j++) {
>> +
>>
>
> The above for-loop is frequently used in these patches, can we introduce
> the following macro definition from the kernel?
>
> #define for_each_mod_mem_type(type) \
> for (enum mod_mem_type (type) = 0; \
> (type) < MOD_MEM_NUM_TYPES; (type)++)
>
> Looks more convenient to me.
Yes, agree, also I was thinking about something like this.
will try it in the next version.
Thanks.
(I'd like to use int as I wrote in the 02/15 thread though :)
For this case, if the compiler won't report a warning/an error when the
value exceeds the ranges of enum types, both int and enum are fine to me.
Otherwise, the enum is better than the int type.
Thanks.
Lianbo
Attachments:
- attachment.html (text/html — 3.1 KB)