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@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@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@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@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@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 list
Arm-dev@centos.org
https://lists.centos.org/mailman/listinfo/arm-dev