ENTRY Argument cannot be watched or changed in DLL with export

ENTRY Argument cannot be watched or changed in DLL with export

This post is similar to one entitled "Subroutine ENTRY Arguments "Undefined" in VS2010 Debug View" but seemed to have enough unique differences to merit a separate posting.

I recently moved a large collection of Fortran subroutines into a DLL, exporting the subroutines that I want to expose. Since then (and with no other code changes) an issue has come up: the dummy argument supplied with an ENTRY is not visible from within the debugger and more importantly, the input argument is not changed by the code that follows the ENTRY. I'm using VS2010/Intel(R) Visual Fortran Compiler XE 12.1.2.278 [IA-32]. [Small tangent: When I debug and walk into the code that follows the ENTRY and look at the Stack Frame in VS2010 it shows "fvslib.dll!GENRPT() line 58". That is the correct DLL name and line number, but it gives the name of the subroutine and not the entry; and it does not include the entry's argument. I don't know if this is expected behavior for an ENTRY in the Stack Frame window, but I would have expected the frame to show the entry name and argument type.]

I can make a temporary copy of the variable and the copied variable can be seen in a Watch window. Making a copy doesn't solve my problem however, since the input value of the inut argument is meant to be changed. Upon return from the ENTRY, the original argument is unchanged in the calling routine, suggesting a temporary copy was made. I tried declaring the dummy variable with INTENT(INOUT), which caused the following corroborating error:

  error #8039: The INTENT(OUT) or INTENT(INOUT) attribute is not allowed for arguments received by value.   [JROUT]

I hadn't expected to see JROUT passed by value, which was a bit surprising.The subroutine (with no arguments) is exported as shown below. This subroutine has several ENTRY points; some with no arguments, some with one argument. The problematic ENTRY  takes one integer argument with the dummy name 'JROUT'. Guessing that the exporting of the subroutine might also affect entry points (I couldn't find documentation about this), I added the ENTRY dummy argument's name (JROUT) to the ATTRIBUTES:

#ifdef _WINDLL
!DEC$ ATTRIBUTES DLLEXPORT,C,DECORATE,ALIAS:'GENRPT'::GENRPT
!DEC$ ATTRIBUTES REFERENCE :: JROUT
#endif

That solves the problem, but it may not be the best way to solve the problem. I'd appreciate some advice about the best approach. Is the issue is related to the DLL export of the subroutine name, which might  make it necessary to make ENTRY arguments by explicit REFERENCE?

Donald Robinson Sr. Systems Ecologist ESSA Technologies Ltd. Vancouver, Canada www.essa.com 604.535.1997 - audio, video, disco
3 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

Did you add the ATTRIBUTES line with the C attribute? This changes the default to pass-by-value. My guess is that you didn't have this before. You should take out the C attribute and then you can remove the REFERENCE.

We know about issues debugging ENTRY and are working on that.

Steve Intel Developer Support

(Blush) - you're right... ATTRIBUTES C snuck in. As we say to the kids - "Do as I say, not as I do" - seems appropriate here.

Donald Robinson Sr. Systems Ecologist ESSA Technologies Ltd. Vancouver, Canada www.essa.com 604.535.1997 - audio, video, disco

Melden Sie sich an, um einen Kommentar zu hinterlassen.