2023-12-09 23:09 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000196mercuryBugpublic2016-07-17 20:56
Assigned Tojuliensf 
Product Version 
Target VersionFixed in Version 
Summary0000196: Binary compatibility checks in C grades don't work.
DescriptionThe binary compatibility checks in runtime/mercury_goto.h don't work. I was able to modify the grade string and re-compile the runtime and link it against the standard library and object files that had been generated against an older version of this header file.

I suspect that the static variable in generated C files that refers to the grade variable is being optimized a way and therefore the linker happily links the mis-matched objects.
TagsNo tags attached.
Attached Files




juliensf (administrator)

Does the variable appear amongst the list of exported symbols?

What version of gcc are you using? (Recent ones do perform some LTO, so maybe
that's the problem?)


juliensf (administrator)

The problem is that the static variable MR_grade that we emit at the end of every generated .c file is being optimised away (since it is not referenced by anything else). GCC and clang seem quite happy to do this even if the variable is also declared to be volatile. The will however retain the variable if it is declared with
the variable attribute __attribute__((used)). For other C compilers I'm not yet sure what to do (or even if this is a problem).


zs (developer)

We could generate an exported function that returns the value of MR_grade.
Since it could be called from somewhere else, the compiler wouldn't be able
to optimize away the reference. This should be more portable than __attribute__.


juliensf (administrator)

We can hide __attribute__ behind a macro, just as we already do with other such attributes, e.g.

  #if defined(MR_GNUC) || defined(MR_CLANG)
      #define MR_CONSIDER_USED __attribute__((used))
      #define MR_CONSIDER_USED volatile /* .. and hope for the best! */

I've implemented this and tested it with clang. (I'm not even sure that this is an issue with
MSVC; I'll take a look tomorrow when I have access to a machine with that compiler installed.)
Given that C compilers used with Mercury are nearly always GCC or clang I think this is probably
good enough.


juliensf (administrator)

Fix in commit 10c210d.

-Issue History
Date Modified Username Field Change
2011-04-13 23:10 pbone New Issue
2011-04-13 23:25 juliensf Note Added: 0000327
2016-07-07 19:56 juliensf Note Added: 0000892
2016-07-07 19:56 juliensf Assigned To => juliensf
2016-07-07 19:56 juliensf Status new => assigned
2016-07-07 20:27 zs Note Added: 0000893
2016-07-07 20:48 juliensf Note Added: 0000894
2016-07-17 20:56 juliensf Note Added: 0000898
2016-07-17 20:56 juliensf Status assigned => resolved
2016-07-17 20:56 juliensf Resolution open => fixed
+Issue History