/tools References in Binaries [Was Re: new makefile.]
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.
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