On Fri, May 26, 2023 at 4:16 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@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