Re: debug files now have program headers
- In reply to: Ed Maste : "Re: debug files now have program headers"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 07 Apr 2026 20:37:06 UTC
On 2026-04-07 18:12, Ed Maste wrote: > Yes, it should be LLVM_BINUTILS_BOOTSTRAP that's responsible, not > LLVM_BINUTILS. The former is only in main while LLVM_BINUTILS is also > in stable/15. The changes to support LLVM_BINUTILS BOOTSTRAP were > missing from the original LLVM_BINUTILS work; it was not intentional > that we continued to use ELF Tool Chain tools for the bootstrap. > > We discovered this because another tool (i.e., libabigail) failed when > the standalone debug files _lacked_ program headers, and I believe > this is the expected state in the GNU tool / Linux distro world. I > presume Valgrind on Linux handles this somehow? Hi Ed I suspect that this is the first time that that this has been observed. That means that Valgrind on Linux probably has the same problem. This issue will need fixing. Very briefly, the issue is caused in the code that runs only with -v -v or more that will print something like ==61545== Adding active redirection: --61545-- new: 0x7ff80cb94c65 (operator new(unsigne) R-> (1003.0) 0x100181f50 operator new(unsigned long, std::align_val_t) at that point in the code it only has the function addresses, so it calls some functions to look up the names. That is quite involved. On the way it will call is_elf_object_file_by_DiImage [Di = Debuginfo]. That just looks at the ELF header. Previously it returned false as there was no program header in the split debug files. Now it is returning true. I think that the fix will be to add a further check for a non-zero sized PT_DYNAMIC segment. is_elf_object_file_by_DiImage is used in several places so I have to make sure that there are no bad side effects. Regards Paul