Hi, Is it possible to trace a register''s value? For example, can I write a D-script to print a message whenever %asi''s value has changed (kinda like setting a hardware watch point). thanks, Geetha
On Tue, Feb 28, 2006 at 03:53:08PM -0800, Geetha Vallabhaneni wrote:> Hi, > > Is it possible to trace a register''s value? For example, can I write a > D-script to print a message whenever %asi''s value has changed (kinda > like setting a hardware watch point).Could you give more details on what you''re trying to do? Are we talking about userland or kernel code? core-kernel code or code in your driver? etc. In any case, the answer is no; kernel registers are generally in an unknown state, as far as dtrace is concerned, and the hardware doesn''t provide any fascilities to trap on modification of a particular register that I know of. kmdb(1) is generally what you want if you need to look at or manipulate kernel registers. With more details, we can help direct you better. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
Hi Jonathan, I am helping a customer track down a SIGILL, which was generated during a ldxa instruction. The problem goes away at a lower optimization level since compiler avoids generating the ld*a''s but the customer is interested in finding out whether there is memory corruption in his MT program when the context is saved on the stack. The D-script I wrote (it simply read the asi register on entry and return of every function and printed a message if they are not equal), failed to capture anything. So I wonder if there is any other way to do this other than at the instruction level, like setting a watch point. thanks, Geetha Jonathan Adams wrote On 02/28/06 15:59,:> On Tue, Feb 28, 2006 at 03:53:08PM -0800, Geetha Vallabhaneni wrote: > >>Hi, >> >>Is it possible to trace a register''s value? For example, can I write a >>D-script to print a message whenever %asi''s value has changed (kinda >>like setting a hardware watch point). > > > Could you give more details on what you''re trying to do? Are we talking > about userland or kernel code? core-kernel code or code in your driver? > etc. > > In any case, the answer is no; kernel registers are generally in an > unknown state, as far as dtrace is concerned, and the hardware doesn''t > provide any fascilities to trap on modification of a particular register > that I know of. > > kmdb(1) is generally what you want if you need to look at or manipulate > kernel registers. With more details, we can help direct you better. > > Cheers, > - jonathan >
On Tue, Feb 28, 2006 at 04:08:29PM -0800, Geetha Vallabhaneni wrote:> Hi Jonathan, > > I am helping a customer track down a SIGILL, which was generated during > a ldxa instruction. The problem goes away at a lower optimization level > since compiler avoids generating the ld*a''s but the customer is > interested in finding out whether there is memory corruption in his MT > program when the context is saved on the stack. The D-script I wrote (it > simply read the asi register on entry and return of every function and > printed a message if they are not equal), failed to capture anything. So > I wonder if there is any other way to do this other than at the > instruction level, like setting a watch point.Since it is user level, it might be possible, but I don''t believe any Sparc chips allow you to set a breakpoint on register value changes. One possibility would be to disassemble all functions in the application, find all instructions which modify %asi, and use pid provider probes on those instructions. Something like: % truss -t \!all -Ua.out:main -f ./program arguments 180173/1 at 1: -> main(0x1, 0xffbff5e4, 0xffbff5ec, 0x26000) % mdb -p 180173 Loading modules: [ ld.so.1 libc.so.1 ]> ::nm -t func ! tail +2 | awk -F\| ''{print $1}'' > /tmp/func > ::cat /tmp/func | ::dis ! grep ''%asi *$''... list of all points in text where %asi is modified ... This will only work if your program has a full symbol table, of course. You could use the list to generate a D script recording the last time the register was modified. What is the value of %asi at the SIGILL? Was it set up earlier in the function? Cheers, - jonathan> Jonathan Adams wrote On 02/28/06 15:59,: > > On Tue, Feb 28, 2006 at 03:53:08PM -0800, Geetha Vallabhaneni wrote: > > > >>Hi, > >> > >>Is it possible to trace a register''s value? For example, can I write a > >>D-script to print a message whenever %asi''s value has changed (kinda > >>like setting a hardware watch point). > > > > > > Could you give more details on what you''re trying to do? Are we talking > > about userland or kernel code? core-kernel code or code in your driver? > > etc. > > > > In any case, the answer is no; kernel registers are generally in an > > unknown state, as far as dtrace is concerned, and the hardware doesn''t > > provide any fascilities to trap on modification of a particular register > > that I know of. > > > > kmdb(1) is generally what you want if you need to look at or manipulate > > kernel registers. With more details, we can help direct you better. > > > > Cheers, > > - jonathan > >-- Jonathan Adams, Solaris Kernel Development
No, it is not set-up in this particular function. I have asked them to dis the executables, all libraries and grep for with wr*asi and mov*asi. I don''t have that data yet. The value of asi is zero at the failure (overwritten I am guessing at some point in the past). So, ldxa fails with si_code 0x00000005, (ILL_PRVOPC:Privileged opcode.) thanks, Geetha Jonathan Adams wrote On 02/28/06 16:18,:> On Tue, Feb 28, 2006 at 04:08:29PM -0800, Geetha Vallabhaneni wrote: > >>Hi Jonathan, >> >>I am helping a customer track down a SIGILL, which was generated during >>a ldxa instruction. The problem goes away at a lower optimization level >>since compiler avoids generating the ld*a''s but the customer is >>interested in finding out whether there is memory corruption in his MT >>program when the context is saved on the stack. The D-script I wrote (it >>simply read the asi register on entry and return of every function and >>printed a message if they are not equal), failed to capture anything. So >>I wonder if there is any other way to do this other than at the >>instruction level, like setting a watch point. > > > Since it is user level, it might be possible, but I don''t believe any Sparc > chips allow you to set a breakpoint on register value changes. > > One possibility would be to disassemble all functions in the application, > find all instructions which modify %asi, and use pid provider probes on those > instructions. Something like: > > % truss -t \!all -Ua.out:main -f ./program arguments > 180173/1 at 1: -> main(0x1, 0xffbff5e4, 0xffbff5ec, 0x26000) > % mdb -p 180173 > Loading modules: [ ld.so.1 libc.so.1 ] > >>::nm -t func ! tail +2 | awk -F\| ''{print $1}'' > /tmp/func >>::cat /tmp/func | ::dis ! grep ''%asi *$'' > > ... list of all points in text where %asi is modified ... > > This will only work if your program has a full symbol table, of course. > You could use the list to generate a D script recording the last time > the register was modified. > > What is the value of %asi at the SIGILL? Was it set up earlier in the > function? > > Cheers, > - jonathan > > > > >>Jonathan Adams wrote On 02/28/06 15:59,: >> >>>On Tue, Feb 28, 2006 at 03:53:08PM -0800, Geetha Vallabhaneni wrote: >>> >>> >>>>Hi, >>>> >>>>Is it possible to trace a register''s value? For example, can I write a >>>>D-script to print a message whenever %asi''s value has changed (kinda >>>>like setting a hardware watch point). >>> >>> >>>Could you give more details on what you''re trying to do? Are we talking >>>about userland or kernel code? core-kernel code or code in your driver? >>>etc. >>> >>>In any case, the answer is no; kernel registers are generally in an >>>unknown state, as far as dtrace is concerned, and the hardware doesn''t >>>provide any fascilities to trap on modification of a particular register >>>that I know of. >>> >>>kmdb(1) is generally what you want if you need to look at or manipulate >>>kernel registers. With more details, we can help direct you better. >>> >>>Cheers, >>>- jonathan >>> > >