Re: alpha and gcc4; have foot, will shoot

2011-11-18 Thread Christian Weisgerber
Christian Weisgerber na...@mips.inka.de wrote:

 I split _dl_md_reloc_got() out into a separate file and compared
 the generated assembly language.  There are no differences.  I also
 disassembled the object files, no code differences.
 
 I wonder if ld(1) could be to blame.

... but linking the gcc4 object files on a gcc3 machine doesn't help
either.  I am out of ideas.

-- 
Christian naddy Weisgerber  na...@mips.inka.de



Re: alpha and gcc4; have foot, will shoot

2011-11-18 Thread Christian Weisgerber
Christian Weisgerber na...@mips.inka.de wrote:

 I am out of ideas.

Miod suggested I try this, and it produces a working ld.so.

Index: alpha/Makefile.inc
===
RCS file: /cvs/src/libexec/ld.so/alpha/Makefile.inc,v
retrieving revision 1.2
diff -u -r1.2 Makefile.inc
--- alpha/Makefile.inc  26 Sep 2006 23:14:52 -  1.2
+++ alpha/Makefile.inc  18 Nov 2011 10:28:37 -
@@ -1,5 +1,5 @@
 #  $OpenBSD: Makefile.inc,v 1.2 2006/09/26 23:14:52 martin Exp $
 
-CFLAGS += -fPIC -mno-fp-regs
+CFLAGS += -fPIC -mno-fp-regs -mbuild-constants
 LIBCSRCDIR=${.CURDIR}/../../lib/libc
 .include ${LIBCSRCDIR}/arch/alpha/Makefile.inc
-- 
Christian naddy Weisgerber  na...@mips.inka.de



Re: alpha and gcc4; have foot, will shoot

2011-11-17 Thread Christian Weisgerber
Janjaap van Velthooven janj...@stack.nl wrote:

 For some obscure reason this gave successes. After splitting up
 alpha/rtld_machine.c into 2 or mor parts, any combination where the
 1st and the 3rd function (_dl_md_reloc and _dl_md_reloc_got) were
 not in the same source allowed the split-up sources to be compiled
 without breaking ld.so. Looking with my untrained eye at the generated
 assembly or the dissasembled objects did not give me any clue as
 to why this was happening.

I split _dl_md_reloc_got() out into a separate file and compared
the generated assembly language.  There are no differences.  I also
disassembled the object files, no code differences.

I wonder if ld(1) could be to blame.

-- 
Christian naddy Weisgerber  na...@mips.inka.de



Re: alpha and gcc4; have foot, will shoot

2011-11-17 Thread Janjaap van Velthooven
Christian Weisgerber wrote and mailed:
 Janjaap van Velthooven janj...@stack.nl wrote:
 
  For some obscure reason this gave successes. After splitting up
  alpha/rtld_machine.c into 2 or mor parts, any combination where the
  1st and the 3rd function (_dl_md_reloc and _dl_md_reloc_got) were
  not in the same source allowed the split-up sources to be compiled
  without breaking ld.so. Looking with my untrained eye at the generated
  assembly or the dissasembled objects did not give me any clue as
  to why this was happening.

 I split _dl_md_reloc_got() out into a separate file and compared
 the generated assembly language.  There are no differences.  I also
 disassembled the object files, no code differences.

I did similar and saw no noticable differences either,
other than the address the function was on that is..

 I wonder if ld(1) could be to blame.

If so, why would it do that? It should behave the same as when compiled 
with gcc3 (theoretically at least)..

I can think of some theories:
  - does compiling ld with gcc4 introduce/expose a bug in ld?
(I used a gcc4 compiled ld back then)
  - does the gcc4 compiled rtld_machine.c cause an other codepath than
the gcc3 compiled version in ld on which there has always been a bug?

Janjaap van Velthooven
--  
   / __/ /_/ __/ /_  __/ __/ /___  / 
  / /_  __/___/_/_  /___  / / __/ /___  / /  janj...@stack.nl
 /___/_/_/_/_/_/_/___/_/_/



alpha and gcc4; have foot, will shoot

2011-10-03 Thread Janjaap van Velthooven
Hi,

Last may, after getting a gcc3 internal compiler error bugreport
handed back to me, I decided to see how big a hole I could shoot
in my foot by trying to switch to gcc4.

At that time unaware of Marco Peereboom's gcc4 timing page stating
the issues with alpha and gcc4, I independanly came to the similar
conclusions:
Yes, the kernel needed a tweak and it was trivial.
And furthermore, yes, after userland built fine and it was completely
borked due to ld.so putting multiple clogs into the cogs.

Not to be deterred I started to kick ld.so around for a bit.
compile with -O1: still no go.
compile with -O0: working ld.so.

