🚀 go-pugleaf

In article <20130209021846.GB14983@ece.cmu.edu>,
Chuck Cranor  <chuck@ece.cmu.edu> wrote:
>
>I've been updating one of our alphas here at CMU with 6.0.1
>(was running 5.1_STABLE from Feb 2011 before).
>
>The upgrade went fine, but when I started updating pkgsrc
>I noticed that my /bin/tcsh (from standalone-tcsh package)
>dumps the core.
>
>I dug into it a bit more and discovered that even csh dumps
>core if it is static linked:
>
>% uname -a
>NetBSD omega.pdl.cmu.local 6.0.1 NetBSD 6.0.1 (GENERIC-$Revision: 1.343
>$) #1: Tue Feb  5 13:43:34 EST 2013 
>chuck@omega.pdl.cmu.local:/home/netbsd/6/src/sys/arch/alpha/compile/OMEGA
>alpha
>% /bin/sh
>$ exit
>% /bin/csh -f
>% exit
>% exit
>% 
>% /rescue/sh
>$ exit
>% /rescue/csh
>Segmentation fault
>% 
>
>
>Now if I run /rescue/csh from my old 5.1_STABLE system it works:
>
>% 
>% /home/netbsd/5/alpha/destdir/rescue/csh -f
>% exit
>% exit
>% 
>
>so the problem was introduced sometime in the last 12 months.
>
>is anyone else seeing this with /rescue/csh on their alpha?
>what would cause something like this?
>

gdb stacktrace?

christos

On Fri, Feb 08, 2013 at 09:18:46PM -0500, Chuck Cranor wrote:
> is anyone else seeing this with /rescue/csh on their alpha?
> what would cause something like this?

I can reproduce it in -current, looking into it...

Martin

Disclaimer: I know ~nothing about alpha asm nor the ABI.

It looks like a bug in setjmp/longjmp to me, but it is subtle as it clobbers
the "gp" register, which seems to fall neither in the caller-saved nor the
callee-saved group, but required to be stable for local function calls.

Gcc source says:

/* Define this macro if the register defined by `PIC_OFFSET_TABLE_REGNUM'
   is clobbered by calls.  */
/* ??? It is and it isn't.  It's required to be valid for a given
   function when the function returns.  It isn't clobbered by
   current_file functions.  Moreover, we do not expose the ldgp
   until after reload, so we're probably safe.  */
/* #define PIC_OFFSET_TABLE_REG_CALL_CLOBBERED */


Now in our __setjmp14 implementation we do not store gp in the jump buffer.
Worse, in __longjmp14 we create a sigcontext from the jump buffer and
use partially unintialized stack memory for this, including the storage
area for uc.uc_mcontext.__gregs[_REG_GP].

Then we do a setcontext() and *BOOM* end up back here with an unaligned 
(and probably completely bogus) gp:

Program received signal SIGSEGV, Segmentation fault.
process (catch=<optimized out>) at csh.c:1004
1004            justpr = enterhist;     /* execute if not entering history */
(gdb) bt
#0  process (catch=<optimized out>) at csh.c:1004
#1  0x0000000120001f78 in srcunit (unit=<optimized out>, 
    onlyown=<optimized out>, hflg=<optimized out>) at csh.c:749
#2  0x0000000120002090 in srcfile (f=<optimized out>, onlyown=<optimized out>, 
    flag=<optimized out>) at csh.c:658
#3  0x0000000120003658 in main (argc=<optimized out>, argv=<optimized out>)
    at csh.c:525

Sounds like gcc will reload the gp register after non-local function calls
(whatever that exactly is) and so probably hide the effect in the shared
version.

Does this make sense? If yes, it is easy to fix (but I won't mind someone
with alpha knowledge to beat me to it).

Martin

On Sun, Feb 10, 2013 at 08:05:07PM +0100, Martin Husemann wrote:
> Does this make sense? If yes, it is easy to fix (but I won't mind someone
> with alpha knowledge to beat me to it).

Actually it is easy to fix in two different ways, depending on the ABI/
consensus:

 1) store gp in the jmp_buf in __setjmp14 and copy it to the sigcontext
    in __longjmp14

or:

 2) define the mentioned macro in the gcc spec, causing the compiler to
    generate reload code after setjmp() calls


Martin

In article <20130210190901.GC16496@mail.duskware.de>,
Martin Husemann  <martin@duskware.de> wrote:
>On Sun, Feb 10, 2013 at 08:05:07PM +0100, Martin Husemann wrote:
>> Does this make sense? If yes, it is easy to fix (but I won't mind someone
>> with alpha knowledge to beat me to it).
>
>Actually it is easy to fix in two different ways, depending on the ABI/
>consensus:
>
> 1) store gp in the jmp_buf in __setjmp14 and copy it to the sigcontext
>    in __longjmp14
>
>or:
>
> 2) define the mentioned macro in the gcc spec, causing the compiler to
>    generate reload code after setjmp() calls

It depends what the ABI requires. I would think that it would be best to
do 1, then the compiler could reload or not reload and it will still work...

christos

--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

