[m-dev.] Bug 321

[Julien Fischer]

Hi Paul,

On Sat, 22 Feb 2014, Paul Bone wrote:

> On Fri, Feb 21, 2014 at 11:24:02PM +1100, Julien Fischer wrote:
>>
>>
>> On Fri, 21 Feb 2014, Paul Bone wrote:
>>
>>> I'm tracking down bug 321.  https://www.mercurylang.org/bugs/view.php?id=321
>>>
>>> As you recall this is the symptom:
>>>
>>>    The C linker gives me errors such as:
>>>
>>>    paul at oxygen> mmc --rebuild test -O2 --intermodule-optimization
>>>    Making Mercury/int3s/test.int3
>>>    Making Mercury/ints/test.int
>>>    Making Mercury/opts/test.opt
>>>    Making Mercury/cs/test.c
>>>    Making Mercury/os/test.o
>>>    Making test
>>>    ** Error making `test'.
>>>    Mercury/os/test.o: In function `<predicate 'test.try_divide'/3 mode
>>>    0>':
>>>    test.c:(.text+0xe6): undefined reference to `<predicate
>>>    'exception.wrap_success_or_failure'/2 mode 0>'
>>>    collect2: error: ld returned 1 exit status
>>>
>>> After looking at the exception.m code and the HLDS dumps during compilation
>>> of my test.m I found that:
>>>
>>>    The linker can't find an address for: wrap_success_or_failure/2
>>>    But it can find addresses for: get_determinism/2
>>
>> Is your test.m the same as the file bug321.m that you uploaded to
>> Mantis?  I ask, because when I try the file from Mantis everything
>> seems fine ...
>
> Yes it is except for the module name.

Ok.

>>> Both predicates are called by the same code in the HLDS representation of
>>> test.m but one works and what doesn't.
>>
>> ... and when I look at the HLDS dumps (of bug321.m)I see no reference to
>> wrap_success_or_failure/2.
>
> Are you using the same options as above and in the bug report -O2
> --intermodule-optimization

Yes, in fact I tried everything from -O2 to -O6.

The major difference would be that I am looking at it on a system that
doesn't use ELF executables!  (The problem doesn't seem to occur on 
Mac OS X with either hlc.gc or none.gc at least).

I'll have a look on Linux later today - however, your bug report is a little
bit sketchy about the details of the system you were using:

* Linux (presumably)
* 32-bit or 64-bt?
* GCC version?
* Was the Mercury compiler installed directly from the srcdist or
   was it recompiled in another grade?
* Which grade?  The bug report says low-level C grade, does that mean
   that you've checked all of none.gc, reg.gc and asm_fast.gc and the bug
   occurs with all of them?

>>> So I looked at readelf(1) dump of libmer_std.so's symbol table.
>>> get_determinism/2 is exported globally and wrap_success_or_failure/2 is
>>> exported locally.
>>> Both are declared and defined in the implementation section of the exception
>>> module.  So now I want to know why is one being treated differently.
>>
>> get_determinism/2 is exported globally from exception.o because it
>> is referred to by opt-exported clauses in optimization interface for the
>> exception module.  (It is also subject of a no_inline pragma so its own
>> clauses do not appear in the .opt file.)
>>
>> wrap_success_or_failure/2 is not exported because it only refererred by
>> the predicate try_det, whose own clauses are not opt-exported.
>
> Okay that's odd.  I'll look more closely.

What's odd?  That try_det isn't opt-exported?

Cheers,
Julien.