Bug 1601175
| Summary: | -static-libstdc++ no longer bundles widechars etc. on ppc64 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Developer Toolset | Reporter: | Jan Kratochvil <jan.kratochvil> | ||||||
| Component: | gcc | Assignee: | Marek Polacek <mpolacek> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Martin Cermak <mcermak> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | DTS 8.0 RHEL 6 | CC: | jakub, jan.kratochvil, kanderso, law, mcermak, mnewsome, mpolacek, ohudlick | ||||||
| Target Milestone: | alpha | ||||||||
| Target Release: | 8.0 | ||||||||
| Hardware: | ppc64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2020-01-14 17:12:42 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jan Kratochvil
2018-07-14 14:03:00 UTC
This might have started with r262268, but I'm not sure at all. CCing Alex if he has any ideas whether this is harmless or not. I don't see how it could affect .symtab so brutally on one platform and not in another. Symbols referenced in locations would appear either in a single location or in a loclist, so this shouldn't be the source of a difference. An increase (or reduction as it is) in the number of symbols might arise out of a variation in the number of loclist symbols, but then this patch would cause the opposite effect from the one observed. Plus, loclist symbols shouldn't be in symtab anyway: being .L symbols, they should be resolved to section+offset. Having taken a look at the changes to the gcc-8 branch between the given dates, my educated guess is that this sort of change is not an effect of any change in GCC, but rather of changes in binutils, though I haven't reviewed changes there, if any. If that's at all possible, I would start the investigation there. That actually makes a lot of sense; I also couldn't find anything that would stand out. Hi Jan, > Description of problem: > rpmdiff warned me about debuginfo size reduction and it really look > suspicious to me. It is because with newer GCC ppc64 contains most of the > symbols in .dynsym instead of .symtab. In theory this should be OK. Both sections are symbol tables. The only difference is that .dynsym is intended to contain only those symbols needed by the dynamic loader, whereas .symtab can contain any symbol. > Version-Release number of selected component (if applicable): > PASS: GNU C++14 8.1.1 20180626 (Red Hat 8.1.1-4) > ppc64 vs. x86_64 contained about the same number of .symtab entries > FAIL: GNU C++14 8.1.1 20180712 (Red Hat 8.1.1-5) > ppc64 does contain 3x less .symtab entries than x86_64 Do you know the versions of the binutils package that were installed for the PASS and FAIL results ? > 4 files shrank significantly on ppc64: > /usr/lib/debug/opt/rh/devtoolset-8/root/usr/bin/gdbserver.debug: from > 7692984 to 7430768 bytes (-3%) > /usr/lib/debug/opt/rh/devtoolset-8/root/usr/lib64/libinproctrace.so.debug: > from 2957216 to 2693744 bytes (-8%) > /opt/rh/devtoolset-8/root/usr/bin/gdbserver: from 1714936 to 927440 bytes > (-45%) > /opt/rh/devtoolset-8/root/usr/lib64/libinproctrace.so: from 1774712 to > 528344 bytes (-70%) Just to confirm - you are concerned about the 8% reduction in the size of the libinproctrace.so.debug file and not the 70% decrease in the size of the libinproctrace.so binary yes ? I have a strong suspicion that this phenomenon might actually be the result of a bug-fix to the annobin package. There was a time when using annobin would stop the linker's unused section garbage collection from working. So unused sections would remain in the resulting binaries and hence you would get a lot of unneeded symbols (in both .symtab and .dynsym). This has now been fixed so the linker garbage collection works again. You say however that you would expect (approximately) the same number of symbols in the x86_64 and ppc64 versions of the package. What are the symbol counts for the two architectures ? (The link you posted has expired and I am currently building a scratch rhel-8 gdb package of my own, but it would be good to be sure that we are on the same page). Cheers Nick Hi Jan, Sorry - I was confusing RHEL-8 and DTS-8. The annobin thing probably is a red herring for DTS-8. Back to investigating... Cheers Nick Hi Nick, (In reply to Nick Clifton from comment #5) > In theory this should be OK. Both sections are symbol tables. The only > difference is that .dynsym is intended to contain only those symbols needed > by the dynamic loader, whereas .symtab can contain any symbol. I understand it should be OK, it is just slightly less efficient as more data are (needlessly?) contained in the main binary. Primarily we should know why it has changed, then we should be fine with that. Personally I do not see a reason for such change and as I had to waive this size regression I do not want to be my fault that we/I missed some file size regression bug. So I filed this Bug to reassign responsibility of waiving that rpmdiff file size regression. > Do you know the versions of the binutils package that were installed for > the PASS and FAIL results ? In both builds it was: binutils-2.20.51.0.2-5.42.el6.ppc64.rpm https://brewweb.engineering.redhat.com/brew/packageinfo?packageID=66519 -> devtoolset-8-gdb-8.1-23.el6 https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=723030 https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=17129136 https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=17129186 https://brewweb.engineering.redhat.com/brew/buildrootinfo?buildrootID=4197941 https://brewweb.engineering.redhat.com/brew/rpmlist?buildrootID=4197941&type=component -> devtoolset-8-gdb-8.1-24.el6 https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=724607 https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=17172963 https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=17172999 https://brewweb.engineering.redhat.com/brew/buildrootinfo?buildrootID=4210033 https://brewweb.engineering.redhat.com/brew/rpmlist?buildrootID=4210033&type=component > > 4 files shrank significantly on ppc64: > > /usr/lib/debug/opt/rh/devtoolset-8/root/usr/bin/gdbserver.debug: from > > 7692984 to 7430768 bytes (-3%) > > /usr/lib/debug/opt/rh/devtoolset-8/root/usr/lib64/libinproctrace.so.debug: > > from 2957216 to 2693744 bytes (-8%) > > /opt/rh/devtoolset-8/root/usr/bin/gdbserver: from 1714936 to 927440 bytes > > (-45%) > > /opt/rh/devtoolset-8/root/usr/lib64/libinproctrace.so: from 1774712 to > > 528344 bytes (-70%) > > Just to confirm - you are concerned about the 8% reduction in the size of > the libinproctrace.so.debug file and not the 70% decrease in the size of > the libinproctrace.so binary yes ? I am just concerned some .symtab vs. dynsym classicifcation has changed in the toolchain and I do not know why. If it was .dynsym->.symtab then I would find it as an improvement. But given it is .symtab->.dynsym it is less optimal and it could indicate some uncaught change side-effect==regression. Please ignore ignore these 4 lines from rpmdiff and rathe check the *.rpm files themselves as these messages are buggy/misleading. In fact debuginfo.rpm size "shrank" while main.rpm size increased (the rpmdiff messages above would indicate the opposite IMO). > I have a strong suspicion that this phenomenon might actually be the > result of a bug-fix to the annobin package. There was a time when > using annobin would stop the linker's unused section garbage collection > from working. So unused sections would remain in the resulting binaries > and hence you would get a lot of unneeded symbols (in both .symtab and > .dynsym). This has now been fixed so the linker garbage collection works > again. The problem is that the main rpm .dynsym section now contains significantly _more_ symbols than before. Which is always bad (sure nothing serious). > You say however that you would expect (approximately) the same number of > symbols in the x86_64 and ppc64 versions of the package. What are the > symbol counts for the two architectures ? (The link you posted has expired > and I am currently building a scratch rhel-8 gdb package of my own, but it > would be good to be sure that we are on the same page). Please check the rpm files yourself, they are still downloadable for me from: https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=723030 https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=724607 (In reply to Jan Kratochvil from comment #7) Hi Jan, > The problem is that the main rpm .dynsym section now contains significantly > _more_ symbols than before. Which is always bad (sure nothing serious). > Please check the rpm files yourself, they are still downloadable for me from: > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=723030 > https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=724607 OK, I downloaded the x86_64 and ppc64 rpms from those two builds, but the problem that I see is that the ppc64 files in the -24 build now contain significantly *less* symbols than they did in the -23 build, and also significantly less symbols than the equivalent x86_64 -24 build. Specifically: libinproctrace.so: x86_64 (-23 build): 3389 symbols (-24 build): 3389 symbols ppc64 (-23 build): 3633 symbols (-24 build): 886 symbols libinproctrace.so.debug: x86_64 (-23 build): 4293 symbols (-24 build): 4293 symbols ppc64 (-23 build): 4553 symbols (-24 build): 1385 symbols I do not see a movement of symbols from the .symtab in the .debug file into the .dynsym of the .so file, just an overall reduction in the number of symbols in both symbol tables. To me this would indicate that there is less compiled code in the -24 ppc64 version. Not sure why though. (Incidentally, when I ran my own scratch build of gdb for DTS-8 the symbol counts were a lot less for both x86_64 and ppc64, ~123 symbols in the .so and ~500 symbols in the .debug file. I am not sure why that is. Possibly scratch builds are stripped and your builds are not ?). Anyway, it is late and I need to ponder this, so I will resume investigating in the morning. Cheers Nick Hi Jan, Thinking about it overnight, it seems to me that if the same version of the binutils was used in both the pass and fail cases, then it is unlikely that the binutils are the culprit... (I also considered the possibility that the problem is with the eu-strip program from the elfutils package. But the same version of that package is used in both builds too). In fact I looked that the root logs for the ppc64 -23 and -24 builds and could not find any differences! So I took a look at the dynamic symbol tables for the -23 and -24 ppc64 builds and found that the issue appears to be that the -24 build is missing *all* of the internationalization / translation / locale support... Functions like collate() and moneypunct() are missing, and calls to glibc functions like duplocale() and iswctype() are absent. This is about as far as I can take the investigation. My gut says that you ought to reject the build because something has gone wrong with the internationalization support in the ppc64 target. But I have no idea what has caused this, and whether this is just a temporary sanfu in the build system somewhere, or whether it will be a repeatable offence. Cheers Nick The only buildroot differences are: -devtoolset-8-gcc-8.1.1-4.el6.ppc64.rpm +devtoolset-8-gcc-8.1.1-5.el6.ppc64.rpm -devtoolset-8-gcc-c++-8.1.1-4.el6.ppc64.rpm +devtoolset-8-gcc-c++-8.1.1-5.el6.ppc64.rpm -devtoolset-8-libstdc++-devel-8.1.1-4.el6.ppc64.rpm +devtoolset-8-libstdc++-devel-8.1.1-5.el6.ppc64.rpm +devtoolset-8-make-1:4.2.1-4.el6.ppc64.rpm Checking it more. devtoolset-8-gdb-8.1-23.el6. ppc64 dts8-gcc-8.1.1-4 .dynsym=3633 .symtab=4553 devtoolset-8-gdb-8.1-24.el6. ppc64 dts8-gcc-8.1.1-5 .dynsym= 886 .symtab=1385 It would look OK that newer GCC does not bundles some needless functions (some wide-character funcs etc.) but: devtoolset-8-gdb-8.1-24.el6.x86_64 dts8-gcc-8.1.1-5 .dynsym=3389 .symtab=4293 So when ppc64 does not need them why x86_64 still does need them? This is somehow suspicious to me. I haven't tried other archs than ppc64+x86_64. g++ -shared -fPIC -Wl,--soname=libinproctrace.so -Wl,--no-undefined -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mminimal-toc -Wno-error=cast-function-type -Wno-error=stringop-truncation -DGDB_INDEX_VERIFY_VENDOR -DNEED_DETACH_SIGSTOP -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wformat-nonliteral -Wno-unused -Werror -DGDBSERVER -static-libstdc++ -static-libgcc -Wl,--dynamic-list=../../../gdb/gdbserver/proc-service.list -o libinproctrace.so ax-ipa.o common-utils-ipa.o errors-ipa.o format-ipa.o print-utils-ipa.o regcache-ipa.o remote-utils-ipa.o rsp-low-ipa.o tdesc-ipa.o tracepoint-ipa.o utils-ipa.o vec-ipa.o powerpc-32l-ipa.o powerpc-altivec32l-ipa.o powerpc-cell32l-ipa.o powerpc-vsx32l-ipa.o powerpc-isa205-32l-ipa.o powerpc-isa205-altivec32l-ipa.o powerpc-isa205-vsx32l-ipa.o powerpc-e500l-ipa.o powerpc-64l-ipa.o powerpc-altivec64l-ipa.o powerpc-cell64l-ipa.o powerpc-vsx64l-ipa.o powerpc-isa205-64l-ipa.o powerpc-isa205-altivec64l-ipa.o powerpc-isa205-vsx64l-ipa.o linux-ppc-ipa.o -ldl -pthread One gets: devtoolset-8-gcc-8.1.1-4.el6.ppc64.rpm -rwxr-xr-x. 1 root root 4789432 Aug 17 17:06 libinproctrace.so devtoolset-8-gcc-8.1.1-5.el6.ppc64.rpm -rwxr-xr-x. 1 root root 3251624 Aug 17 17:08 libinproctrace.so Created attachment 1476644 [details]
gdbo.tar.xz with *.o files to link
Created attachment 1476645 [details]
diff which functions did / did not get bundled
Tested on RHEL-6.10 ppc64: https://beaker.engineering.redhat.com/recipes/5528992 -devtoolset-8-gcc-8.1.1-4.el6.ppc64.rpm +devtoolset-8-gcc-8.1.1-5.el6.ppc64.rpm one change was enabling libquadmath on ppc64, so I think that explains why we see some changes only on ppc64. I think this must be the reason. But then it is suspicious x86_64 already had+has libquadmath enabled while x86_64 bundling looks like (=the number of bundled symbols look like) that ppc64 one before libquadmath was enabled. :-) devtoolset-8-gdb-8.1-23.el6. ppc64 dts8-gcc-8.1.1-4 .dynsym=3633 .symtab=4553 devtoolset-8-gdb-8.1-24.el6. ppc64 dts8-gcc-8.1.1-5 .dynsym= 886 .symtab=1385 devtoolset-8-gdb-8.1-24.el6.x86_64 dts8-gcc-8.1.1-5 .dynsym=3389 .symtab=4293 I do not say there is a bug in GCC, just I have no idea why the change happened and I had to waive it in rpmdiff. I am OK with NOTABUG close but I do not know if it is right. https://rpmdiff.engineering.redhat.com/run/337844/5/ NEEDS INSPECTION - 4 files grew significantly on s390x: devtoolset-8-gdb-debuginfo /opt/rh/devtoolset-8/root/usr/bin/gdbserver: from 745152 to 1466024 bytes (+96%) /opt/rh/devtoolset-8/root/usr/lib64/libinproctrace.so: from 401336 to 1392592 bytes (+246%) - filenames are wrong - rpmdiff means the .debug files, not the binary files. This BZ had dev_ack+ by mistake, resetting back. By any chance, has this gone back to normal with any of the latest builds? The debuginfo size bounces around, often depending on binutils. I'm not sure what could be done on the GCC size, so I'm going to close this. |