All,
> -----Original Message----- > From: [email protected] <[email protected]> On > Behalf Of Bryan Evenson via lists.yoctoproject.org > Sent: Monday, June 1, 2020 4:46 PM > To: Bryan Evenson <[email protected]>; > [email protected] > Subject: Re: [yocto] Eclipse GDB setup issues; can't determine cause for > SIGSEGV > > All, > > > -----Original Message----- > > From: [email protected] <[email protected]> On > > Behalf Of Bryan Evenson via lists.yoctoproject.org > > Sent: Monday, June 1, 2020 11:16 AM > > To: [email protected] > > Subject: [yocto] Eclipse GDB setup issues; can't determine cause for > SIGSEGV > > > > All, > > > > I have a AT91SAM9G25 system that has been idle for a couple years > (running > > morty, yocto version 2.2.1) and I am working on updating to the latest > Yocto > > production branch. Before I get there, I'm trying to confirm the old setup > > and I'm having problems with remote debugging. I know there have been > > changes since yocto version 2.7 for debugging support, so I want to make > > sure I can get the old setup to work first prior to changing everything. > > I'm > > looking for assistance in tracking down my debug issues. > > > > My stable production image is based off of core-image-minimal, with a few > > additional packages for our proprietary applications (proprietary > applications > > are written in C). I also have a development image, based off of our > > production image, with the following additions: > > > > IMAGE_FEATURES += "package-management dev-pkgs eclipse-debug > allow- > > empty-password empty-root-password" > > > > IMAGE_INSTALL += " \ > > #same additional packages as production image \ > > #"-dbg" version of proprietary applications \ > > gdbserver \ > > " > > # Strip python from the image to reduce the image size > > PACKAGE_EXCLUDE = "python" > > > > I have the Eclipse Yocto plugin installed and it is setup to use the SDK > > that I > > have built based on the development image. I've confirmed that I can start > a > > debug session on one of our proprietary applications. I can set breakpoints > > and run the debugger. However, the debugger always stops at the first call > > to uuid_compare with a SIGSEGV. The last line in the call stack states > > "<symbol is not available> 0x00000000". From my understanding, the stack > > pointer is getting set to NULL when uuid_compare is getting called. If I > > stop > > the debugger and just run the application on the hardware, the application > > runs without errors. I have confirmed with syslog messages that I do not > > have the same NULL stack pointer issue when I run the application outside > of > > the debugger. > > > > Any suggestions on where to start looking? I don't see any obvious > possible > > causes and I don't know where to start looking for the problem. > > > > On a whim, I changed in my code: > if(uuid_compare(uuid1, uuid2) == 0) > > To: > If(memcmp(uuid1, uuid2, 16) == 0) > > After this change the problematic line of code worked just fine. The > debugger worked fine until I got to the next spot in my code that called > uuid_compare. At the next call to uuid_compare I got the same SIGSEGV > error I had before. Something is clearly a problem with calling uuid_compare. > However, I'm using several other functions from the uuid library > (uuid_is_null, uuid_parse, uuid_unparse for a few) and none of them are > causing problems. I don't think it's a problem with the input parameters > because I'm passing the same UUIDs to memcomp as I did to uuid_compare. > Has anyone ever seen only one function from a library cause problems like > this? I don't know if this is related, but I noticed that the debugger cannot step into any library functions. For example, I tried stepping into strncpy, and the debugger stepped over the function call. I switched to assembly instruction stepping mode, then when I stepped into strncpy I received the message "No source available for strncpy@plt". I continued single stepping and was able to step through all the assembly code for strncpy. I then instruction single stepped into uuid_compare, and I was able to single step without issue until I got to the following instruction: bx r12 When this instruction is called, r12 is 0. I'm a little confused why this library function call is failing in this manner (when all the input parameters to uuid_compare are valid), and I'm not sure why I can't source step through any library functions. If anyone has any suggestions on either issue, please let me know. Thanks, Bryan > > > Thanks, > > Bryan
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49556): https://lists.yoctoproject.org/g/yocto/message/49556 Mute This Topic: https://lists.yoctoproject.org/mt/74606807/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
