Hi Paul, On Wed, 2020-10-28 at 00:40 -0400, Paul Smith wrote: > On Tue, 2020-10-27 at 23:23 +0100, Mark Wielaard wrote: > > Do you have the generated core files somehwere so others can look > > at > > them? How exactly are you testing the build-id notes are there? > > I don't have one to publish but I can create one. That's a good idea > anyway as it will be simpler to debug than the actual system which is > much more complex. > > I'm using eu-unstrip -n --core core.xxx to check for build IDs.
OK, so say you have a core file (this one produced by the kernel crashing a local sleep process). Then eu-unstrip -n --core would show: 0x400000+0x208000 ec28c24670b6b52fb99b43338e47fe2d4b6fb4ea@0x400284 - - /usr/bin/sleep 0x7ff037345000+0x3cd000 dd9a6ba0d81c91f5ca7dbb4a1ac58319cc26dd5a@0x7ff037345280 - - /usr/lib64/libc-2.17.so 0x7ff037712000+0x224000 a527fe72908703c5972ae384e78d1850d1881ee7@0x7ff0377121d8 - - /usr/lib64/ld-2.17.so 0x7ffed73bf000+0x1000 63023e5151c4d5bbdb7f6f85a6f95a6b95dc780e@0x7ffed73bf328 . - linux-vdso.so.1 What this means is that it found the build-id for libc-2.17.so at address 0x7ff037345280 in the segment spanning 0x7ff037345000+0x3cd000. So that address is very near the beginning of that segment. eu-readelf -l on the core file will show a segment that corresponds to that: LOAD 0x025000 0x00007ff037345000 0x0000000000000000 0x001000 0x1c2000 R E 0x1000 Note that the filesize is just the first page (0x001000) even though the file itself is much bigger (as shown by the memsize of 0x1c2000) You'll have to make sure your coredumper program produces a similar segment in the core file covering the same area of libc.so to get the build-id in there. Hope that helps, Mark
