Offer quarkus property to enable debug symbols

[emmanuelbernard]

Now that GraalVM has debug symbols, have a Quarkus property

e.g. quarkus.native.debug-symbols

so it generates the image with debug symbols.

Useful in conjunction with profiles

[emmanuelbernard]

Hey @galderz or @dmlloyd , would you have time for this one ?

[galderz]

@emmanuelbernard sure assign it to me, but there's some obstacles to resolve before then.

I started playing with debug symbols and Quarkus a few days back, which led me to finding #9750.

Once that was fixed I tried to debug it with gdb 7.6, but gdb threw a segmentation fault. I tried with latest gdb 9.2 and at least that loaded the image with symbols, but I've not tried to step through the code yet to see if I can move between lines/code...etc.

Assuming that works fine, the tricky thing is access to sources. Some source zip files seem to be missing which @adinn spotted oracle/graal#2551. In my local testing I was just linking to locally built src zip files.

Once all of that is figure out we can wrap it up with the addition of the property.

Finally, @n1hility has requested for symbols to be kept in a separate file. That's not the case at the moment; symbols are kept in the same file as the binary. I'm checking to see how much would would that involve, how we're tracking that...etc.

[emmanuelbernard]

OK, considering we would really like to get this one in 1.6, I propose we can add the high level Quarkus property to wire things all the way down. Whether GraalVM feature has bugs (or Quarkus has bugs) and whether we can move the symbols to a separate file, we should do as follow up tasks.

[gsmet]

Ah, yes, I will send the email right away.

[gsmet]

I created the wiki page the other day but forgot to send the email: https://github.com/quarkusio/quarkus/wiki/Release-Planning

[gsmet]

Done.

[galderz]

@emmanuelbernard Assigned this to me, I've started work on it.

[galderz]

@emmanuelbernard I've been chatting to @jerboaa and I'm thinking that -Dquarkus.native.debug-symbols might better be an enum rather than a boolean, because we plan to support debug symbols being stored inside the binary (e.g. internal) and debug symbols stored outside the binary (e.g. external). Would we change the property name then?

[galderz]

@emmanuelbernard Might be better if we discuss it in quarkus-dev google group?

[galderz]

Started a discussion on quarkus-dev about the configuration to expose. I will work with @jerboaa to see where we end up splitting symbols.

[emmanuelbernard]

yes I think the enum is fine. I had the same thoughts when talking with Andrew during Insights.

[emmanuelbernard]

What would be the values though?

[emmanuelbernard]

Also we need to make room for the ability to generate "more" debug symbols.

Is this external file supposed to be configurable in name and location?
I have two proposals depending on this

Proposition 1: not configurable or with sensible default file name value

quarkus.native.debug-symbols.enable=NONE|INTERNAL|EXTERNAL
quarkus.native.debug-symbols.external-file=c:\Users\Emmanuel\Quarkus\debug.symbols
quarkus.native.debug-symbols.level=moderate|goestoeleven

Proposition 2: must define a file name anyways

quarkus.native.debug-symbols.enable=true
# absence of external file means internal
quarkus.native.debug-symbols.external-file=c:\Users\Emmanuel\Quarkus|debug.symbols
quarkus.native.debug-symbols.level=moderate|goestoeleven

[emmanuelbernard]

I think 1 has my preference as sensible external file name might make a lot of sense.

[geoand]

I would go with 1

[rsvoboda]

Regarding quarkus.native.debug-symbols.enable=NONE|INTERNAL|EXTERNAL

• .enable evokes true/false being the value
• I always struggle between.enable and .enabled suffix, which one is the one
  • looking at https://quarkus.io/guides/all-config there are both ways being used and that's not ideal

I would go with with quarkus.native.debug-symbols=NONE|INTERNAL|EXTERNAL (drop .enable) or quarkus.native.debug-symbols.mode=NONE|INTERNAL|EXTERNAL (.enable => .mode)

[jerboaa]

@emmanuelbernard I'd like to avoid adding too many config values for this. OK for making the suffix configurable (defaulting to debug, say). The name of the external debug symbols would always be <binary>.<suffix>. Example foo, the binary, and foo.debug containing the debug symbols of binary foo with suffix debug (the default).

[galderz]

@emmanuelbernard I opened a quarkus-dev discussion, but anyway...

I agree with @rsvoboda, something that has enable in it seems like it should be true|false.

Also, note that quarkus.native.debug-symbols already exists today, as a boolean, that adds -g (enterprise edition flag). Would we deprecate that? Or we could just reuse it as is (boolean)? Or remove it?

I'd just for an enum (that allows us to introduce new options in the future, including different levels).

Then, about the debug symbols external file, I'd just leave that out for now. If there's an option to set the path of the native binary, then one could modify that and get the symbols location modified along (so that it sits next to it).

[maxandersen]

debug-symbols is a weird implementation detail for me.

should it not just to include debug info or not ? i.e. -g on javac and gcc compiler?.

[maxandersen]

for me what would make sense is that the debug file location default to .symbols and then have a quarkus.native.debug=<list of options where none means don't do it>.

have it default on and then you just need to do -Dquarkus.native.debug=none to turn it off.

If you want to tweak settings do -Dquarkus.native.debug=lines,goto11 or if it truly just is a integer level tehn:

-Dquarkus.native.debug.enabled=false to turn off and -Dquarkus.native.debug.level=11

[galderz]

All, further discussions in https://groups.google.com/forum/#!topic/quarkus-dev/VOSQ6zhy_vI