Would it be a good time to perhaps either do a full rebuild of everything into a unified repository? Or at least merge the old build repository with the main public repository? I can't be the first one to run into this, even if I am the first one to mention it here. On Thu, Aug 8, 2019 at 10:03 PM Pablo Sebastián Greco < pablo at fliagreco.com.ar> wrote: > Yeap, another one that wasn't migrated from the old buildsystem, > > https://armv7.dev.centos.org/repodir/c71708-pass-1/mesa-private-llvm/3.9.1-3.el7/armv7hl/ > > Pablo. > El 8/8/19 a las 17:19, Gordan Bobic escribió: > > Another debuginfo package missing: > mesa-private-llvm-3.9.1-3.el7.armv7hl > > > On Thu, Aug 8, 2019 at 5:50 PM Pablo Sebastián Greco < > pablo at fliagreco.com.ar> wrote: > >> Gordan, sorry for the absence, I've been swamped with C8, and now with >> C7.7, not to mention $dayjob. >> I have no theories at the moment, and if I'd love to help once both >> versions are out. >> >> Pablo. >> El 8/8/19 a las 13:39, Gordan Bobic escribió: >> >> Pablo, I don't suppose you (or anyone else here) has had any ideas on how >> to get any further in debugging this? >> >> On Wed, Jul 31, 2019 at 10:21 PM Gordan Bobic <gordan at redsleeve.org> >> wrote: >> >>> Hmm, after a lot of debuginfo chasing, rebuilding packages where I >>> couldn't find them, different gdbs I have hit a dead end again. >>> No missing debuginfos reported, SIGILL still happens, but backtrace says >>> it can't read memory at address 0x2c. >>> In step through mode, the last it comes up with is: >>> >>> 796 reshape(winWidth, winHeight); >>> 798 event_loop(dpy, win); >>> >>> and then it SIGILLs... >>> >>> I never thought it would be so difficult to find out what library >>> function is executing when SIGILL gets emitted. :-( >>> >>> >>> >>> On Wed, Jul 24, 2019 at 11:42 AM Pablo Sebastián Greco < >>> pablo at fliagreco.com.ar> wrote: >>> >>>> >>>> El 23/7/19 a las 17:41, Gordan Bobic escribió: >>>> >>>> On Tue, 23 Jul 2019, 21:35 Pablo Sebastián Greco, < >>>> pablo at fliagreco.com.ar> wrote: >>>> >>>>> >>>>> El 23/7/19 a las 15:36, Gordan Bobic escribió: >>>>> >>>>> Joy. So missing / mismatching debuginfo warnings are now all resolved, >>>>> but execution through gdb fails eventually with "Cannot access memory at >>>>> address ..." >>>>> gdb/frame.c:445: internal-error: get_frame_id: Assertion >>>>> `fi->this_id.p' failed. >>>>> And gdb helpfully offers to dump core. >>>>> >>>>> Anyone got any other ideas? >>>>> >>>>> I've had some problems using stock gdb, so I generally use gdb from >>>>> dts-7 >>>>> >>>> >>>> My acronym-fu is weak. What is dts-7? >>>> >>>> That is devtoolset-7 (basically gcc 7.x, gdb 8.x and others. you can >>>> find the armhfp version here >>>> https://buildlogs.centos.org/c7-devtoolset-7.armhfp/ >>>> >>>> Pablo. >>>> >>> > _______________________________________________ > Arm-dev mailing listArm-dev at centos.orghttps://lists.centos.org/mailman/listinfo/arm-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20190808/1887b032/attachment-0006.html>