Comment # 28 on bug 1190434 from David Mair
In the source examples below I re-post some from comment #27 where I correct a
line I ended with a comma but the source ends with a semi-colon.

To show why I am bogged down by this, here's the source for symbol_search():

> ulong
> symbol_value(char *symbol)
> {
>         struct syment *sp;
> 
>         if (!(sp = symbol_search(symbol)))
>                 error(FATAL, "cannot resolve \"%s\"\n", symbol);
> 
>         return(sp->value);
> }

This sets it's own struct syment sp in an identical way to the following source
sample from comment #27 except that the use of symbol_value in the following
set's linux_banner to the ASCII text 0x65762078756e694c, which is the value
linux_banner holds a pointer to:

>     if (!(sp = symbol_search("linux_banner")))
>         error(FATAL, "linux_banner symbol does not exist?\n");
>     else
>         if ((sp->type == 'R') || (sp->type == 'r') ||
>                 (THIS_KERNEL_VERSION >= LINUX(2,6,11) &&
>                 (sp->type == 'D' || sp->type == 'd')) ||
>                 (machine_type("ARM") && sp->type == 'T') ||
>                 (machine_type("ARM64")))
>             linux_banner = symbol_value("linux_banner");
>         else
>             get_symbol_data("linux_banner", sizeof(ulong);

Yet, if I insert the single line linux_banner = sp->value instead of that
symbol_value call and use the sp structure pointer we already have the error
doesn't happen:

>     if (!(sp = symbol_search("linux_banner")))
>         error(FATAL, "linux_banner symbol does not exist?\n");
>     else
>         if ((sp->type == 'R') || (sp->type == 'r') ||
>                 (THIS_KERNEL_VERSION >= LINUX(2,6,11) &&
>                 (sp->type == 'D' || sp->type == 'd')) ||
>                 (machine_type("ARM") && sp->type == 'T') ||
>                 (machine_type("ARM64")))
>             linux_banner = sp->value
>         else
>             get_symbol_data("linux_banner", sizeof(ulong);

So far, that makes no sense!

I believe calling get_symbol_data() would do it but if we took the false path
in the nested conditional the change I show in the true path would never be
executed.

Hence I am deep debugging at present and it's quite nasty for all the reasons
I've described...


You are receiving this mail because: