[WIP] Adds debuginfo size to native-image output

[zakkak]

@fniephaus this is a draft implementation that outputs the debuginfo size along with the other stats.

It uses the objectfile sections' names to aggregate the sizes of those containing .debug in their name.
This should work for both linux:

.debug	This section holds information for symbolic debugging. The contents are unspecified. All section names with the prefix .debug hold information for symbolic debugging. The contents of these sections are unspecified.

Source: https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/specialsections.html

and windows:

The .debug section is used in object files to contain compiler-generated debug information and in image files to contain all of the debug information that is generated. This section describes the packaging of debug information in object and image files.

Source: https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#the-debug-section

WDYT?

[fniephaus]

Thanks! I'll look into this as soon as I can :)

[olpaw]

@stooke can you confirm that his approach will allow us also get the size of debuginfo for Windows?

[stooke]

@stooke can you confirm that his approach will allow us also get the size of debuginfo for Windows?

The debug section sizes will be counted properly by this code on Windows, where the sections are .debug$S and .debug$T, so this code works.

It's somewhat misleading, as the final debuginfo size in the executable is quite different. Not only does this not count debugInfo for any native code, but on Windows some of this information will end up in a separate .PDB file, not the executable. (similarly this can be true on Linux). Also, any COFF information added by the debugInfo code (e.g. new relocation table entries) is not reflected in this. Users mustn't assume there's any 1-1 object to executable correspondence.

[zakkak]

Thanks for looking into it @stooke!

It's somewhat misleading, as the final debuginfo size in the executable is quite different. Not only does this not count debugInfo for any native code...

That's true, but to my understanding @fniephaus was interested in the size of the debuginfo that GraalVM is generating and not the one that comes with native code that we don't control. Do you think people would be interested in the size of debug info not generated by GraalVM as well?

... but on Windows some of this information will end up in a separate .PDB file, not the executable. (similarly this can be true on Linux).

AFAIK in linux we currently store everything in the same binary, we don't split it.

Also, any COFF information added by the debugInfo code (e.g. new relocation table entries) is not reflected in this. Users mustn't assume there's any 1-1 object to executable correspondence.

That's interesting. Do you have any proposals on how we could properly report debuginfo size on windows if possible at all?

[stooke]

Thanks for looking into it @stooke!

It's somewhat misleading, as the final debuginfo size in the executable is quite different. Not only does this not count debugInfo for any native code...

That's true, but to my understanding @fniephaus was interested in the size of the debuginfo that GraalVM is generating and not the one that comes with native code that we don't control. Do you think people would be interested in the size of debug info not generated by GraalVM as well?

I don't know. it's always possible for someone that's really interested to dump the executable or strip it to see the size difference. To me, it's the time (and memory) we spend generating the debug Info that is more of an issue.

... but on Windows some of this information will end up in a separate .PDB file, not the executable. (similarly this can be true on Linux).

AFAIK in linux we currently store everything in the same binary, we don't split it.

Also, any COFF information added by the debugInfo code (e.g. new relocation table entries) is not reflected in this. Users mustn't assume there's any 1-1 object to executable correspondence.

That's interesting. Do you have any proposals on how we could properly report debuginfo size on windows if possible at all?

Linux might have the same issue. I don't think it's much, but you'd probably have to have code to measure the difference in reloc entries before and after the debuginfo generation phase. That's for the object file. The linker takes the debug info (especially type info) and rearranges it so the only valid way to do this for the executable itself is to run a tool after linking. Currently I think some of the information ends up in the .EXE, and some in the .PDB file.

[fniephaus]

Thanks @zakkak and @stooke! I have cherry picked @zakkak's commit and it's now part of #4106.

it's the time (and memory) we spend generating the debug Info that is more of an issue.

BTW: The time to generate the debug info is part of the new build output.