post b-i-b merge report

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

i386-unknown-freebsd4.7, FSF binutils 2.13 appears to bootstrap
post-merge fine (just completed).  For reference later, at an inner
most call to validate_switches() of an ./xgcc invocation run after
full bootstrap, I see this:

(gdb) x/20c start
0x8067f39:      84 'T'  42 '*'  125 '}' 32 ' '  125 '}' 125 '}' 125 '}' 125 '}'
0x8067f41:      125 '}' 125 '}' 0 '\0'  0 '\0'  0 '\0'  0 '\0'  0 '\0'  0 '\0'
0x8067f49:      0 '\0'  0 '\0'  0 '\0'  0 '\0'

While walking up the stack of validate_switches calls, it generated
pointers as high as 0x8067f4e (each pop of the call stack wants an
extra \0 to unwind properly)...

i386-unknown-freebsd5.0, FSF binutils 2.13.2 crashes upon first
invocation of newly built xgcc in stage 1.  It bootstrapped mainline
correctly with the same tools and exact same environment on 20021215.
At the inner most call to validate_switches(), I see this:

(gdb) x/20c start
0x806fec2:      84 'T'  42 '*'  125 '}' 32 ' '  125 '}' 125 '}' 125 '}' 125 '}'
0x806feca:      125 '}' 125 '}' 10 '\n' 10 '\n' 0 '\0'  -48 'Ð' -48 'Ð' -48 'Ð'
0x806fed2:      -48 'Ð' -48 'Ð' -48 'Ð' -48 'Ð'

Why is this difference important?  As I finish up the
validate_switches() calls, I see it walking off the end of this
in-core spec file.  The first time it doesn't find a \0, it walks
until the end of mapped memory (only because all values -48 until
unmapped page) at which point it sees a sig 11.

Aside, why do the in-core spec files look different in terms of
existence of \n?  Is that difference OK? (I'm getting a sense of deja vu.)

Anyways, I could probably do enough research to find a proper patch
but does anyone that made b-i-b changes see how this could have
happened and want to fix it?  Does anyone want to defend the way extra
\0 are required off the end of a spec fragment as we unwind up the
stack?  That usage seems quirky and quite non-robust to me.

Regards,
Loren