[opensuse-packaging] debuginfo
Hi, some years ago I understood some of the stuff but apparently forgot almost everything again. I'm hunting an issue that the Firefox debugsymbols (the google-breakpad ones) which are created in the build step do not match the binaries ending up in the package. This means that crashreports sent to Mozilla cannot be decoded and are useless. Nothing changed in the packages and the way all that is handled and it worked in the past (I cannot exactly tell when it stopped working). For verifying which step of the build could be culprit I've disabled the debuginfo flag in OBS and rebuilt the package. Afterwards the breakpad symbols did match again. I've also verified that stripping the binaries via command strip does not change the ID and therefore stripping itself is not hurting the procedure. Therefore I'm pretty sure something in RPMs find-debuginfo.sh is doing something which changes the breakpad ID. I cannot tell what it is but it wasn't an issue in the past. So the following question: - what does find-debuginfo.sh do which changes the breakpad ID And as a sidequestion out of curiousity: - what is expected when the debuginfo flag is removed from OBS? Do binaries still contain debugsymbols? (apparently no) Do shared libs still contain debugsymbols? (apparently yes) Is that expected? I need to find a solution since the breakpad symbols are actually more useful for me since users don't have to do anything special (using gdb) to report crashes. But the "distro" way is to have the debuginfo packages usable with gdb. If both cannot be achieved at the same time, I'm not sure what to do. Thanks, Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Wolfgang Rosenauer <wolfgang@rosenauer.org> writes:
So the following question: - what does find-debuginfo.sh do which changes the breakpad ID
How is the breakpad ID computed? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Am 03.02.2014 13:02, schrieb Andreas Schwab:
Wolfgang Rosenauer <wolfgang@rosenauer.org> writes:
So the following question: - what does find-debuginfo.sh do which changes the breakpad ID
How is the breakpad ID computed?
hmm, for details I would need to point you to the google-breakpad project and source code but a quick and overall explanation I got is: "the debug id is either the build ID from the ELF headers, or a hash of the first page of .text" Just found the relevant code: // Attempt to locate a .note.gnu.build-id section in an ELF binary // and copy as many bytes of it as will fit into |identifier|. static bool FindElfBuildIDNote(const void *elf_mapped_base, uint8_t identifier[kMDGUIDSize]) { void* note_section; int note_size, elfclass; if ((!FindElfSegment(elf_mapped_base, PT_NOTE, (const void**)¬e_section, ¬e_size, &elfclass) || note_size == 0) && (!FindElfSection(elf_mapped_base, ".note.gnu.build-id", SHT_NOTE, (const void**)¬e_section, ¬e_size, &elfclass) || note_size == 0)) { return false; } if (elfclass == ELFCLASS32) { return ElfClassBuildIDNoteIdentifier<ElfClass32>(note_section, note_size, identifier); } else if (elfclass == ELFCLASS64) { return ElfClassBuildIDNoteIdentifier<ElfClass64>(note_section, note_size, identifier); } return false; } // Attempt to locate the .text section of an ELF binary and generate // a simple hash by XORing the first page worth of bytes into |identifier|. static bool HashElfTextSection(const void *elf_mapped_base, uint8_t identifier[kMDGUIDSize]) { void* text_section; int text_size; if (!FindElfSection(elf_mapped_base, ".text", SHT_PROGBITS, (const void**)&text_section, &text_size, NULL) || text_size == 0) { return false; } my_memset(identifier, 0, kMDGUIDSize); const uint8_t* ptr = reinterpret_cast<const uint8_t*>(text_section); const uint8_t* ptr_end = ptr + std::min(text_size, 4096); while (ptr < ptr_end) { for (unsigned i = 0; i < kMDGUIDSize; i++) identifier[i] ^= ptr[i]; ptr += kMDGUIDSize; } return true; } // static bool FileID::ElfFileIdentifierFromMappedFile(const void* base, uint8_t identifier[kMDGUIDSize]) { // Look for a build id note first. if (FindElfBuildIDNote(base, identifier)) return true; // Fall back on hashing the first page of the text section. return HashElfTextSection(base, identifier); } -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Wolfgang Rosenauer <wolfgang@rosenauer.org> writes:
"the debug id is either the build ID from the ELF headers, or a hash of the first page of .text"
That's probably the reason: the build-id note is only added during the find-debuginfo.sh run. You probably need a way to (re)compute the breakpad ID after that. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (2)
-
Andreas Schwab -
Wolfgang Rosenauer