public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "jeremy.bennett at embecosm dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug remote/15696] New: Need for separarate qOffsets value for BSS Date: Thu, 27 Jun 2013 20:28:00 -0000 [thread overview] Message-ID: <bug-15696-4717@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=15696 Bug ID: 15696 Summary: Need for separarate qOffsets value for BSS Product: gdb Version: HEAD Status: NEW Severity: enhancement Priority: P2 Component: remote Assignee: unassigned at sourceware dot org Reporter: jeremy.bennett at embecosm dot com At present the remote serial prototocol qOffsets packet requires that the target Data and BSS offsets are the same. I have an example, using a RTOS, where this causes problems. The host supplied ELF files, which assume an ordering in memory of Text aligned at 0x4 Data aligned at 0x4 BSS aligned at 0x40 The target however loads the image in the following order, but with the same alignment constraints. Data, BSS, Text The GDB client assumes BSS has exactly the same positioning w.r.t. Data on host as the target, so BSS offsets for symbols can be computed as offsets from Data. However the different alignments mean this is not always the case. Imagine a Text of size 0x1a and a Data of size 0x17 On the host, the Text will be loaded at adress 0x0, the Data at address 0x1c (alignment moved up from 0x1a) and the BSS at address 0x80 (alignment moved up from 0x43). On the target, the Data will be loaded at address 0x0 and the BSS at address 0x40 (alignment moved up from 0x17). On the host, a variable at offset 0x4 in the BSS will be at offset 0x4 in the BSS will be at address 0x84, which is offset 0x68 from the start of Data. On the target, this variable will be at address 0x44, which is offset 0x44 from the start of Data. By assuming Data and BSS have the same relationship on the host and target, the address computation, based on the Data offset for BSS data is wrong. The solution is to allow explicit offsets for BSS in the qOffsets packet, which are distinct from the the Data offset, and to use this offset in computing BSS addresses. I'm happy to work on a patch for this, but would appreciate any suggestions for the code areas which might be affected. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2013-06-27 20:28 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-06-27 20:28 jeremy.bennett at embecosm dot com [this message] 2013-06-28 11:14 ` [Bug remote/15696] " palves at redhat dot com 2013-06-28 11:16 ` palves at redhat dot com 2013-06-28 11:37 ` jeremy.bennett at embecosm dot com 2013-06-28 11:47 ` palves at redhat dot com 2013-06-28 11:47 ` palves at redhat dot com 2013-06-28 13:16 ` jeremy.bennett at embecosm dot com
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=bug-15696-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@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: linkBe 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; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).