Add debug symbol version

[axot]

It will be useful when investigating PHP segmentation. For now, we have to build a custom image for this purpose. What do you think about it?

[phy25]

Duplicate of #709, #530.

[axot]

There are risks to enable --enable-debug, some pecl extensions may get a problem with this. My suggestion is just using -g -O2.

[tianon]

Adding -g wouldn't help because we explicitly strip everything post-build:

php/Dockerfile-debian.template

Line 183 in d367f7f

find /usr/local/bin /usr/local/sbin -type f -executable -exec strip --strip-all '{}' + || true; \

It would be interesting/useful to add something like du -hs /usr/local before/after that line (and adding -g to PHP_CFLAGS).

[axot]

Yes, In my local(alpine php-fpm) single php binary increased from 15M to 51M, the total size will increase 36*3 = 108M.

[HycarlDev]

can't we just remove the strip and add the -g to it?

[enumag]

Hello, since the debug images from @csandanov are no longer maintained, I'd like to again ask about the possibility of having official ones.

The latest reason against it I found is this comment from @tianon about already long build times.

I fail to understand why exactly it's an issue. If you properly prioritize the tasks and have the non-debug images built and published first (since admittedly the debug images are less important), longer build time shouldn't really matter in my opinion.

So what's the problem?

[yosifkit]

If you properly prioritize the tasks and have the non-debug images built and published first (since admittedly the debug images are less important)

It is not just the php image that would be slowed down by more php images, but any other images queued to build as well.

The build system is not designed to handle special prioritizing of tags within one image repo over other tags in the same repo (or even across image repos). The only ordering of builds is dependency based (FROM). Within a single image repo (like php), tags are ordered only if there is an image dependency otherwise the order of the library/php file is the order that they are built. Builds at this level only push once all tags are built and only push to an architecture specific namespace on Docker Hub (like amd64/php and arm64v8/php).

Since each architecture builds at differing speeds, a separate job called put-shared eventually combines the tags from different architectures to create the multi-architecture manifest found at the main "library" namespace for the image (php on Docker Hub)

See https://github.com/docker-library/oi-janky-groovy for the groovy generators that create the jobs. See also our FAQ repo: https://github.com/docker-library/faq#an-images-source-changed-in-git-now-what

[martinvonwittich]

Debug symbols would be extremely useful for the ability to attach to running PHP instances with gdb -p <pid> and to run zbacktrace as provided by PHP's php-src/.gdbinit to get a PHP stack trace. Here is an example how to use it: https://reverseengineering.stackexchange.com/questions/9558/how-to-get-current-php-function-name-in-gdb

The debug symbols don't even need to be included in the images; Debian provides their debug symbols in separate -dbgsym packages so that you can install these debug packages only when you actually need them. The build ID is used to identify the correct file that contains the debug symbols for a specific binary; the file is AFAIK generated with objcopy by the dh_strip debhelper build tool:

host ~ # file /usr/bin/php8.1 
/usr/bin/php8.1: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=31db10c6dec8cae42cfc103c4565817eacd6b1f9, for GNU/Linux 3.2.0, stripped
host ~ # ll /usr/lib/debug/.build-id/31/db10c6dec8cae42cfc103c4565817eacd6b1f9.debug 
-rw-r--r-- 2 root root 8,3M 11. Jul 10:55 /usr/lib/debug/.build-id/31/db10c6dec8cae42cfc103c4565817eacd6b1f9.debug

The build process of the PHP docker images could generate these debug files and e.g. host them on a web server, where people could download them as needed.

[tianon]

Closing via #1364 (which is as close as we plan to get to this)