/tools References in Binaries [Was Re: new makefile.]

George Boudreau georgeb at linuxfromscratch.org
Wed Aug 30 18:27:44 PDT 2006


Greg Schafer wrote:
> Dan Nicholson wrote:
> 
>> So, there's a reference to the internal gcc include dir from /tools in
>> the debugging information. IIRC, that happens with the way the
>> toolchain get's built. It may be because the LFS toolchain adjustment
>> doesn't do anything to the include dir path. I'm not sure. I CC'd
>> Greg. Maybe he remembers more. Unfortunately, all my binaries seem to
>> be stripped, so I can't see what's in their debugging sections.
>>
>> Greg, is this normal for the debugging info on the first pass, or is
>> this a bug in LFS/JHALFS?
> 
> I'm not certain but I'd guess it's not a bug in LFS/JHALFS. You're
> right that the GCC used to compile module-init-tools shouldn't know
> anything about /tools. However..
> 
> I just tried to reproduce it here and indeed, some weird stuff does appear
> in that .debug_line ELF section. I see references to
> glibc-build/csu..crti.S which suggests that some debugging cruft is
> retained in the Glibc startfiles that get linked into every executable.
> Remember that Glibc is compiled by the GCC in /tools. I'd say this
> explains it.
> 
> IMHO it just confirms what we already know ie: debugging cruft should be
> stripped out before performing ICA style byte-for-byte diffs.
> 
> Regards
> Greg
Thanks for the detective work Greg. By the end of the yesterday evening 
I was sure this was the norm, I looked in another source distro and 
found other examples. (rule-1:Investigate first.. ask questions later)



More information about the alfs-discuss mailing list