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 [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

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?

3 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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.

Retired 12/31/2016

(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.

Leave a Comment

Please sign in to add a comment. Not a member? Join today