On Wed, Jul 12, 2023 at 09:21:40PM +0200, Mark Wielaard wrote:
> Hi,
>
> On Wed, Jul 12, 2023 at 09:54:49AM -0600, Jerry James wrote:
> > On Wed, Jul 12, 2023 at 4:38 AM Richard W.M. Jones <rjones@xxxxxxxxxx> wrote:
> > > During the OCaml 5 rebuild I found there's a generic problem on s390x
> > > & ppc64le (ie. the bytecode-only architectures) involving stripping of
> > > OCaml binaries. [...]
> > >
> > > The binary is correct when built, but gets corrupted after one of
> > > these steps is applied (not sure which):
> > >
> > > + /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
> > > + /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
>
> OK, that is later than I suspect. I believe these steps run after the
> debuginfo packages are created. And I don't know much about these
> steps, so if that is the case my advise might not be relevant.
>
> > > Anyway this could potentially affect any s390x / ppc64le OCaml package
> > > that contains a binary so it's something to look out for ... For some
> > > reason dune doesn't seem to be affected.
> > [...]
> > I encountered that with a couple of packages, ocaml-findlib and
> > coccinelle. Sorry I missed the others. Yes, stripping those binaries
> > removes the bytecode payload, leaving only the bytecode interpreter.
> > I also noticed that dune isn't affected, which is interesting. I
> > wonder if it is the difference between -output-complete-exe and
> > -custom. Dune now uses the former instead of the latter.
>
> It would be interesting to know what the difference between these
> methods is. Specifically if they create different names (or
> alloced/unalloced) ELF sections.
A way to reproduce the issue is:
$ echo 'print_endline "hello world"' > test.ml
$ echo 'void f(void) {}' > test-c.c
$ ocamlc -custom -o test test.ml test-c.c
$ ll test
-rwxr-xr-x. 1 rjones rjones 1406334 Jul 12 22:25 test
$ ./test
hello world
$ strip ./test
$ ./test --version
unknown option --version
$ ./test
no bytecode file specified
If you replace -custom with -output-complete-exe then it does actually
work fine, so probably that's the answer to our problem. Anyhow,
continuing with the analysis of -custom ...
I looked through the section names with objdump -h and none of them
looked unusual. However I think in the past when we analyzed this we
found it was doing something really crazy, like actually appending the
bytecode to the file (ie. not using the ELF format at all).
I will look at whether we can fix this using -output-complete-exe in
supermin. The documentation says:
-output-complete-exe
Build a self-contained executable by linking a C object file
containing the bytecode program, the OCaml runtime system and any
other static C code given to ocamlc. The resulting effect is
similar to -custom, except that the bytecode is embedded in the C
code so it is no longer accessible to tools such as ocamldebug. On
the other hand, the resulting binary is resistant to strip.
which looks like what we need.
Rich.
> If the issue is with creating the debuginfo packages, then it likely
> is because there is an (unallocated) ELF section which is moved from
> the main executable to the .debug file (because debuginfo-find
> believes it isn't needed at runtime.
>
> In that case, and you can find out how such sections are named, then
> you might be able to workaround it by adding someting like:
>
> %define _find_debuginfo_opts --keep-section .special_ocaml_bytecode
>
> Cheers,
>
> Mark
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
