libsel4utils: remove unused environment setup

[anchao]

libsel4utils: remove unused environment setup

It is unnecessary to writing environment to the stack since the target environment size is always 0.

This PR also fix compile warning on native X86 build:

[2/8] Building C object apps/sel4test-driver/seL4_libs/libsel4utils/CMakeFiles/sel4utils.dir/src/process.c.obj
/home/archer/code/sel4/projects/seL4_libs/libsel4utils/src/process.c: In function ‘sel4utils_spawn_process_v’:
/home/archer/code/sel4/projects/seL4_libs/libsel4utils/src/process.c:320:13: warning: ‘sel4utils_stack_copy_args’ accessing 8 bytes in a region of size 0 [-Wstringop-overflow=]
  320 |     error = sel4utils_stack_copy_args(vspace, &process->vspace, vka, envc, envp, dest_envp, &initial_stack_pointer);
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/archer/code/sel4/projects/seL4_libs/libsel4utils/src/process.c:320:13: note: referencing argument 5 of type ‘char *[0]’
/home/archer/code/sel4/projects/seL4_libs/libsel4utils/src/process.c:209:12: note: in a call to function ‘sel4utils_stack_copy_args’
  209 | static int sel4utils_stack_copy_args(vspace_t *current_vspace, vspace_t *target_vspace,
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~
[8/8] Generating ../../images/sel4test-driver-image-x86_64-pc99

[FennelFoxxo]

+1
Getting the same compiler warning here too, this fixes it

[kent-mcleod]

Thanks, I agree that as no environment variables are ever able to be set, the lines being removed are not needed. The null-termination value for the empty environment section is still intentionally left in to be compatible with the init ABI.

[lsf37]

This merge might have broken something in the camkes examples, at least this PR is the only difference between the previous working run and the currently failing one in https://github.com/seL4/camkes-tool/actions/runs/10770953732/job/29866025686 for imx8mm.

Although I think we might have changed something on the machine queue side for imx8mm since then. @alwin-joshy / @Ivan-Velickovic could you have a brief look at that?

[alwin-joshy]

I think the uboot parameter might have been changed back to what it was before. Will look into it.

…

On Tue, 10 Sep 2024 at 00:09, Gerwin Klein ***@***.***> wrote: This merge might have broken something in the camkes examples, at least this PR is the only difference between the previous working run and the currently failing one in https://github.com/seL4/camkes-tool/actions/runs/10770953732/job/29866025686 for imx8mm. Although I think we might have changed something on the machine queue side for imx8mm since then. @alwin-joshy <https://github.com/alwin-joshy> / @Ivan-Velickovic <https://github.com/Ivan-Velickovic> could you have a brief look at that? — Reply to this email directly, view it on GitHub <#80 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADVFDBIL3RRFNP4OE5WNC7TZVWTYVAVCNFSM6AAAAABNZ4JLG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZYGIZTCNBSGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kent-mcleod]

It seems like an unrelated failure.

[alwin-joshy]

Yep, it's not to do with this commit, it's an issue with the machine queue. The cause is seL4/seL4_tools#205, and it seems like the load address of the imx8 in machine queue was changed back to the old one.

[alwin-joshy]

@lsf37 The address that uboot loads the image to has been changed back to 0x42000000, so the CI should run now.

[lsf37]

Thanks, can confirm that CI is working again.