From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) by mail.openembedded.org (Postfix) with ESMTP id C984860107 for ; Tue, 19 Apr 2016 00:51:56 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail.windriver.com (8.15.2/8.15.1) with ESMTPS id u3J0pt5B019158 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Apr 2016 17:51:55 -0700 (PDT) Received: from soho-mhatle-m.local (172.25.36.226) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.3.248.2; Mon, 18 Apr 2016 17:51:54 -0700 To: =?UTF-8?Q?Andreas_M=c3=bcller?= References: <62a9bef209d903048c1095d90387384115eb6fd5.1459147231.git.hongxu.jia@windriver.com> <571496CC.8010607@windriver.com> <57149B89.2090607@windriver.com> <5714A30A.9000204@windriver.com> <5714AA1E.9020505@windriver.com> <5714DC35.7040206@windriver.com> <57152C67.1030508@windriver.com> From: Mark Hatle Organization: Wind River Systems Message-ID: <57158128.5070706@windriver.com> Date: Mon, 18 Apr 2016 19:51:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Cc: Patches and discussions about the oe-core layer Subject: Re: [PATCH 01/17] conf/bitbake.conf package.bbclass: fix dbg package not contain sources while -fdebug-prefix-map used X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 00:51:56 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/18/16 4:05 PM, Andreas Müller wrote: > On Mon, Apr 18, 2016 at 8:50 PM, Mark Hatle wrote: >> On 4/18/16 9:16 AM, Andreas Müller wrote: >>> On Mon, Apr 18, 2016 at 3:55 PM, Burton, Ross wrote: >>>> >>>> On 18 April 2016 at 14:08, Hongxu Jia wrote: >>>>> >>>>> If sysroot is required, override DEBUG_FLAGS to remove -fdebug-prefix-map >>>> >>>> >>>> We should probably get this in the release notes, as many people do indeed >>>> want remote debug to work. >>>> >>>> Can you tell gdb the base path to use when looking for symbols? I've not >>>> done remote GDB for some time but wouldn't "set substitute-path / >>>> //my/sysroot/" work? Or maybe /usr /my/sysroot/usr? >>>> >>>> If gdb can't be told then instead of having to replace all of DEBUG_FLAGS it >>>> would be neat if the prefix mapping variables where in another variable that >>>> could just be unset. >>>> >>>> Ross >>> OK I think I could live with removing -fdebug-prefix-map for now. >>> >>> A thought: We have the setting IMAGE_GEN_DEBUGFS - I have not yet >>> tested. As far as I understand it creates an unstripped sysroot and >>> does not affect target rootfs - is that correct? Does the sysroot >>> created by IMAGE_GEN_DEBUGFS contain the sources? If yes we could set >>> that as sysroot for gdb. >>> >>> I think one of the problems we have here is that there is no reference >>> way documented (or it is outdated) how remote debugging is meant to be >>> performed. >> >> Remote debugging is setup to always assume the remote side has access to a >> debugable sysroot. Remote (target from host) is setup to always assume the -host- side has access to a debuggable sysroot. The target -never- needs access, unless you are trying to run GDB on the target. > Just that I get this right: remote = target? If yes: Where do you get > this from? Or - have you ever run a remote session with files taken > from target? I have: see caffeine/colleagues section below. >> This isn't the project's sysroot, since that is transient, >> but a REAL matching sysroot to the main image. > If you say transient: Do you mean status of last build. Isn't that > what I am usually looking for when debugging? It's transient. There is no direct correlation between the contents of the image you are booting and the sysroot directory int he project/tmp/sysroot area. The files MIGHT be related, but they are not the same. The build project is only setup for actually building software. To debug, you must you the -dbg packages that are created as part of the build. Using the IMAGE_GEN_DEBUGFS automates this process. Or you can individually grab (and unpack) the -dbg for the components you wish to debug. >> The easiest way to do this is to add the following to your local.conf: >> IMAGE_GEN_DEBUGFS = '1' > This exactly what I've asked for in my previous mail - further comments below. >> >> After this, look in your deploy directory and you will see the image to deploy >> to the target, and also a matching 'debug' chunk that you keep on your local >> host. This way you -know- they are always in sync. > You really want me to wait for building an full image after each > modification - I will either die for caffeine overdose or my > colleagues will kill me... How big is your filesystem? Typically when I make a small change, it only takes me minutes to build a filesystem.. (I'm roughly similar to the core-image-base.) I'm not changing key things like the toolchain or glibc, I'm changing individual applications with few downstream dependencies. You can always build the component by itself and simply pull the -dbg components out if you want. That is certainly a short cut method to this. The non-dbg have the correct versions for deployment for runtime, while the -dbg has the corresponding debug information. The sysroot though is not the right place for this, if you want to work around the system use the actual work location for the components themselves and copy the pieces from there. >> >> There is class material from the various Yocto Project Dev Day classes on using >> this. >> >> >> The alternative is tell GDB itself to map directories. I don't remember offhand >> the right option, but GDB supports remapping a directory reference to an actual >> directory. It should be pretty simple to re-map it -- but due to the transient >> nature of the sysroot directory in the build, I don't recommend doing it this way. >> > We are using remote debugging with build sysroot almost daily and we > do that since we use openembedded. The more I learn here it seems > nobody else does remote debugging. How do you fix bugs? I do remote debugging all the time, note -- for much of my work I'm still on 2.0. But the design of 2.1 (master) actually makes this easier then before, as all of the file references are finally correct -- instead of a mismatched set of target and host dependencies. I -always- use the -dbg versions when doing local (on target) or remote (host to target) debugging. It takes no additional time, and it's easy to shortcut as I mentioned above. The sysroot is only appropriate for compiling against. > I'll remove -fdebug-prefix-map and wait till remote debugging breaks > again - maybe then completely. That scares me as I am loosing the > possiblity to start a remote debug session on an productive image > within seconds. Without the prefix maps, you won't get functional -dbg packages for remote debugging of deployed production systems. This is really the key here, we facilitate both development -and- production remote debug. I don't know of any other (embedded) build system that is designed with production remote debug built in. You never have to deploy symbols to your production images, but yet you can still cross debug them by simply keeping a copy of the -dbg (and as of recently the corresponding debugfs image.) This ensures the code is not only debugable today, but in the future when your product has been deployed for a long time. --Mark > Andreas >