cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with "findpregtype".

SOLVED
Go to solution
Narendra Thapa
Frequent Advisor

Problem with "findpregtype".

Hi All,

I am writing a device driver on HPUX. I am seeing different behavior of findpregtype() on debug and non debug HPUX OS.

findpregtype() in the code below is always returning “preg->p_reg” as NULL on debug version of HPUX (B.11.31.0903). But, it works correctly on PERF HPUX.

vas = p_vas(procp_self());
vas_read_lock(vas);
preg = findpregtype(vas, PT_TEXT, (struct kthread *)NULL);
vas_unlock(vas);
if (preg && preg->p_reg)
{
vp = preg->p_reg->r_fstore;
}

Please let me know if I am missing anything here.
"Study as if you were going to live forever; live as if you were going to die tomorrow."
3 REPLIES
Don Morris_1
Honored Contributor
Solution

Re: Problem with "findpregtype".

Well, the first thing that comes to mind is that if you have access to debug builds -- you shouldn't be asking *here*. Either you're with HP (which I can't determine to be true hence I have to reply to you here) or you're suitably supported that you should use your support channels.

No one outside of R&D development environments should ever be running true debug bits.

That aside -- there are a couple thoughts on your code snippet:

1) It is not safe to read the p_reg field of the pregion in general as you describe without the VAS lock held. Yes, it is your VAS -- but the region underlying the pregion could be changed by another thread in your process [perhaps the text is being made self-patching (write is granted) and needs to be changed to a private copy instead of the globally shared bopy... that's a new region and hence the old region might go away between your dropping the lock and reading the field -- interrupts can happen at any time and mean you can't wave this away with "I do this quickly"].

2) More to the point -- what you're describing makes me wonder if your driver is also compiled Debug when you link with the debug kernel. The usual culprit when I see this type of nonsense result (and it is nonsense -- the race I describe at (1) is possible but should be really rare, which means that usually reading your own VAS/text combination should work. You handle the daemon case by checking for NULL -- and if the pregion is non-NULL, it pretty much should have a region. The fact that you imply this is both repeatable and does not happen on a Perf kernel (when there's no difference between the two for this algorithm) suggests to me that you're really reading the *wrong field*. Which naturally flows if you're linking a perf-built driver to a debug kernel. The debug version of a pregion structure gains a lot of extra (debugging fields) in things like embedded locks, etc. The p_reg offset may easily just be pointing to garbage -- which you happen to see as NULL.

One way to confirm (2) would be to use the debugger or disassemble your driver code -- see where the offset referenced is on the perf versus debug kernels. If the offset is the same (as I suspect), then compare that with the fields of preg_t, and you should see what you're really reading.
Dennis Handly
Acclaimed Contributor

Re: Problem with "findpregtype".

>Don: One way to confirm (2) would be to use the debugger or disassemble your driver code

If it has debug info, you can get it to print out the offsets of each field.
gdb has "info types" and "ptype -v".
kwdb doesn't have -v but q4 has "fields -cv".
Narendra Thapa
Frequent Advisor

Re: Problem with "findpregtype".

Hi Don Morris I was able to solve the issue with your suggested 2nd point.

Thanks to Dennis also for replying to my query.


Closing the thread as script is working now.
"Study as if you were going to live forever; live as if you were going to die tomorrow."