From: Sergei Poselenov <sposelenov@emcraft.com>
To: gdb@sourceware.org
Subject: Re: [rfc / remote protocol] ELF segment based qOffsets
Date: Fri, 14 Dec 2007 10:29:00 -0000 [thread overview]
Message-ID: <47625A95.7080203@emcraft.com> (raw)
Hello all,
We've ran into the following problem while running the ppc cross-gdb
with the U-Boot firmware image:
bash# ./gdb u-boot
GNU gdb Red Hat Linux (6.7-1rh)
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=ppc-linux".
The target architecture is set automatically (currently powerpc:403)
..
warning: Loadable segment ".resetvec" outside of ELF segments
warning: Loadable segment ".bootpg" outside of ELF segments
(gdb)
bash# readelf -lS u-boot
There are 27 section headers, starting at offset 0xc3dc0:
Section Headers:
[Nr] Name Type Addr Off Size ES
Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00
0 0 0
[ 1] .resetvec PROGBITS fffffffc 02e208 000004 00
AX 0 0 1
[ 2] .bootpg PROGBITS fffff000 02d20c 00033c 00
AX 0 0 1
[ 3] .text PROGBITS fffc0000 0000a0 022f9c 00
AX 0 0 16
[ 4] .rodata PROGBITS fffe2f9c 02303c 007250 00
A 0 0 4
[ 5] .reloc PROGBITS fffea200 02a2a0 001204 00
WA 0 0 1
...
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg
Align
LOAD 0x0000a0 0xfffc0000 0xfffc0000 0x2d16c 0x35cd0 RWE 0x10
LOAD 0x02d20c 0xfffff000 0xfffff000 0x01000 0x01000 R E 0x1
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
Section to Segment mapping:
Segment Sections...
00 .text .rodata .reloc .data .data.rel.local
.data.rel.ro.local .data.rel data .u_boot_cmd
01 .resetvec .bootpg
02
You see, the warnings are caused by the fact that the segment 01 has
address/size values which wraps to 0 in the following 'if' condition
introduced by the $subj in elfread.c, elf_symfile_segments():
...
&& vma < segments[j]->p_vaddr + segments[j]->p_memsz)
The place above is trivial to fix, but I wonder will be any
other consequences to the remote debugging of such kind of
images? (I can't try this at the moment)
Regards,
Sergei
next reply other threads:[~2007-12-14 10:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-14 10:29 Sergei Poselenov [this message]
2007-12-17 22:55 ` Daniel Jacobowitz
2007-12-19 15:45 ` Sergei Poselenov
2007-12-19 16:20 ` Sergei Poselenov
-- strict thread matches above, loose matches on Subject: below --
2007-05-09 19:12 Daniel Jacobowitz
2007-05-09 19:47 ` Eli Zaretskii
2007-05-19 17:38 ` Pedro Alves
2007-06-18 15:48 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47625A95.7080203@emcraft.com \
--to=sposelenov@emcraft.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox