On 4/18/16 4:05 PM, Andreas Müller wrote: > On Mon, Apr 18, 2016 at 8:50 PM, Mark Hatle <[email protected]> wrote: >> On 4/18/16 9:16 AM, Andreas Müller wrote: >>> On Mon, Apr 18, 2016 at 3:55 PM, Burton, Ross <[email protected]> wrote: >>>> >>>> On 18 April 2016 at 14:08, Hongxu Jia <[email protected]> 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 > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
