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)
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page
|