From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from yocto-www.yoctoproject.org (yocto-www.yoctoproject.org [140.211.169.56]) by mx.groups.io with SMTP id smtpd.web11.16336.1589558046788042727 for ; Fri, 15 May 2020 08:54:06 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=vO+uldk9; spf=softfail (domain: gmail.com, ip: 140.211.169.56, mailfrom: schnitzeltony@gmail.com) Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 366B8E01B6C; Fri, 15 May 2020 08:54:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (schnitzeltony[at]gmail.com) * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no * trust * [209.85.166.182 listed in list.dnswl.org] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid Received: from mail-il1-f182.google.com (mail-il1-f182.google.com [209.85.166.182]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id F37EBE01B6A for ; Fri, 15 May 2020 08:54:02 -0700 (PDT) Received: by mail-il1-f182.google.com with SMTP id l20so3005183ilj.10 for ; Fri, 15 May 2020 08:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=igdbnGN8XNuZkPs8S5Kc+od63vMIHttx6vW2pGle1nc=; b=vO+uldk9gut3OljoHR4Cms27x65ljZ+l+J3uZhdGWdbOVhbUJFo11zB3ORFIC2iXJ3 i0xiMM97wZfGOO+1iGGY597uE5LbjFm+2PySG9XnfUJ/tEtn7mvmAk0WE9gNhwuWuAh5 b1/ZexWsxYklkLevgcDcedvjUUrK0GbWLwn4tGDIcAD/hrZ/8o2EAbs27TnR9cnPnUzq 1/iLt5mfMqbN11NgUqTAoYpzpR8HbaR58lQ07ngXjzQ/KaZYkkX/gcUo7hTYPZDMDZg8 nP7Y+AT2kQUdksjHvbtYM7ikz+vZIQdarmQSjQKa+b1dRdTZqcuYGKQbo/zh3iL+DoRh Lagw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=igdbnGN8XNuZkPs8S5Kc+od63vMIHttx6vW2pGle1nc=; b=M5C71Nm3SFHsED78Z3WWRcbaQGY+p3oX9+22gWMN1b3BvDkeQzR0Losa1clfrslYfg 6tsty9ha2dkTkRGRyLq4R4MSMMu3U5NdBkFgJkQ8e7Kq3e3qN8Vev72H7aQ2t/TuDIwV +DIPzHQ43heh1ZZI+12DeQgqIsa9Rm28ESh86iUGVHf/EnICHka8uyzEtq/yLbL2pwNu 84j1NcqEhBcu++AWbS3UF9+J/A2EdFTQEfftMMnUWC3QFjIh/2VYAgnwl6gTKbSUhNly 3j6MyRzZ8U/RI/ilN/6MkLIkTRc1YJIBHLsevGLwgnFl4oB9R7UpLRs8+xADYjBDE+h0 q1mg== X-Gm-Message-State: AOAM5327gihkNWx96BkCFLTX0EGTiBsqnpHQ7pqDPXk6J6CM0Z9NcqQh /zNhizKXafG9C76HIoP/zenP6/3pHi40ljisX4E= X-Google-Smtp-Source: ABdhPJxSxteYGpVSBTPWIKuB9TBM36RUrIPwadVrgcEy8TvWh1PFuUPmMn6QIg/pzugpe/W3kZiYWMhQRGJ1ca1EZA8= X-Received: by 2002:a92:aa53:: with SMTP id j80mr4061193ili.299.1589558041796; Fri, 15 May 2020 08:54:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Andreas M?ller" Date: Fri, 15 May 2020 17:53:49 +0200 Message-ID: Subject: Re: [yocto] What is the recommended method for debugging applications with Yocto To: Khem Raj Cc: Patrick Doyle , Yocto discussion list Content-Type: text/plain; charset="UTF-8" On Fri, May 15, 2020 at 5:36 PM Khem Raj wrote: > > On 5/15/20 8:25 AM, Patrick Doyle wrote: > > I know I can do > > > > $ bitbake base-image -cpopulate_sdk > > > > and distribute the resulting SDK to developers (myself included). > > > > But suppose I've just built and deployed an image and want to debug a > > core file generated by one of the applications. > > > > I don't see .debug directories anywhere in $TMP, so when I try to tell > > gdb to use the sysroot from the application, that works, but I don't > > get debugging symbols libc, nor do I get stack traces (on my MIPS > > target). > > (I guess it's possible that I would have found the .debug directories > > if I had performed a complete build from scratch without the benefit > > of the sstate-cache, but I rely upon the sstate-cache and routinely > > start with a blank $TMP) > > > > So, I can populate the sdk, and end up with a pile of .debug directories: > > > > $ find . -name .debug -type d > > ./tmp/work/sundial-poky-linux-musl/base-image/1.0-r0/sdk/image/opt/irobot-mt/0.2/sysroots/mips32r2-24kec-nf-poky-linux-musl/usr/lib/.debug > > ./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/packages-split/gcc-cross-canadian-mipsel-dbg/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/bin/mipsel-poky-linux/.debug > > ./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/packages-split/gcc-cross-canadian-mipsel-dbg/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/8.3.0/.debug > > ./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/packages-split/gcc-cross-canadian-mipsel-dbg/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/8.3.0/plugin/.debug > > ./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/package/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/bin/mipsel-poky-linux/.debug > > ./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/package/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/8.3.0/.debug > > ./tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-cross-canadian-mipsel/8.3.0-r0/package/opt/irobot-mt/0.2/sysroots/x86_64-pokysdk-linux/usr/libexec/mipsel-poky-linux/gcc/mipsel-poky-linux/8.3.0/plugin/.debug > > ./tmp/work/mips32r2-24kec-nf-poky-linux-musl/musl-utils/20170421-r0/packages-split/musl-utils-dbg/usr/bin/.debug > > ./tmp/work/mips32r2-24kec-nf-poky-linux-musl/musl-utils/20170421-r0/package/usr/bin/.debug > > > > Which sysroot directory is the best one at which I can point gdb for > > getting debug symbols? > > > > If I build this with an autobuilder and want to archive the sysroot > > for use by gdb later, which one should I archive? > > > > I could archive the generated SDK, but that will require that I (or > > others) install the SDK just to debug a core file, which seems a > > little heavy to me. But I can do that, if that's "the Yocto way". > > > > I wonder if there is a lighter weight mechanism for accessing the > > debugging symbols during development, and for archiving said symbols > > for post-development support. > > > > Any ideas? Best practices? Recommended approaches? > > > > I would think of using IMAGE_GEN_DEBUGFS set to 1 which should generate > a debug archive of image > > see following for detailed steps > > https://docs.windriver.com/bundle/Wind_River_Linux_Platform_Developers_Guide_9_1/page/fvn1520619692704.html > > https://developer.ridgerun.com/wiki/index.php?title=Preparing_Yocto_Development_Environment_for_Debugging > > > Thanks > > > > --wpd > > I created [1] in meta-mortsgna. It is not recommended (bit of a hack / nobody but me and my colleagues use it) but it * works on the fly: Once enabled building the recipe you want to debug is good enough * not bound to SDK or image which tends to last * no manual copying necessary [1] https://github.com/schnitzeltony/meta-mortsgna/blob/master/classes/instant-sysroot-target.bbclass Andreas