On Mon, Feb 11, 2013 at 04:21:15AM +0000, Christos Zoulas wrote:
> It depends what the ABI requires. I would think that it would be best to
> do 1, then the compiler could reload or not reload and it will still work...

Yes, and attached patch does that (and seems to fix the problem for me).
However, I'd like to get comments from someone who actually knows the ABI
(or have a look at the ABI, anoyne got a pointer?) before commiting this.

The patch includes an unrelated change: memset the whole context to zero,
since we do not fully initialize it. Sounds saner to me and should be of
negligable cost, since we do a syscall later.

Martin

--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="alpha.patch"
Content-Transfer-Encoding: 8bit

Index: __longjmp14.c
===================================================================
RCS file: /cvsroot/src/lib/libc/arch/alpha/gen/__longjmp14.c,v
retrieving revision 1.5
diff -c -u -p -r1.5 __longjmp14.c
--- __longjmp14.c	28 Apr 2008 20:22:55 -0000	1.5
+++ __longjmp14.c	11 Feb 2013 10:14:14 -0000
@@ -56,6 +56,8 @@ __longjmp14(jmp_buf env, int val)
 	if (val == 0)
 		val = -1;
 
+	memset(&uc, 0, sizeof uc);
+
 	/* Set _UC_SIGMASK and _UC_CPU */
 	uc.uc_flags = _UC_SIGMASK | _UC_CPU;
 
@@ -74,6 +76,7 @@ __longjmp14(jmp_buf env, int val)
 	uc.uc_mcontext.__gregs[_REG_S5] = sc->sc_regs[R_S5];
 	uc.uc_mcontext.__gregs[_REG_S6] = sc->sc_regs[R_S6];
 	uc.uc_mcontext.__gregs[_REG_RA] = sc->sc_regs[R_RA];
+	uc.uc_mcontext.__gregs[_REG_GP] = sc->sc_regs[R_GP];
 	uc.uc_mcontext.__gregs[_REG_SP] = sc->sc_sp;
 	uc.uc_mcontext.__gregs[_REG_PC] = sc->sc_pc;
 	uc.uc_mcontext.__gregs[_REG_PS] =
Index: __setjmp14.S
===================================================================
RCS file: /cvsroot/src/lib/libc/arch/alpha/gen/__setjmp14.S,v
retrieving revision 1.5
diff -c -u -p -r1.5 __setjmp14.S
--- __setjmp14.S	12 Jun 2011 05:44:36 -0000	1.5
+++ __setjmp14.S	11 Feb 2013 10:14:14 -0000
@@ -55,6 +55,7 @@ LEAF(__setjmp14, 1)
 	stq	s6, (SC_REGS+_REG_S6)(a0)
 	stq	ra, (SC_REGS+_REG_RA)(a0)
 	stq	sp, (SC_REGS+_REG_SP)(a0)
+	stq	gp, (SC_REGS+_REG_GP)(a0)
 
 	/*
 	 * get signal information

--5mCyUwZo2JvN/JJP--

I am still looking for someone who has a copy of the alpha ELF ABI (or
remembers it well enough) to finally solve this issue.

Anyone?

Martin

On Fri, 8 Mar 2013, Martin Husemann wrote:

> I am still looking for someone who has a copy of the alpha ELF ABI (or
> remembers it well enough) to finally solve this issue.
>
> Anyone?

   Was there ever an ELF ABI for the Alpha?  I certainly don't remember 
ever seeing one (but there's lots of things I probably don't remember 
anymore).

Mike

---
Michael L. Hitch                        mhitch@montana.edu
Operations Consulting,  Information Technology Center
Montana State University, Bozeman, MT     USA

On Fri, Mar 08, 2013 at 01:54:08PM -0700, Michael L. Hitch wrote:
>   Was there ever an ELF ABI for the Alpha?  I certainly don't remember 
> ever seeing one (but there's lots of things I probably don't remember 
> anymore).

Hmm, that would explain why it seems so hard to find.
So, just go with Christos' suggestion and save/restore the register,
even if it might be papering over a compiler bug?

Martin

On Mar 8, 2013, at 12:59 PM, Martin Husemann <martin@duskware.de> wrote:

"What does Linux do?"

> On Fri, Mar 08, 2013 at 01:54:08PM -0700, Michael L. Hitch wrote:
>> Was there ever an ELF ABI for the Alpha?  I certainly don't remember 
>> ever seeing one (but there's lots of things I probably don't remember 
>> anymore).
> 
> Hmm, that would explain why it seems so hard to find.
> So, just go with Christos' suggestion and save/restore the register,
> even if it might be papering over a compiler bug?
> 
> Martin


-- thorpej

On Fri, Mar 08, 2013 at 02:27:40PM -0800, Jason Thorpe wrote:
> 
> On Mar 8, 2013, at 12:59 PM, Martin Husemann <martin@duskware.de> wrote:
> 
> "What does Linux do?"

I am not sure for general linux. Do they support static linking?

I looked at the uLibc source and it does not store/restore register 29
(aka $gp). All documents describing the register set I found claim
it would not be preserved accross function calls - which is kind of
natural for its intended usage.

Still sounds like a gcc bug to me.

Martin