In <caml/major_gc.h> declare some variables 'extern' #1770
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The variables in question are caml_major_ring, caml_major_ring_index, and caml_major_work_credit. It is correct C code to declare those variables in the .h without a storage class, in which case they are treated as "common" variables by the linker. However, this causes problems with Clang's address sanitizer: it increases the size of the common variable when it is used, but leaves it unchanged when it is not. As a consequence, the linker sees several occurrences of a "common" variable with different sizes. The linker does the right thing and takes the "max" of the sizes, but not without printing an annoying warning, which is then reported as suspicious behavior by ocamltest. This commit puts "extern" storage class on the incriminated variables in <caml/major_gc.h>, consistently with the other GC variables.
|
@damiendoligez please review ASAP, this is your code, and I'd like the fix to go in 4.07. |
And add proper declaration in byterun/fix_code.c and asmrun/startup.c (the places where this table is initialized). As explained in commit 74ce561, it is preferable to declare variables "extern" in .h files and have them declared non-extern only once, in a .c file.
|
For completeness I used clang's warnings to find other variables that should be |
|
Reviewers are hard to find and code is obviously correct, so I take responsibility for merging. |
xavierleroy
added a commit
that referenced
this pull request
May 16, 2018
GPR #1770. * In <caml/major_gc.h> declare some variables 'extern' The variables in question are caml_major_ring, caml_major_ring_index, and caml_major_work_credit. It is correct C code to declare those variables in the .h without a storage class, in which case they are treated as "common" variables by the linker. However, this causes problems with Clang's address sanitizer: it increases the size of the common variable when it is used, but leaves it unchanged when it is not. As a consequence, the linker sees several occurrences of a "common" variable with different sizes. The linker does the right thing and takes the "max" of the sizes, but not without printing an annoying warning, which is then reported as suspicious behavior by ocamltest. This commit puts "extern" storage class on the incriminated variables in <caml/major_gc.h>, consistently with the other GC variables. * In <caml/intext.h> declare `caml_code_fragments_table` as extern And add proper declaration in byterun/fix_code.c and asmrun/startup.c (the places where this table is initialized). Same reasons as above.
|
Cherry-pciked in 4.07, 1161b77 |
|
Note that COMMON data is a source of other problems anyway (https://caml.inria.fr/mantis/view.php?id=5693). |
gasche
pushed a commit
that referenced
this pull request
Sep 26, 2021
GPR #1770. * In <caml/major_gc.h> declare some variables 'extern' The variables in question are caml_major_ring, caml_major_ring_index, and caml_major_work_credit. It is correct C code to declare those variables in the .h without a storage class, in which case they are treated as "common" variables by the linker. However, this causes problems with Clang's address sanitizer: it increases the size of the common variable when it is used, but leaves it unchanged when it is not. As a consequence, the linker sees several occurrences of a "common" variable with different sizes. The linker does the right thing and takes the "max" of the sizes, but not without printing an annoying warning, which is then reported as suspicious behavior by ocamltest. This commit puts "extern" storage class on the incriminated variables in <caml/major_gc.h>, consistently with the other GC variables. * In <caml/intext.h> declare `caml_code_fragments_table` as extern And add proper declaration in byterun/fix_code.c and asmrun/startup.c (the places where this table is initialized). Same reasons as above. (cherry picked from commit 1161b77)
OlivierNicole
pushed a commit
to OlivierNicole/ocaml
that referenced
this pull request
Sep 30, 2022
GPR ocaml#1770. * In <caml/major_gc.h> declare some variables 'extern' The variables in question are caml_major_ring, caml_major_ring_index, and caml_major_work_credit. It is correct C code to declare those variables in the .h without a storage class, in which case they are treated as "common" variables by the linker. However, this causes problems with Clang's address sanitizer: it increases the size of the common variable when it is used, but leaves it unchanged when it is not. As a consequence, the linker sees several occurrences of a "common" variable with different sizes. The linker does the right thing and takes the "max" of the sizes, but not without printing an annoying warning, which is then reported as suspicious behavior by ocamltest. This commit puts "extern" storage class on the incriminated variables in <caml/major_gc.h>, consistently with the other GC variables. * In <caml/intext.h> declare `caml_code_fragments_table` as extern And add proper declaration in byterun/fix_code.c and asmrun/startup.c (the places where this table is initialized). Same reasons as above.
dra27
pushed a commit
to dra27/ocaml
that referenced
this pull request
Dec 12, 2022
GPR ocaml#1770. * In <caml/major_gc.h> declare some variables 'extern' The variables in question are caml_major_ring, caml_major_ring_index, and caml_major_work_credit. It is correct C code to declare those variables in the .h without a storage class, in which case they are treated as "common" variables by the linker. However, this causes problems with Clang's address sanitizer: it increases the size of the common variable when it is used, but leaves it unchanged when it is not. As a consequence, the linker sees several occurrences of a "common" variable with different sizes. The linker does the right thing and takes the "max" of the sizes, but not without printing an annoying warning, which is then reported as suspicious behavior by ocamltest. This commit puts "extern" storage class on the incriminated variables in <caml/major_gc.h>, consistently with the other GC variables. * In <caml/intext.h> declare `caml_code_fragments_table` as extern And add proper declaration in byterun/fix_code.c and asmrun/startup.c (the places where this table is initialized). Same reasons as above. (cherry picked from commit 1161b77)
dra27
pushed a commit
to dra27/ocaml
that referenced
this pull request
Dec 12, 2022
GPR ocaml#1770. * In <caml/major_gc.h> declare some variables 'extern' The variables in question are caml_major_ring, caml_major_ring_index, and caml_major_work_credit. It is correct C code to declare those variables in the .h without a storage class, in which case they are treated as "common" variables by the linker. However, this causes problems with Clang's address sanitizer: it increases the size of the common variable when it is used, but leaves it unchanged when it is not. As a consequence, the linker sees several occurrences of a "common" variable with different sizes. The linker does the right thing and takes the "max" of the sizes, but not without printing an annoying warning, which is then reported as suspicious behavior by ocamltest. This commit puts "extern" storage class on the incriminated variables in <caml/major_gc.h>, consistently with the other GC variables. * In <caml/intext.h> declare `caml_code_fragments_table` as extern And add proper declaration in byterun/fix_code.c and asmrun/startup.c (the places where this table is initialized). Same reasons as above. (cherry picked from commit 1161b77)
dra27
pushed a commit
to dra27/ocaml
that referenced
this pull request
Dec 12, 2022
GPR ocaml#1770. * In <caml/intext.h> declare `caml_code_fragments_table` as extern And add proper declaration in byterun/fix_code.c and asmrun/startup.c (the places where this table is initialized). Same reasons as above. (cherry picked from commit 1161b77)
dra27
pushed a commit
to dra27/ocaml
that referenced
this pull request
Dec 12, 2022
GPR ocaml#1770. * In <caml/major_gc.h> declare some variables 'extern' The variables in question are caml_major_ring, caml_major_ring_index, and caml_major_work_credit. It is correct C code to declare those variables in the .h without a storage class, in which case they are treated as "common" variables by the linker. However, this causes problems with Clang's address sanitizer: it increases the size of the common variable when it is used, but leaves it unchanged when it is not. As a consequence, the linker sees several occurrences of a "common" variable with different sizes. The linker does the right thing and takes the "max" of the sizes, but not without printing an annoying warning, which is then reported as suspicious behavior by ocamltest. This commit puts "extern" storage class on the incriminated variables in <caml/major_gc.h>, consistently with the other GC variables. * In <caml/intext.h> declare `caml_code_fragments_table` as extern And add proper declaration in byterun/fix_code.c and asmrun/startup.c (the places where this table is initialized). Same reasons as above. (cherry picked from commit 1161b77)
dra27
pushed a commit
to dra27/ocaml
that referenced
this pull request
Dec 12, 2022
GPR ocaml#1770. * In <caml/intext.h> declare `caml_code_fragments_table` as extern And add proper declaration in byterun/fix_code.c and asmrun/startup.c (the places where this table is initialized). Same reasons as above. (cherry picked from commit 1161b77)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The variables in question are caml_major_ring, caml_major_ring_index, and caml_major_work_credit.
It is correct C code to declare those variables in the .h without a storage class, in which case they are treated as "common" variables by the linker.
However, this causes problems with Clang's address sanitizer: it increases the size of the common variable when it is used, but leaves it unchanged when it is not. As a consequence, the linker sees several occurrences of a "common" variable with different sizes. The linker does the right thing and takes the "max" of the sizes, but not without printing an annoying warning, which is then reported as suspicious behavior by ocamltest.
This commit puts "extern" storage class on the incriminated variables in <caml/major_gc.h>, consistently with the other GC variables.