Silence ld warning with libasmrun_shared.so#13496
Conversation
|
I thought that I fixed these by testing on precheck a couple of years ago, but that's definitely worth a look, thanks! The full test is: $ cat hello.ml
print_endline "hello, world"
$ cat main.c
#define CAML_INTERNALS
#include <caml/callback.h>
int main_os(int argc, char_os **argv)
{
caml_startup(argv);
caml_shutdown();
return 0;
}
$ ocamlopt -output-obj -o ocaml.o hello.ml
$ gcc -o hello ocaml.o main.c -I $(ocamlopt -where) -L $(ocamlopt -where) -lasmrun_shared -lm
/usr/bin/ld: warning: type and size of dynamic symbol `caml_system__frametable' are not defined |
|
Thanks. Running that on Ubuntu 24.04 s390x doesn’t give any warnings about
missing size. It seems like it should be a warning or at least is more
correct with that annotation.
…On Mon, 30 Sep 2024 at 4:43 pm, David Allsopp ***@***.***> wrote:
I thought that I fixed these by testing on precheck a couple of years ago,
but that's definitely worth a look, thanks! The full test is:
$ cat hello.mlprint_endline "hello, world"
$ cat main.c#define CAML_INTERNALS#include <caml/callback.h>
int main_os(int argc, char_os **argv){ caml_startup(argv); caml_shutdown(); return 0;}
$ ocamlopt -output-obj -o ocaml.o hello.ml
$ gcc -o hello ocaml.o main.c -I $(ocamlopt -where) -L $(ocamlopt -where) -lasmrun_shared -lm/usr/bin/ld: warning: type and size of dynamic symbol `caml_system__frametable' are not defined
—
Reply to this email directly, view it on GitHub
<#13496 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABJXOOJ33RT35V5TGCUS43ZZDXIFAVCNFSM6AAAAABPBV7N4WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBSGI2DAMBQG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
It appears that the # With .type and no .size
tsmc@s390x-worker-01:~/ocaml$ nm -S --print-size runtime/s390x.o |grep frametable
0000000000000000 D caml_system.frametable
# With .type and .size
tsmc@s390x-worker-01:~/ocaml$ nm -S --print-size runtime/s390x.o |grep frametable
0000000000000000 0000000000000028 D caml_system.frametableInterestingly if you just add It feels more correct to have both but it seems to not make a difference. I leave it up to you @dra27 |
|
Given that we are readily able to emit the correct versions of both directives, I think we should. Apparently these warnings are relatively new; perhaps |
|
Nick Barnes (2024/10/01 02:16 -0700):
Given that we are readily able to emit the correct versions of both
directives, I think we should.
Yes, I do agree with that!
|
runtime/power.S
Outdated
| .short -1 /* negative frame size => use callback link */ | ||
| .short 0 /* no roots here */ | ||
| .align 3 | ||
| .size caml_system.frametable, .-caml_system.frametable |
There was a problem hiding this comment.
For consistency with other platforms, you should probably add a ENDOBJECT macro and use it here.
There was a problem hiding this comment.
I expect my original thinking (in 2022) was along the lines that there was no alternate version so it didn't need a macro... how does 7be1ad0 (putting in both OBJECT and ENDOBJECT to both) look?
There was a problem hiding this comment.
Almost good! The .section directives should be left outside of these macros, however.
There was a problem hiding this comment.
Done (finally - sorry for the delay)
|
I pushed an extra commit applying the pattern of 7be1ad0 ( |
We should, eventually (not necessarily in this PR, though). |
|
I think one's good to go as steps in the correct direction? (and eliminating that pesky warning!) |
|
My approval (for what little it's worth) still stands in today's version. |
|
Your review & approval on these things is much appreciated, thank you! |
amd64 and power were missing .type and .size directives on caml_system.frametable which causes a warning from ld when linking against the shared runtime.
|
Approving this on behalf of @dustanddreams |
The amd64 and power backends were missing .type and .size directives on caml_system.frametable which causes a warning from ld when linking against the shared runtime.
Prior to this PR, when linking with libasmrun.so, ld emits:
I'd like to put this on 4.14, where the i386 backend also has the same issue.