0004563: ocamldumpobj misreports address operands of CLOSUREREC instructions

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0004563

OCaml

OCaml general

public

2008-06-05 15:49

2008-09-10 14:53

Reporter

premchai21

Assigned To

Priority

normal

Severity

minor

Reproducibility

always

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

3.10.2

Target Version

Fixed in Version

3.11+dev

Summary

0004563: ocamldumpobj misreports address operands of CLOSUREREC instructions

Description

Compiling a file with the definitions:

  let rec even x = if x == 0 then true else odd (x-1)
      and odd x = if x == 0 then false else even (x-1)

and then running ocamldumpobj on the resulting object file yields
output containing the instruction:

      28 CLOSUREREC 0, 4294967298, 4294967311

which seems incorrect. From examining interp.c, CLOSUREREC seems to
take a count of variables and a number of function bytecode addresses,
and dumpobj.ml is outputting the operands in that order, but it's also
erroneously adding 2^32 to the addresses. E.g., the above line should
probably read:

      28 CLOSUREREC 0, 2, 15

Additional Information

This is on Debian GNU/Linux, unstable variant, AMD64 architecture,
with OCaml 3.10.2, Debian OCaml package version 3.10.2-3. A glance at
tools/dumpobj.ml seems to indicate that what's happening is that the
offset is being treated as unsigned (comment mine for annotation):

        print_int nvars;
        for i = 0 to nfuncs - 1 do
          print_string ", ";
          print_int (orig + inputu ic); (* <-- unsigned offset *)
        done;

This probably works on 32-bit machines because the Caml integers wrap
around properly in that case anyway, but on a 64-bit architecture,
there's more range in a Caml int and so treating the 32-bit offset as
an unsigned int rather than a signed one causes errors in bits 32 and
above in the result.

Issue History
Date Modified	Username	Field	Change
2008-06-05 15:49	premchai21	New Issue
2008-09-10 14:53	doligez	Status	new => closed
2008-09-10 14:53	doligez	Resolution	open => fixed
2008-09-10 14:53	doligez	Fixed in Version	=> 3.11+dev

Relationships

Notes
There are no notes attached to this issue.