[Crash-utility] [RFC PATCH 06/15] Support "mod -s|-S" options

[lijiang]

On Fri, May 26, 2023 at 4:16 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20230530/62de3256/attachment-0001.htm>