|
From: Vinay C. <vin...@gm...> - 2012-04-18 01:56:24
|
Hi all,
I am trying to develop a tool using valgrind and I had to use
unsafeIRDirty_1_N for writing into a temporary register. It works fine
for integer temporary registers but fails for floating point ones. The
error message comes from line 4020 in VEX/priv/host_amd64_isel.c which
basically says that dirty call should not return floating point value.
I am not sure if the dirty call actually does not support floating
point values or if I am doing something wrong. I would appreciate any
help in this regard. The error message is as follows:
t132 = DIRTY 1:I1 ::: Dirty_Value{0x38001030}()
vex: the `impossible' happened:
iselStmt(amd64)
vex storage: T total 1058649560 bytes allocated
vex storage: P total 960 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
==17711== at 0x38003A77: report_and_quit (m_libcassert.c:210)
==17711== by 0x38003ADE: panic (m_libcassert.c:294)
==17711== by 0x38003B38: vgPlain_core_panic_at (m_libcassert.c:299)
==17711== by 0x38003B4A: vgPlain_core_panic (m_libcassert.c:304)
==17711== by 0x3801E602: failure_exit (m_translate.c:700)
==17711== by 0x380A2C18: vpanic (main_util.c:226)
==17711== by 0x381C6759: iselSB_AMD64 (host_amd64_isel.c:4148)
==17711== by 0x380A143B: LibVEX_Translate (main_main.c:699)
==17711== by 0x3801BF19: vgPlain_translate (m_translate.c:1544)
==17711== by 0x3804918C: vgPlain_scheduler (scheduler.c:929)
==17711== by 0x38072AC9: run_a_thread_NORETURN (syswrap-linux.c:98)
==17711== by 0x38072D5A: vgModuleLocal_start_thread_NORETURN
(syswrap-linux.c:268)
==17711== by 0x380756ED: ??? (in
/home/vchippa/valgrind/installation/lib/valgrind/char-amd64-linux)
==17711== by 0xDEADBEEFDEADBEEE: ???
==17711== by 0xDEADBEEFDEADBEEE: ???
==17711== by 0xDEADBEEFDEADBEEE: ???
Thanks,
Vinay.
|
|
From: Vinay C. <vin...@gm...> - 2012-04-18 18:05:58
|
Thanks Florian,
I kind of guessed that from the valgrind code but could not
find any documentation that talks about the limitation of dirty calls.
I made an ugly fix by passing the argument (and returning) as long int
and reinterpreting it as float/double on the other side.
Regards,
Vinay.
On Wed, Apr 18, 2012 at 1:58 PM, Florian Krohm <fl...@ei...> wrote:
> On 04/17/2012 09:55 PM, Vinay Chippa wrote:
>> Hi all,
>> I am trying to develop a tool using valgrind and I had to use
>> unsafeIRDirty_1_N for writing into a temporary register. It works fine
>> for integer temporary registers but fails for floating point ones. The
>> error message comes from line 4020 in VEX/priv/host_amd64_isel.c which
>> basically says that dirty call should not return floating point value.
>> I am not sure if the dirty call actually does not support floating
>> point values or if I am doing something wrong.
>
> The machinery around dirty helper calls does not support floating point
> return values (and also no floating point arguments). The reason is that
> dirty helper calls are rare and therefore only what is needed is being
> implemented.
> You're running into the assert because the condition on line 4020 is
> false. It tests for the return type being an integer.
> I don't think there is anything fundamental that prevents you from
> having a dirty helper that returns a float. So if you're eager you can
> probably figure out how to extend the code. But it's not exactly a
> warm-up exercise...
>
> Florian
>
>
>
> I would appreciate any
>> help in this regard. The error message is as follows:
>>
>> t132 = DIRTY 1:I1 ::: Dirty_Value{0x38001030}()
>> vex: the `impossible' happened:
>> iselStmt(amd64)
>> vex storage: T total 1058649560 bytes allocated
>> vex storage: P total 960 bytes allocated
>>
>> valgrind: the 'impossible' happened:
>> LibVEX called failure_exit().
>> ==17711== at 0x38003A77: report_and_quit (m_libcassert.c:210)
>> ==17711== by 0x38003ADE: panic (m_libcassert.c:294)
>> ==17711== by 0x38003B38: vgPlain_core_panic_at (m_libcassert.c:299)
>> ==17711== by 0x38003B4A: vgPlain_core_panic (m_libcassert.c:304)
>> ==17711== by 0x3801E602: failure_exit (m_translate.c:700)
>> ==17711== by 0x380A2C18: vpanic (main_util.c:226)
>> ==17711== by 0x381C6759: iselSB_AMD64 (host_amd64_isel.c:4148)
>> ==17711== by 0x380A143B: LibVEX_Translate (main_main.c:699)
>> ==17711== by 0x3801BF19: vgPlain_translate (m_translate.c:1544)
>> ==17711== by 0x3804918C: vgPlain_scheduler (scheduler.c:929)
>> ==17711== by 0x38072AC9: run_a_thread_NORETURN (syswrap-linux.c:98)
>> ==17711== by 0x38072D5A: vgModuleLocal_start_thread_NORETURN
>> (syswrap-linux.c:268)
>> ==17711== by 0x380756ED: ??? (in
>> /home/vchippa/valgrind/installation/lib/valgrind/char-amd64-linux)
>> ==17711== by 0xDEADBEEFDEADBEEE: ???
>> ==17711== by 0xDEADBEEFDEADBEEE: ???
>> ==17711== by 0xDEADBEEFDEADBEEE: ???
>>
>> Thanks,
>> Vinay.
>>
>> ------------------------------------------------------------------------------
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>
|