tech-kern archive

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

Re: KSYMS_CLOSEST



On Sun, Dec 25, 2022 at 17:41:10 +0100, Anders Magnusson wrote:

> Den 2022-12-25 kl. 17:25, skrev Valery Ushakov:
> > On Sun, Dec 25, 2022 at 15:42:47 +0100, Anders Magnusson wrote:
> > 
> > > Den 2022-12-25 kl. 13:43, skrev Valery Ushakov:
> > > > On Sun, Dec 25, 2022 at 09:20:49 +0100, Anders Magnusson wrote:
> > > > 
> > > > > IIRC it was to match the ddb "sift" command.
> > > > I'm not sure I get how it might be used for sifting - a kind of "next"
> > > > for external iteration?  Since we never got around to do that do we
> > > > still want to keep it, or shall we deprecate/delete it?
> > >
> > > Ah! I had to look at the code - no, it has nothing to do with sift.
> > > I think it is implicit when asking for a name these days; it is used
> > > to get nearest lower address address in debug output. (like
> > > tstile+0x18 )
> >
> > Right, right, but I wonder what could it possibly mean then, when the
> > flag is not specified - as opposed to the example above.  I.e. if
> > KSYMS_CLOSEST is foo+0x10, what KSYMS_EXTERN (i.e. no specific flags)
> > could be, other than foo+0x10, for the same address?  I mean,
> > technically, netbsd + 0xcaffe42 would also be a correct reply in that
> > case :)
>
> :-)  If you are not specifying KSYMS_EXACT, you may not get the exact
> address, yes.  That is true :-)
>
> > Also, checking the very first versions of ksyms code I don't see
> > KSYMS_CLOSEST ever actually handled (it's defined and specified in the
> > ddb strategy defines, but never tested in ksyms).  May be I missed
> > some later short-lived incarnation.
> > 
> > The existing call sites that supply the flag look like cargo-cult^W^W
> > common sense ("looks like you might need to specify that flag to get
> > foo+0x10, well, *shrug*, won't hurt").
> I assume that might be the case, yes.
> The ksyms code comes from another system for which I wrote it a long time
> ago, where the meaning may have had a significance (do not remember).
> But feel free to clean this up.  (IMHO KSYMS_EXACT should be the default,
> requiring KSYMS_CLOSEST to be defined if that is requested).

But KSYMS_EXACT has different meaning.  It means to look for exactly
"foo" (foo+0) and fail otherwise.

    if ((f & KSYMS_EXACT) && (v != es->st_value))
        return ENOENT;


-uwe


Home | Main Index | Thread Index | Old Index