<div dir="ltr"><div dir="ltr">On Fri, May 26, 2023 at 4:16 PM HAGIO KAZUHITO(萩尾　一仁) <<a href="mailto:k-hagio-ab@nec.com">k-hagio-ab@nec.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Is it possible to reuse the member offset in module memory patches? I<br>
> noticed that the offset is not used in the calculate_load_order_v3(). If it<br>
> is doable to reuse the offset, that may avoid modifying the gdb patch? I<br>
> haven't investigated the details.<br>
<br>
Modifying the gdb patch will be unavoidable, because the calculation in <br>
gdb/symtab.c is different from the existing one.<br>
<br>
And if we reuse the offset member, anyway we need an additional flag or <br>
something to switch the calculation above.  So I decided to add the addr <br>
member to clarify its meaning.<br></blockquote><div> </div><div>Ok, let's keep it. But I saw a warning:</div><div>...</div>symtab.c: In function ‘void gdb_command_funnel_1(gnu_request*)’:<br>symtab.c:7519:64: warning: ‘%lx’ directive writing between 1 and 16 bytes into a region of size between 10 and 73 [-Wformat-overflow=]<br> 7519 |                                         sprintf(buf, " -s %s 0x%lx", secname, lm->mod_section_data[i].addr);<br>      |                                                                ^~~<br>symtab.c:7519:54: note: directive argument in the range [1, 18446744073709551615]<br> 7519 |                                         sprintf(buf, " -s %s 0x%lx", secname, lm->mod_section_data[i].addr);<br>      |                                                      ^~~~~~~~~~~~~~<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
>> +       for (j = MOD_TEXT; j < MOD_MEM_NUM_TYPES; j++) {<br>
>> +<br>
>><br>
> <br>
> The above for-loop is frequently used in these patches, can we introduce<br>
> the following macro definition from the kernel?<br>
> <br>
> #define for_each_mod_mem_type(type)                     \<br>
>          for (enum mod_mem_type (type) = 0;              \<br>
>               (type) < MOD_MEM_NUM_TYPES; (type)++)<br>
> <br>
> Looks more convenient to me.<br>
<br>
Yes, agree, also I was thinking about something like this.<br>
will try it in the next version.<br></blockquote><div><br></div><div>Thanks.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
(I'd like to use int as I wrote in the 02/15 thread though :)<br>
<br></blockquote><div> </div><div>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.</div><div><br></div><div>Thanks.</div><div>Lianbo</div><div><br></div></div></div>