Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ocamldumpobj misreports address operands of CLOSUREREC instructions #4563

vicuna opened this issue Jun 5, 2008 · 0 comments


None yet
1 participant
Copy link

commented Jun 5, 2008

Original bug ID: 4563
Reporter: premchai21
Status: closed (set by @damiendoligez on 2008-09-10T12:53:37Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 3.10.2
Fixed in version: 3.11+dev
Category: ~DO NOT USE (was: OCaml general)
Monitored by: ines

Bug 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 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/ 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 *)

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.

@vicuna vicuna closed this Sep 10, 2008

@vicuna vicuna added the bug label Mar 19, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.