tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: symbol lookup in ddb - bad heuristic



On Sat, Dec 10, 2022 at 01:03:06AM +0300, Valery Ushakov wrote:
> db_printsym has the following heuristic:
> 
>   revision 1.68
>   date: 2021-12-13 04:25:29 +0300;  author: chs;  state: Exp;  lines: +16 -2;  commitid: MT9cIBmUIZU1AqkD;
>   ddb: fix function names of "noreturn" functions in stack traces.
> 
>   when looking up function names for stack traces (where the addresses
>   are the return addresses of function calls), if the address is the
>   first instruction in the function, assume that the function being
>   called is marked "noreturn" and that the function containing the
>   call is actually the function immediately before the address that we
>   looked up.  to find the correct function name, do the lookup again
>   with (address - 1) and then add one to the offset within the
>   function that we find.
> 
> 
> That causes breakpoints on a function entry to be misreported:
> 
>   Breakpoint in pid 0.0 (system) at netbsd:sysbeepdetach+0x21: pushl %ebp
>   ...
>   db{0}> show break
>    Map      Count    Address
>   *0x0     1    netbsd:sysbeepdetach+0x21
>   db{0}> x/i sysbeepdetach+0x21   
>   netbsd:clockintr:       pushl   %ebp
> 
> May be the hack need to be applied only with a new special flag, say,
> KSYMS_RET?  Then we can define separate DB_STGY_PROC (no heuristic)
> and DB_STGY_RET (with the heuristic).
> 
> The downside is that all MD db_stack_trace_print functions need to be
> adjusted, but it actually makes sense to use both strategies there,
> b/c when we are traversing an interrupt/exception frame, the
> DB_STACK_PROC (without the heuristic) is the right thing to use, but
> unwinding a call needs DB_STACK_RET (with the new flag).
> 
> Thoughts?
> 
> -uwe

hi, sorry for the delay in replying.

you're right, to print the right function name we do need to distinguish
between addresses that are function return addresses and those that are not,
and the DB_STGY_RET / KSYMS_RET flags that you suggest sound like a fine way
of doing that.  would you like to implement this or do you want me to do it?

-Chuck


Home | Main Index | Thread Index | Old Index