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

ocamlopt places symbols interior to statically allocated 'value's #4414

Closed
vicuna opened this issue Oct 10, 2007 · 3 comments
Closed

ocamlopt places symbols interior to statically allocated 'value's #4414

vicuna opened this issue Oct 10, 2007 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Oct 10, 2007

Original bug ID: 4414
Reporter: gordonhenriksen
Status: acknowledged (set by @xavierleroy on 2007-11-10T13:12:05Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.10+dev
Category: back end (clambda to assembly)
Tags: patch
Monitored by: "Radzevich Belevich" jm @avsm @alainfrisch

Bug description

For statically allocated 'value's, ocamlopt places symbols interior to the objects they identify--specifically, the symbol lies after the object header. For instance, a string constant is emitted as such (x86):

    ; Existing behavior
    .data
    .long   2300     ; wosize=2, color=0, tag=string

_camlExample__1:
.ascii "Hello"
.space 2
.byte 2 ; = (wosize*size_addr)-(strlen+1)

This is convenient in that it provides symbols which can be directly used as 'value's. However, it prevents applying dead stripping to the compiled code since the linker will incorrectly attribute the object header to the preceding symbol.

Additional information

The attached patch fixes the above problem by moving the symbols from the "value" position to the "header pointer" position. Referring to the same example as above, with this patch ocamlopt will emit:

    ; Behavior after patch
    .data

_camlExample__1:
.long 2300 ; wosize=2, color=0, tag=string
.ascii "Hello"
.space 2
.byte 2 ; = (wosize*size_addr)-(strlen+1)

In assembly and within the runtime, references to statically allocated objects are changed to use symbol+displacement references instead of bare symbol references. Here's an example of that change from the startup file:

    ; Existing behavior
    .data
    .globl  _caml_exn_Out_of_memory
    .long   1024

_caml_exn_Out_of_memory:
.long L100002
.long 4348
L100002:
.ascii "Out_of_memory"
.space 2
.byte 2
.globl _caml_bucket_Out_of_memory
.long 1024
_caml_bucket_Out_of_memory:
.long _caml_exn_Out_of_memory

    ; Behavior after patch
    .data
    .globl  _caml_exn_Out_of_memory

_caml_exn_Out_of_memory:
.long 1024
.long L100002 + 4
L100002:
.long 4348
.ascii "Out_of_memory"
.space 2
.byte 2
.globl _caml_bucket_Out_of_memory
_caml_bucket_Out_of_memory:
.long 1024
.long _caml_exn_Out_of_memory + 4

References from code are modified similarly. Since the linker performs these displacement calculations, there is no runtime cost associated with this change.

This change should be binary compatible with compiled C extensions. However, it does break binary compatibility for ocamlopt output (obviously) and with the runtime (see asmrun/fail.c).

The patch is based on CVS HEAD as of 2007-10-10 01:08:08 UTC. It has been tested on Darwin x86 and PowerPC, primarily by make opt.opt, but also with the test directory (for whatever that's worth). Other architectures have been updated, but not tested (or even compiled!). However, the architecture-specific changes are both trivial and mechanical, so this shouldn't be much of a problem.

Caveats:

  • I have observed that after the patch is applied, the i386 instruction selector occasionally will emit lea;movl instead of a simple movl as before the patch.
  • In one instance only, I observed that the change introduced a seemingly unnecessary register copy. I have not scrutinized the PowerPC codegen in that level of detail.

With this change, it would be possible to move static exceptions from the startup assembly into the runtime. The only problem in doing so would be encoding Ocaml strings in C.

File attachments

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 18, 2020
@mshinwell
Copy link
Contributor

There is some work going on with respect to dead code elimination at the moment, and this pull request contains an interesting observation that may be relevant. I'd rather leave this open.

@mshinwell mshinwell removed the Stale label May 18, 2020
bobzhang added a commit to rescript-lang/ocaml that referenced this issue May 27, 2020
anmonteiro pushed a commit to melange-re/ocaml that referenced this issue Mar 9, 2021
bobzhang added a commit to rescript-lang/ocaml that referenced this issue Mar 15, 2021
@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants