Thank you @dinosaure . As @Kensan pointed in #562 I though about adding something rather than removing the /DISCARD/ part. It seems that it's mandatory to add the lines in the asm files and not in thge linker script. About this PR and the change proposed at https://github.com/codelabs-ch/solo5/tree/asm-noexec-stack, when I compile qubes-mirage-firewall, I have:

• current head

/usr/bin/ld: warning: /home/user/.opam/4.14.1/bin/../lib/x86_64-solo5-none-static/solo5_xen.o: requires executable stack (because the .note.GNU-stack section is executable)

• this PR

/usr/bin/ld: warning: /home/user/.opam/4.14.1/bin/../lib/x86_64-solo5-none-static/solo5_xen.o: requires executable stack (because the .note.GNU-stack section is executable)

• the commit proposed that add some asm notes

/usr/bin/ld: warning: amd64.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker

That warning comes from the caml compiler directory, so it might be relevant to also investigate there.

So to me the issue should be fixed by https://github.com/codelabs-ch/solo5/tree/asm-noexec-stack :)

Yes, I agree to put the .note.GNUinto assembly code and discard it at the link time 👍.

That warning comes from the caml compiler directory, so it might be relevant to also investigate there.

You mean with ocaml-solo5? Not sure to understand well this warning. The warning will be deleted then in next versions of the linker?

You mean with ocaml-solo5? Not sure to understand well this warning. The warning will be deleted then in next versions of the linker?

The only amd64.o I've found is in ~/.opam/default/.opam-switch/build/ocaml-solo5.xxx/ocaml/runtime/ and ocaml has assembly files (e.g. https://github.com/ocaml/ocaml/blob/trunk/runtime/amd64.S). It seems that this warning has been recently added and reading https://discuss.ocaml.org/t/ld-error-missing-note-gnu-stack-section/12478 leave me thinking about adding the directive to ocaml-solo5.

So to me this is unrelated to solo5, the commit proposed by @Kensan LGTM.

To move forward I wonder if the best is to add (flags (:standard -cclib "-z noexecstack")) in ocaml-solo5 (if possible) or PR at ocaml to add a similar .section .note.GNU-stack,"",%progbits in the asm files? EDIT: As it seems there's no issue about that in the ocaml repository, it's probably relevant to ocaml-solo5 :)

To move forward I wonder if the best is to add (flags (:standard -cclib "-z noexecstack")) in ocaml-solo5 (if possible) or PR at ocaml to add a similar .section .note.GNU-stack,"",%progbits in the asm files? EDIT: As it seems there's no issue about that in the ocaml repository, it's probably relevant to ocaml-solo5 :)

So, I will let this PR opens but we probably should check if the warning continues to appear if we update ocaml-solo5.

Is there any solution for this PR? Should it be included in solo5, or can it be left out (and closed)?

I would suggest to follow the same strategy than what was merged in the compiler in [ocaml/ocaml#13735], namely to do just as the C compiler does: the logic the C compiler uses to determine whether it should output the .note.GNU-stack is more complex than it appears (I looked into clang at least, I don’t remember for GCC) and they are surprising special cases (% is not always the symbol chosen by the compiler, for instance), so copying the C compiler output is a lot safer.
So, we could do so by adding in bindings/GNUmakefile:

noexecstack.c:
	printf 'int f() {\n  return 0;\n}\n' > $@

noexecstack.s: noexecstack.c
	$(CC) $(CFLAGS) $(CPPFLAGS) -S $< -o $@

noexecstack.h: noexecstack.s
	grep -F .note.GNU-stack $< > $@

and adding #include "noexecstack.h" in the .S files instead of using directly the note.

Thanks for your solution. I still think that this PR is not yet needed for Solo5 as we discovered. I will still keep this PR open the time that we get the same issue again but let's keep Solo5 simple as long as we don't need to deal with .note.GNU-stack.

I'm still uncertain what we need to do here. Is #562 still an issue, and is there a reasonable fix (this PR, or a different one)?

I still think that the issue is much more related to ocaml-solo5 than solo5 itself. I noticed the error only when it's about building an unikernel with ocaml-solo5 and never saw this error when it's about just compile a (C?) unikernel with Solo5. So, I'm not sure that we should merge it and probably just double check GCC versions used, if it's about ocaml-solo5 or if we can reproduce the error with a simpe C unikernel.

In our CI, we see the warnings. So I'd guess it is about solo5. Also, @Kensan proposed in #562 (comment) a different solution.

The issue is really in Solo5. The patches to OCaml fixed this issue in the code generated by the compiler. The fix in the compiler is doing something similar to what I wrote in my comment above: it calls the C compiler and mimicks its behaviour later on.

@shym oh. or maybe you have a good idea for how to patch solo5? It may be based on @Kensan branch, or your idea from above. Any PR that fixes the warning would be great.

Any PR that fixes the warning would be great.

#619 is what I had in mind.