I will have some time to look into this later this week. It looks like
this is just libunwind expecting something to be present that isn't, but
I am not sure what the best way to fix it would be.

Thanks!
Todd


On Tue, Jul 13, 2021 at 04:50:54PM +0000, Charlene Wendling wrote:
> Hi,
> 
> The editors/emacs packages cannot be built on macppc with libexecinfo
> because the resulting executables segfault. I've committed a workaround
> for the port, but cannot fix the underlying issue.
> 
> It can be reproduced with:
> 
> - OpenBSD 6.9-current (GENERIC) #899: Thu Jun 24 21:33:19
> - OpenBSD 6.9-current (GENERIC) #901: Mon Jun 28 18:22:52
> - OpenBSD 6.9-current (GENERIC) #907: Sun Jul 11 18:25:13 (latest)
> 
> I'm forwarding you the most interesting bits from the ports@ thread and a
> backtrace. Backtraces from the regress test and emacs are similar.
> 
> I've tested a number of ports with #899 that used to depend on ports
> libexecinfo, with no issues.
> 
> Charlène.
> 
> 
> Begin forwarded message:
> 
> Date: Tue, 13 Jul 2021 13:00:51 +0000
> From: Charlene Wendling <[email protected]>
> To: Jeremie Courreges-Anglas <[email protected]>
> Cc: [email protected]
> Subject: Re: [macppc, base libexecinfo] Unbreak editors/emacs
> 
> 
> On Tue, 13 Jul 2021 13:54:05 +0200
> Jeremie Courreges-Anglas <[email protected]> wrote:
> 
> > On Tue, Jul 13 2021, Charlene Wendling <[email protected]> wrote:
> > > On Tue, 13 Jul 2021 01:51:28 +0200
> > > Jeremie Courreges-Anglas <[email protected]> wrote:
> > >
> > >> On Mon, Jul 12 2021, Charlene Wendling <[email protected]>
> > >> wrote:
> > >> > Hi,
> > >> >
> > >> > This is the first bulk with base libexecinfo.
> > >> >
> > >> >> https://bin.charlenew.xyz/emacs_bulk_failure.log
> > >> >
> > >> > The last port commit brought libexecinfo support to emacs, and
> > >> > leads to segfault during the build on macppc. I attach the
> > >> > backtrace of a simple 'temacs' invocation, showing that it may
> > >> > not be emacs' fault.
> > >> >
> > >
> > >> I'm slightly worried regarding libunwind status on powerpc.  What
> > >> does regress/gnu/lib/libexecinfo say?
> > >
> > > This cannot be run on macppc:
> > >
> > > -->8--
> > > ==== run-regress-skiparch ====
> > > # No unwind info on this arch
> > > SKIPPED
> > > --8<--
> > >
> > > It's limited to amd64 or llvm>=12, as mentioned in the regress'
> > > Makefile cvs log.
> >
> > Well could you please test with the diff below applied?
> > 
> > Index: Makefile
> > ===================================================================
> > RCS file: /d/cvs/src/regress/gnu/lib/libexecinfo/Makefile,v
> > retrieving revision 1.2
> > diff -u -p -r1.2 Makefile
> > --- Makefile        18 Jun 2021 14:09:31 -0000      1.2
> > +++ Makefile        13 Jul 2021 11:49:56 -0000
> > @@ -6,7 +6,7 @@
> >  
> >  # Only amd64 has unwind info by default in llvm11. llvm12 adds more arches.
> >  CLANG_VERSION!=clang --version | head -1 | grep -E -o 'version 
> > [[:digit:]]+' | cut -d' ' -f 2
> > -CLANG_GE_12!=if [ ${CLANG_VERSION} -ge 12 ] ; then echo 1 ; fi
> > +CLANG_GE_12!=if [ ${CLANG_VERSION} -ge 11 ] ; then echo 1 ; fi
> >  .if ${MACHINE} == "amd64" || ${CLANG_GE_12} == "1"
> >  
> >  PROG=      t_backtrace
> > 
> > -- 
> > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> > 
> 
> Here you are. I did the same thing this morning but i wasn't very
> sure if it was valid.
> 
> If i pass DEBUG="-O0 -g" to the Makefile, it does not segfault by the
> way. 
> 
> (gdb) run                                                                     
>                                    
> Starting program: /usr/src/regress/gnu/lib/libexecinfo/t_backtrace -r 1       
>                                    
>                                                                               
>                                    
> Program received signal SIGSEGV, Segmentation fault.                          
>                                    
> libunwind::CFI_Parser<libunwind::LocalAddressSpace>::findFDE 
> (addressSpace=..., pc=3122944028,                   
>     ehSectionStart=3123060828, sectionLength=<optimized out>, 
> fdeHint=<optimized out>, fdeInfo=0xfffcbce8,       
>     cieInfo=0xfffcbcc8) at 
> /usr/src/gnu/llvm/libunwind/src/DwarfParser.hpp:223                           
>         
> 223         pint_t cfiLength = addressSpace.get32(p);                         
>                                    
> (gdb) bt                                                                      
>                                    
> #0  libunwind::CFI_Parser<libunwind::LocalAddressSpace>::findFDE 
> (addressSpace=..., pc=3122944028,               
>     ehSectionStart=3123060828, sectionLength=<optimized out>, 
> fdeHint=<optimized out>, fdeInfo=0xfffcbce8, 
>     cieInfo=0xfffcbcc8) at /usr/src/gnu/llvm/libunwind/src/DwarfParser.hpp:223
> #1  0xba24cfd0 in libunwind::UnwindCursor<libunwind::LocalAddressSpace, 
> libunwind::Registers_ppc>::getInfoFromDwarfSection (this=0xfffcc920, 
> pc=3122944028, sects=..., fdeSectionOffsetHint=0)
>     at /usr/src/gnu/llvm/libunwind/src/UnwindCursor.hpp:1518
> #2  0xba249ce4 in libunwind::UnwindCursor<libunwind::LocalAddressSpace, 
> libunwind::Registers_ppc>::setInfoBasedOnIPRegister (this=0xfffcc920, 
> isReturnAddress=<optimized out>)
>     at /usr/src/gnu/llvm/libunwind/src/UnwindCursor.hpp:1927
> #3  0xba2480a8 in __unw_init_local (cursor=0xfffcc920, context=0xfffcc578)
>     at /usr/src/gnu/llvm/libunwind/src/libunwind.cpp:76
> #4  0xba24582c in _Unwind_Backtrace (callback=0xba24ec54 <tracer>, 
> ref=0xfffccd28)
>     at /usr/src/gnu/llvm/libunwind/src/UnwindLevel1-gcc-ext.c:112
> #5  0xba24ebd4 in backtrace (arr=<optimized out>, len=<optimized out>)
>     at /usr/src/gnu/lib/libexecinfo/unwind.c:69
> #6  0x2d1e070c in myfunc3 () 
> 

Reply via email to