On Wed, Jun 1, 2022 at 10:16 AM Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > > On Wed, 2022-06-01 at 07:01 -1000, Steve Sakoman wrote: > > On Wed, Jun 1, 2022 at 6:32 AM Richard Purdie > > <richard.pur...@linuxfoundation.org> wrote: > > > > > > On Wed, 2022-06-01 at 06:21 -1000, Steve Sakoman wrote: > > > > On Wed, Jun 1, 2022 at 6:10 AM Richard Purdie > > > > <richard.pur...@linuxfoundation.org> wrote: > > > > > > > > > > On Wed, 2022-06-01 at 05:29 -1000, Steve Sakoman wrote: > > > > > > > > > > > > > > > Keep in mind that the test uses sstate to compare against so even that > > > > > isn't a guarantee of identifying the issue. > > > > > > > > > > Did you try the strings comparison I suggested? Do you have the file > > > > > section tables comparison (diff) I could look at? > > > > > > > > Are you referring to the section header info from objdump -h ? > > > > > > > > If so I've attached the a/b info, they are quite compact. > > > > > > Yes, I couldn't remember the option to objdump offhand. The diff looks > > > like: > > > > > > --- /tmp/headersa.txt 2022-06-01 17:22:57.272277627 +0100 > > > +++ /tmp/headersb.txt 2022-06-01 17:22:43.972218408 +0100 > > > @@ -1,5 +1,5 @@ > > > > > > -a/usr/lib/libwebkit2gtk-4.0.so.37.56.5: file format elf64-x86-64 > > > +b/usr/lib/libwebkit2gtk-4.0.so.37.56.5: file format elf64-x86-64 > > > > > > Sections: > > > Idx Name Size VMA LMA File off > > > Algn > > > @@ -63,15 +63,15 @@ > > > CONTENTS, READONLY, DEBUGGING, OCTETS > > > 29 .debug_abbrev 00c6ce64 0000000000000000 0000000000000000 921c9968 > > > 2**0 > > > CONTENTS, READONLY, DEBUGGING, OCTETS > > > - 30 .debug_line 09025ee1 0000000000000000 0000000000000000 92e367cc > > > 2**0 > > > + 30 .debug_line 09025ede 0000000000000000 0000000000000000 92e367cc > > > 2**0 > > > CONTENTS, READONLY, DEBUGGING, OCTETS > > > - 31 .debug_str 1820ba50 0000000000000000 0000000000000000 9be5c6ad > > > 2**0 > > > + 31 .debug_str 1820ba50 0000000000000000 0000000000000000 9be5c6aa > > > 2**0 > > > CONTENTS, READONLY, DEBUGGING, OCTETS > > > - 32 .debug_line_str 0005d9f4 0000000000000000 0000000000000000 > > > b40680fd 2**0 > > > + 32 .debug_line_str 0005d9f4 0000000000000000 0000000000000000 > > > b40680fa 2**0 > > > CONTENTS, READONLY, DEBUGGING, OCTETS > > > - 33 .debug_loclists 13d74aa2 0000000000000000 0000000000000000 > > > b40c5af1 2**0 > > > + 33 .debug_loclists 13d74aa0 0000000000000000 0000000000000000 > > > b40c5aee 2**0 > > > CONTENTS, READONLY, DEBUGGING, OCTETS > > > - 34 .debug_rnglists 034c6c08 0000000000000000 0000000000000000 > > > c7e3a593 2**0 > > > + 34 .debug_rnglists 034c6bf6 0000000000000000 0000000000000000 > > > c7e3a58e 2**0 > > > CONTENTS, READONLY, DEBUGGING, OCTETS > > > - 35 .gnu_debuglink 00000024 0000000000000000 0000000000000000 > > > cb30119c 2**2 > > > + 35 .gnu_debuglink 00000024 0000000000000000 0000000000000000 > > > cb301184 2**2 > > > CONTENTS, READONLY > > > > > > I'm a bit puzzled since usually the debug symbols are moved off to the > > > -dbg package and yet they seem combined here with the library. What the > > > above seems to say is that the debug_line, loclists and rnglists > > > sections changed size, the rest changed offset (and we ignore > > > gnu_debuglink since that is a checksum which would depend on the other > > > bits). > > > > > > That would imply that some piece of code used to compile webkit has > > > different line numbering on one system compared to another but > > > generates identical code. You should be able to parse the debuginfo to > > > get a filename and linenumber out of it but I can't remember how, I > > > think I learnt to read dwarfish last time I did this :/. > > > > I did a dump of the debug sections with objdump -g and got absolutely > > huge output files that crashed all of the diff programs I tried. > > > > I guess the next step is to split those files into smaller chunks and > > diff those :-( > > > > Have I mentioned how much I hate webkit-gtk? > > Steve ran readelf against them and found there were some differences > with the _ZZN7WebCore11CSSProperty symbol. A grep on a build directory > shows: > > tmp/work/core2-64-poky-linux/webkitgtk/2.36.1-r0$ grep WebCore11CSSProperty > build webkitgtk-2.36.1 -R > grep: build/lib/libWebCoreGTK.a: binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2f84417a-14.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2f84417a-17.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-84c9f43f-5.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-26ec8d00-4.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2f84417a-7.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-950a39b6-5.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-a6b8b600-2.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-26ec8d00-2.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-8feba646-7.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-26ec8d00-5.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-043dd90b-14.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-950a39b6-14.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2f84417a-16.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2f84417a-10.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-950a39b6-7.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-2f84417a-1.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-26ec8d00-3.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-043dd90b-22.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unified-sources/UnifiedSource-f34946be-2.cpp.o: > binary file matches > grep: > build/Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/CSSPropertyNames.cpp.o: > binary file matches > grep: > build/Source/WebKit/CMakeFiles/WebKit.dir/__/__/DerivedSources/WebKit/unified-sources/UnifiedSource-50d0d8dd-6.cpp.o.d: > No such file or directory > > which fills me with dread since I worry it may be changing the output > depending on the order it is linking these in. Just a guess but...
And of course now I'm not able to get this to reproduce. I tried twice in the hopes of grabbing the source trees from A/B builds so I could compare them, but no joy. I'm beginning to suspect that this really isn't related to the gcc 11.3 version bump. Steve
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#166472): https://lists.openembedded.org/g/openembedded-core/message/166472 Mute This Topic: https://lists.openembedded.org/mt/91339755/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
