Re: [libunwind] libunwind segv with gcc 2.96 programs run on Redhat EL 3 with GLIBC 2.3.2

[Jim Wilson]

On Wed, 2004-02-04 at 08:28, Harrow, Jerry wrote:
> My project has been using libunwind to trace the stack at event points
> within a process.  When testing with the new Redhat EL V3 on Itanium
> (glibc 2.3.2)  we started to see a segv from libunwind when attempting
> to unwind through main().

I don't have access to RH AS or RH EL, so I can't check.  However, I
would guess that this is a glibc issue.

The call chain is supposed to be terminated with a 0 address.  This
requires an instruction to load 0 into rp during the _start function,
and an unwind descriptor to indicate that the 0 is there.  David
Mosberger first added this stuff to glibc on 2001-04-09, and then
revised it 2003-03-27.  I believe you need to have a glibc from after
2003-03-27 for this to work reliably.  If you have a glibc in between
those two dates, then it will probably work sometimes.  If you have a
glibc from before 2001-04-09, then it probably won't work at all.  I
don't know what glibc versions and patches are in the RH OS versions
that you have.

See in particular the glibc sysdeps/ia64/elf/start.S file.  There are
also equivalent changes to the dynamic linker.

There could perhaps be an issue with threads if a thread doesn't have
its call chain properly terminated.  I don't know enough the thread
support to know if this is an issue.  I don't know if I have the tls
thread support on my debian system.  I suspect I don't.

Your testcase works fine on my debian system, which has an up-to-date
copy of glibc.  readelf -u gives me
<_start>: [0x40000000000007a0-0x4000000000000830], info at +0xf10
  v1, flags=0x0 (), len=8 bytes
    R1:prologue(rlen=0)
        P7:rp_when(t=0)
        P3:rp_gr(reg=r0)
which makes it clear that the call chain is terminated with a 0 rp value
even before the first instruction.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com