[OE-core] [PATCH 01/17] conf/bitbake.conf package.bbclass: fix dbg package not contain sources while -fdebug-prefix-map used
Andreas Müller
schnitzeltony at googlemail.com
Tue Apr 19 14:11:32 UTC 2016
On Tue, Apr 19, 2016 at 9:33 AM, Hongxu Jia <hongxu.jia at windriver.com> wrote:
> Hi all,
>
> With some investigation, there is an example to explain how to do remote
> debug.
>
> Also file [YOCTO #9481] for document.
>
> Hi Andreas,
>
> Would you please have a look the example, to see if it could fit your case.
>
> Example:
>
> 1. Build a image with gdbserver and gzip installed. The gzip
> is the debug binary. Append the following to local.conf
> ...
> IMAGE_INSTALL_append = " gdbserver gzip"
> ...
>
> $ bitbake core-image-sato
>
> 2. Build gdb-cross for remote debug on host
>
> $ bitbake gdb-cross-i586
>
> 3. start qemu
>
> $ runqemu qemux86 core-image-sato
>
> 4. On host side, create symlink /usr/src/debug to
> ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS} which the
> location of sources is /usr/src/debug.
>
> $ ln -snf /TOPDIR/tmp/work/i586-poky-linux /usr/src/debug
>
> 5. On target side, ipaddr is 128.224.163.187,
> run gdbserver to debug "gzip -h"
>
> root at qemux86-64:~# gdbserver localhost:1024 gzip -h
> Process gzip created; pid = 530
> Listening on port 1024
>
> 6. On host side, enter gzip's devshell
> $ bitbake -cdevshell gzip
>
> 7. On host side, run gdb-cross to remote debug gzip
>
> gzip-1.6# i586-poky-linux-gdb ../build/gzip
>
> 8. Use path ${STAGING_DIR_HOST} as the system root for
> the program being debugged. Any absolute shared
> library paths will be prefixed with path;
>
> (gdb) set sysroot /TOPDIR/tmp/sysroots/qemux86
>
>
> 9. Start remote target, set break point at help()
>
> (gdb) target remote 128.224.163.187:1024
> (gdb) break gzip.c:325
> (gdb) info break
> Num Type Disp Enb Address What
> 1 breakpoint keep y 0x0000000000401ec1 in main at
> /usr/src/debug/gzip/1.6-r0/gzip-1.6/gzip.c:325
> (gdb) c
> Continuing.
>
> Breakpoint 1, main (argc=2, argv=0x7fffffffeca8) at
> /usr/src/debug/gzip/1.6-r0/gzip-1.6/gzip.c:465
> 465 help(); do_exit(OK); break;
> (gdb) list
> 460 case 'd':
> 461 decompress = 1; break;
> 462 case 'f':
> 463 force++; break;
> 464 case 'h': case 'H':
> 465 help(); do_exit(OK); break;
> 466 case 'k':
> 467 keep = 1; break;
> 468 case 'l':
> 469 list = decompress = to_stdout = 1; break;
> (gdb) c
> Continuing.
> [Inferior 1 (process 1246) exited normally]
>
>
> 10. On target side, get output of "gzip -h"
> [snip]
> Remote debugging from host 128.224.153.74
> Usage: gzip [OPTION]... [FILE]...
> Compress or uncompress FILEs (by default, compress FILES in-place).
>
> Mandatory arguments to long options are mandatory for short options too.
>
> -c, --stdout write on standard output, keep original files unchanged
> -d, --decompress decompress
> -f, --force force overwrite of output file and compress links
> -h, --help give this help
> -k, --keep keep (don't delete) input files
> -l, --list list compressed file contents
> -L, --license display software license
> -n, --no-name do not save or restore the original name and time stamp
> -N, --name save or restore the original name and time stamp
> -q, --quiet suppress all warnings
> -r, --recursive operate recursively on directories
> -S, --suffix=SUF use suffix SUF on compressed files
> -t, --test test compressed file integrity
> -v, --verbose verbose mode
> -V, --version display version number
> -1, --fast compress faster
> -9, --best compress better
>
> With no FILE, or when FILE is -, read standard input.
>
> Report bugs to <bug-gzip at gnu.org>.
>
> Child exited with status 0
> GDBserver exiting
> [snip]
>
> //Hongxu
>
thanks a lot for your efforts. Do I understand this right: You suggest
to use build sysroot (on my own risk - as I did before) and make gdb
happy by linking sources?
Problem I see is that we have multiple package archs e.g
ARM/ARMThumb/Machine so ${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}
expands to multiple paths. But a script symlinking all together + set
substitute-path might help here...
I will play around with this in the later...
Andreas
More information about the Openembedded-core
mailing list