Big cheer, I now had an fully ggc4 compiled base. 

Further kicking at the ld.so sources determined that only the files
alpha/rtld_machine.c and dl_prebind.c needed to be compiled with
-O0. The rest could be compiled with the default -O2 and still
result in a working ld.so.

Finally after cursing the lack of information I could retrieve from
either running something from gdb (there did not deem to be any
process yet to debug and placing breakpoints on the entrypoints of
ld.s also did not seem to give any action) or by ktracing (which
did nothing between returning from exec and generating a segv) a
simple binary with a broken ld.so (in a chrooted environment) did
not give me any more insight into what might have been happening,
but after reading the kernel sources for some intuitive reason still
completely beyond any logic I can reproduce I decided to split up
the problematic source files.

For some obscure reason this gave successes. After splitting up
alpha/rtld_machine.c into 2 or mor parts, any combination where the
1st and the 3rd function (_dl_md_reloc and _dl_md_reloc_got) were
not in the same source allowed the split-up sources to be compiled
without breaking ld.so. Looking with my untrained eye at the generated
assembly or the dissasembled objects did not give me any clue as
to why this was happening.

Recently I found a new spot of available time and tried the same
trick with the other problematic file (dl_prebind.c). Here a split
where the second and the third function (prebind_load_exe and
prebind_load_fd) needed to be in separate source/object files resulted
in a -O2 compilable situation. The rest of the functions could be
put with either one of them or even in one or more separate functions
without any influnence on the result.

Therfore my question is: Does anyone have an idea about what is
happening or at least how I can find out what the issue is?

As a last issue, after getting ld.so running I found an onther issue
with gcc4 built userland: anything using libkvm gets a unaligned
access in the code to avoid alignment issues (around kvm.c line
780). compiling with -fno-builtin removed this issue but I have not
yet looked more closely at it.

With these workarounds in place I have been running fine on several 
generations of current between then and now.

Ob-dmesg for those interested:

[ using 630552 bytes of bsd ELF symbol table ]
consinit: not using prom console
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2011 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.0-current (GENERIC) #0: Tue Sep 27 21:37:28 CEST 2011
janjaap@alf:/forest/trees/src/sys/arch/alpha/compile/GENERIC
Digital AlphaPC 164SX 533 MHz
8192 byte page size, 1 processor.
real mem = 536870912 (512MB)
rsvd mem = 1966080 (1MB)
avail mem = 517832704 (493MB)
mainbus0 at root
cpu0 at mainbus0: ID 0 (primary), PCA56-2 (unknown minor type 2)
cpu0: architecture extensions: 1BWX
cia0 at mainbus0: DECchip 2117x Core Logic Chipset (Pyxis), pass 1
cia0: extended capabilities: 1BWEN
cia0: using BWX for PCI config and bus access
pci0 at cia0 bus 0
vga0 at pci0 dev 6 function 0 Matrox MGA G200 PCI rev 0x01
wsdisplay0 at vga0 mux 1
wsdisplay0: screen 0-5 added (80x25, vt100 emulation)
em0 at pci0 dev 7 function 0 Intel PRO/1000MT (82541GI) rev 0x00: eb164 irq 
10, address 00:0e:0c:51:3d:a0
sio0 at pci0 dev 8 function 0 Contaq Microsystems CY82C693U ISA rev 0x00
pciide0 at pci0 dev 8 function 1 Contaq Microsystems CY82C693U ISA rev 0x00: 
DMA, channel 0 wired to compatibility
pciide0: channel 0 disabled (no drives)
pciide1 at pci0 dev 8 function 2 Contaq Microsystems CY82C693U ISA rev 0x00: 
no DMA, channel 0 wired to compatibility
wd0 at pciide1 channel 0 drive 0: Maxtor 6Y160P0
wd0: 16-sector PIO, LBA48, 156334MB, 320173056 sectors
wd1 at pciide1 channel 0 drive 1: WDC WD800JB-00JJA0
wd1: 16-sector PIO, LBA, 76319MB, 156301488 sectors
wd0(pciide1:0:0): using PIO mode 4
wd1(pciide1:0:1): using PIO mode 4
ohci0 at pci0 dev 8 function 3 Contaq Microsystems CY82C693U ISA rev 0x00: 
couldn't map interrupt
uhci0 at pci0 dev 9 function 0 VIA VT83C572 USB rev 0x61: eb164 irq 8
uhci1 at pci0 dev 9 function 1 VIA VT83C572 USB rev 0x61: eb164 irq 12
ehci0 at pci0 dev 9 function 2 VIA VT6202 USB rev 0x63: eb164 irq 16