Weird compile problems
A message that is not in the archive (sent off-list or not yet received): [email protected]
On Tue, 30 Jan 2001, Paul J.Y. Lahaie wrote:
[about pehc CVS devel branch gcc]
Quoted 2 lines
And fixincl (the progrma that does the subst) is taking 0% CPU (from top)
10727 pjlahaie 9 0 712 712 520 S 20 0.0 0.5 0:00 fixincl
Yeah, fixincl dies for me too. I'd been putting it down to some sort of kernel problem, and just disabled fixinc (gcc/Makefile:STMP_FIXINC). Other than that, I get a successful bootstrap, and both kernel & glibc compile natively - except that `make' died randomly in the glibc build, and I currently have a ld.so.1 that segfaults.
Hmm, looking at what I just wrote, you can hardly call it a "successful bootstrap". I'm investigating the ld.so.1 problem - at least that one is reproducable.
Alan
Signature · 1 line
Linuxcare. Support for the Revolution.
Alan Modra writes...
Quoted 11 lines · Paul J.Y. Lahaie
[about pehc CVS devel branch gcc]
Quoted 2 lines
And fixincl (the progrma that does the subst) is taking 0% CPU (from top)
10727 pjlahaie 9 0 712 712 520 S 20 0.0 0.5 0:00 fixinclYeah, fixincl dies for me too. I'd been putting it down to some sort of kernel problem, and just disabled fixinc (gcc/Makefile:STMP_FIXINC). Other than that, I get a successful bootstrap, and both kernel & glibc compile natively - except that `make' died randomly in the glibc build, and I currently have a ld.so.1 that segfaults.
I suspect that your make actually died during the make install right? This is the problem that John Marvin and I are working on. The pthread changes that he made broke things that use librt and libpthread. In our current nfsroot that is tar, make, and sleep. For now we're using a static make to complete the install. Once I have a new glibc package built I will do new new make,tar,sleep stuff too.
Quoted 3 lines
Hmm, looking at what I just wrote, you can hardly call it a "successful bootstrap". I'm investigating the ld.so.1 problem - at least that one is reproducable.
I was seeing that here too but John wasn't. We're currently trying to determine the differences in our build environments. What system are you building on and what nfsroot/kernel are you using?
Thanks,
Signature · 2 lines
Matt Taggart Linux Development Lab [email protected] HP Linux Systems Operation
Quoted 1 line · Matt Taggart
I suspect that your make actually died during the make install right? This is
No, during the build.
Quoted 6 lines
the problem that John Marvin and I are working on. The pthread changes that he made broke things that use librt and libpthread. In our current nfsroot that is tar, make, and sleep. For now we're using a static make to complete the install. Once I have a new glibc package built I will do new new make,tar,sleep stuff too.
Quoted 7 lines
Quoted 3 lines
Hmm, looking at what I just wrote, you can hardly call it a "successful bootstrap". I'm investigating the ld.so.1 problem - at least that one is reproducable.
I was seeing that here too but John wasn't. We're currently trying to determine the differences in our build environments. What system are you building on and what nfsroot/kernel are you using?
Machine is a 712/80, nfsroot started life as nfsroot-20001009 but has been tweaked quit a bit - compiler, binutils, glibc. Kernel is one I built from CVS checked out 24th. Jan.
Alan
Signature · 1 line
Linuxcare. Support for the Revolution.
Quoted 1 line · Alan Modra
and I currently have a ld.so.1 that segfaults.
r19 is being trashed. It's a compiler bug. One I added too. :-(
At least, it's to do with the new scheme of allowing gcc to allocate a register to save r19 rather than trying to use a fixed register. From a quick glance over disassembled code, it seems that inline functions try to restore r19 from a register that has never been initialised.
Alan
Signature · 1 line
Linuxcare. Support for the Revolution.
On Wed, 31 Jan 2001, Alan Modra wrote:
[about pehc devel branch gcc]
Quoted 1 line
r19 is being trashed. It's a compiler bug. One I added too. :-(
Now fixed.
Signature · 1 line
Linuxcare. Support for the Revolution.
Quoted 6 lines · Alan Modra
On Wed, 31 Jan 2001, Alan Modra wrote:
[about pehc devel branch gcc]
Quoted 1 line
r19 is being trashed. It's a compiler bug. One I added too. :-(
Now fixed.
It anyone has tried to compile glibc with the devel branch compiler, you've probably discovered by now that ld.so is still crashing, but for a different reason. The global register allocation pass does the following naughty thing:
[from elf/dl-load.c]
(insn 612 608 1626 (set (reg:SI 1 %r1)
(plus:SI (reg:SI 19 %r19)
(high:SI (symbol_ref/v/f:SI ("*.LC27"))))) 80 {*pa.md:2326}
(nil)
(nil))(insn 1626 612 621 (set (reg:SI 23 %r23 [242])
(reg:SI 1 %r1)) 69 {*pa.md:2099} (nil)
(nil))[snip around 1480 lines, including calls]
(insn 1638 1527 988 (set (reg:SI 21 %r21)
(mem/u:SI (lo_sum:SI (reg:SI 23 %r23 [242])
(unspec:SI[
(symbol_ref/v/f:SI ("*.LC27"))
] 0)) 0)) 82 {*pa.md:2352} (nil)
(nil))With the problem being that r23 is not a callee saved register, so it's well and truly trashed by the time insn 1638 tries to use it.
Signature · 1 line
Linuxcare. Support for the Revolution.