[debug] collect all binaries generated with -g

[vvlevchenko]

Summary

This prototype of fix #276

Use Cases

build of debug binaries with graalvm

[linux-foundation-easycla]

• ❌ - login: @vvlevchenko / name: Vasily Levchenko . The commit (7df9263) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[anthonydahanne]

hello @vvlevchenko !
Thanks for your issue and PR! Please don't forget to sign the CLA!

I understand that native-image -g would produce 2 binaries.
You seem to suggest in your PR that the user would specify GraalVM arguments to pass the -g
How do you envision buildpacks to embed them? the 2 binaries in the same layer with an option (env var) to choose between each of them? or rather using multi process selection (https://buildpacks.io/docs/app-developer-guide/run-an-app/)?
Thanks!

[dmikusa]

I think this merits a discussion about default behavior as well.

Paketo targets producing production images, which would not typically include debug information as that would result in larger images.

I like the idea of auto detecting the -g flag, so when that's present we'd retain the debug info but I think we should output a warning message as a reminder that the debug flag is on and will result in larger images.

[vvlevchenko]

I think this merits a discussion about default behavior as well.

Paketo targets producing production images, which would not typically include debug information as that would result in larger images.

I like the idea of auto detecting the -g flag, so when that's present we'd retain the debug info but I think we should output a warning message as a reminder that the debug flag is on and will result in larger images.

Hello @dmikusa,

Sorry for delay, the main reason why user need debug info for containerised build is lack of debugger support for Windows and Mac OS hosts, so the user on these platforms can only relay on containerised builds or debugging JVM variants which is not the same.

[vvlevchenko]

Hello @anthonydahanne!
Sorry for delay,

hello @vvlevchenko ! Thanks for your issue and PR! Please don't forget to sign the CLA!
we're in process with legal here :)

I understand that native-image -g would produce 2 binaries. You seem to suggest in your PR that the user would specify GraalVM arguments to pass the -g How do you envision buildpacks to embed them? the 2 binaries in the same layer with an option (env var) to choose between each of them? or rather using multi process selection (https://buildpacks.io/docs/app-developer-guide/run-an-app/)? Thanks!

Actually I amn't very familiar with buildpacks, and perhaps there are better ways. Scenario to debug binary is after getting the result image we're creating docker container which contains gdbserver, with entrypoint gdbserver :<port> /application/application

[dmikusa]

Thanks for the additional information.

A couple of additional concerns/discussion points:

1. We have an RFC for remote debugging. I think we should attempt to align any changes here with that RFC, that way we're following consistent patterns when it comes to remote debugging.
2. I think we need to look more closely at how it is detecting the output file. First, I think it should only deviate and look for debug files if we're doing a remote debug (i.e. it sees the -g flag). I don't want to have a case where it accidentally detects multiple files. Second, I think we should consider if there's a need to have the search operation configurable. We use pattern matching in a lot of places, would people expect that here as well.