dtrace discuss - Apr 2010 - Change a driver, dtrace becomes confused on prototypes

This is probably a newbie question, but I didn''t find an answer 
searching the history of this forum.

Working on driver CR and wanted to put some test hooks into the ata 
driver.  After I copy my new ata bits to /kernel/drv and 
/kernal/drv/amd64 my dscript suddenly breaks.

pfexec dtrace -s ata.d
dtrace: failed to compile script ata.d: line 10: operator ?: operands 
must have compatible types

The script....
fbt::ata_ctlr_fsm:entry
{
     self->pkt = args[3];
}
fbt::ata_ctlr_fsm:return
/self->pkt/
{
     printf("%s %02x %x\n",
         probefunc,
         (self->pkt->ap_cdbp) ? self->pkt->ap_cdbp[0] : 0xff,
         self->pkt->ap_hd);
     self->pkt = 0;
}

I''m reasonably sure the issue is I''m taking a short cut and
just copying
over the ata driver bits and not getting something updated that dtrace 
wants.  I''m hoping that the "something" is easy and
I''m don''t have to do
a full onu upgrade every time I change some little thing.

Thanks for your help
Charles

Your CTF data is likely out of sync between the driver and the genunix 
on the system.  Look here:

http://braindump.uk/wiki/index.php/CTF

for how to get your driver compiled properly.

John


On 04/21/10 11:03, Charles Binford wrote:
> This is probably a newbie question, but I didn''t find an answer 
> searching the history of this forum.
>
> Working on driver CR and wanted to put some test hooks into the ata 
> driver.  After I copy my new ata bits to /kernel/drv and 
> /kernal/drv/amd64 my dscript suddenly breaks.
>
> pfexec dtrace -s ata.d
> dtrace: failed to compile script ata.d: line 10: operator ?: operands 
> must have compatible types
>
> The script....
> fbt::ata_ctlr_fsm:entry
> {
>     self->pkt = args[3];
> }
> fbt::ata_ctlr_fsm:return
> /self->pkt/
> {
>     printf("%s %02x %x\n",
>         probefunc,
>         (self->pkt->ap_cdbp) ? self->pkt->ap_cdbp[0] : 0xff,
>         self->pkt->ap_hd);
>     self->pkt = 0;
> }
>
> I''m reasonably sure the issue is I''m taking a short cut
and just
> copying over the ata driver bits and not getting something updated 
> that dtrace wants.  I''m hoping that the "something" is
easy and I''m
> don''t have to do a full onu upgrade every time I change some
little
> thing.
>
> Thanks for your help
> Charles
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

Thanks.  That solved the problem.  Based on the wiki referenced below I did

     export CTFMERGE_GENUNIX=xxx

before I compiled the ata driver.  Now, after copying it to my test 
system dtrace works.

Thanks for the quick response and pointer to an informative wiki page.

cb


On 04/21/10 01:24 PM, John Harres wrote:
> Your CTF data is likely out of sync between the driver and the genunix 
> on the system.  Look here:
>
> http://braindump.uk/wiki/index.php/CTF
>
> for how to get your driver compiled properly.
>
> John
>
>
> On 04/21/10 11:03, Charles Binford wrote:
>> This is probably a newbie question, but I didn''t find an
answer
>> searching the history of this forum.
>>
>> Working on driver CR and wanted to put some test hooks into the ata 
>> driver.  After I copy my new ata bits to /kernel/drv and 
>> /kernal/drv/amd64 my dscript suddenly breaks.
>>
>> pfexec dtrace -s ata.d
>> dtrace: failed to compile script ata.d: line 10: operator ?: operands 
>> must have compatible types
>>
>> The script....
>> fbt::ata_ctlr_fsm:entry
>> {
>>     self->pkt = args[3];
>> }
>> fbt::ata_ctlr_fsm:return
>> /self->pkt/
>> {
>>     printf("%s %02x %x\n",
>>         probefunc,
>>         (self->pkt->ap_cdbp) ? self->pkt->ap_cdbp[0] :
0xff,
>>         self->pkt->ap_hd);
>>     self->pkt = 0;
>> }
>>
>> I''m reasonably sure the issue is I''m taking a short
cut and just
>> copying over the ata driver bits and not getting something updated 
>> that dtrace wants.  I''m hoping that the "something"
is easy and I''m
>> don''t have to do a full onu upgrade every time I change some
little
>> thing.
>>
>> Thanks for your help
>> Charles
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20100421/9777e550/attachment.html>