[meta-freescale] image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

[Julio Cruz Barroso]

Hi Bjørn, Christian,

I'm trying to perform a remote debug with a Qt Application (as you described below).

The GDB (at QT Creator) show a Segmentation Fault at dl-debug.c [1]. Basically, the same situation.

I performed the following steps:

- Sync to the latest jethro revision
- Delete tmp directory
- Rebuild SD image
- Rebuild SDK installer (bitbake my-image -c populate_sdk). 'my-image' inherit populate_sdk_qt5

Some days ago, the remote debugging was working without problem. 

There is a current issue related with this? Any advices or suggestion?

Thanks for your help,

Julio

[1] SIGSEGV during remote debug: [dl-debug.c] Line 55: if (r->r_map == NULL || ldbase != 0)


-----Original Message-----
From: meta-freescale-bounces at yoctoproject.org [mailto:meta-freescale-bounces at yoctoproject.org] On Behalf Of Bjørn Forsman
Sent: Thursday, January 07, 2016 5:49 PM
To: Christian Ege
Cc: meta-freescale
Subject: Re: [meta-freescale] image-prelink (can) cause SIGSEGV on program startup (when run under GDB)

Hi Christian,

On 7 January 2016 at 10:40, Christian Ege <k4230r6 at gmail.com> wrote:
> Hi Bjørn,
> Am 07.01.2016 9:57 vorm. schrieb "Bjørn Forsman" <bjorn.forsman at gmail.com>:
>>
>> Hi all,
>>
>> Just FYI, I spent 2 days debugging why my application would fail to 
>> start when run under GDB (gdbserver). It received SIGSEGV _before_ 
>> entering main. Turns out that by removing "image-prelink" from 
>> local.conf fixes it.
>>
> From my experience image-prelink and using the OpenEmbedded SDKs is 
> not recommended. Maybe your SDK is older than your current rootfs this 
> can cause GDB to struggle.

Thanks for the data point. The thing is, debugging worked fine for a long time. But when I added another library dependency, things broke.

Unless the build system is completely borked, rootfs and SDK should be in sync. I explicitly rebuilt and re-flashed exactly to eliminate that kind of trouble.

> Anyway we had big issues when we tried to analyse stack backtraces 
> with our rootfs and marching SDK. Because the libc in the SDK is not 
> prelinked and the checksum check in GDB is not passed GDB barked out some warning.

I guess you mean warnings like:

(gdb) set sysroot
~/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Multimedia.so.5"
is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Widgets.so.5"
is not at the expected address (wrong library or version mismatch?)
warning: .dynamic section for
"/home/bfo/poky-toolchain/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/usr/lib/libQt5Gui.so.5"
is not at the expected address (wrong library or version mismatch?) ...

The weird part is that these warnings seem to come no matter what (prelink or not). (I guess I should triple check that...)

> Maybe there is a magic knob to tune but we did not found it. But the 
> last time I checked was in an older Yocto/OpenEmbedded environment.

I'm on early Yocto 2.0 / Jethro. I plan on updating soon, there are probably many fixes.

Best regards,
Bjørn Forsman
--
_______________________________________________
meta-freescale mailing list
meta-freescale at yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale