From: Yao Qi <yao@codesourcery.com>
To: <lgustavo@codesourcery.com>
Cc: "'gdb-patches@sourceware.org'" <gdb-patches@sourceware.org>,
Mike Frysinger <vapier@gentoo.org>
Subject: Re: [PATCH, gdbserver] Further cleanup of FDPIC/DSBT divergences
Date: Mon, 24 Jun 2013 13:47:00 -0000 [thread overview]
Message-ID: <51C84CBD.10506@codesourcery.com> (raw)
In-Reply-To: <51C34F14.8070803@codesourcery.com>
On 06/21/2013 02:51 AM, Luis Machado wrote:
> Things have changed, and c6x is now using the exact same data structures
> as FDPIC-based targets in uClibc. Please refer to
> http://lists.uclibc.org/pipermail/uclibc/2013-May/047789.html for the
> uClibc changes that led to this.
>
> Mark Salter, the author of the uClibc change, has agreed with the
> solution i proposed:
> http://lists.uclibc.org/pipermail/uclibc/2013-May/047790.html.
>
> It is all good, but we've been conditionalizing the c6x-specific
> target_loadmap data structure based on the presence of PT_GETDSBT. This
> has always been defined in uClibc and, since Mark's change, it doesn't
> work as a hint of whether to use the new or the old target_loadmap data
> structure anymore. Therefore we will/already have a potential problem
> with backwards compatibility.
>
> Bernhard has stated that backwards compatibility on uClibc's side is not
> a problem:http://lists.uclibc.org/pipermail/uclibc/2013-June/047801.html.
>
> With all that exposed, my proposed change to gdbserver is to drop all
> the DSBT-specific bits, remove their definitions and explicitly use
> FDPIC definitions instead, making things a little bit cleaner.
>
> In the following patch i also changed the code slightly to stop defining
> linux_read_loadmap to NULL and i switched to explicitly setting the
> target hook to NULL in the absence of the required definition.
>
> What do you think? Yao? Mike?
Luis,
Looks Mark S. proposed using FDPIC in tic6x port in kernel, instead of
DSBT which was used when we did the tic6x port in GDB. I checked the
kernel log, and found that DSBT constants are never used in the official
kernel. They only appeared in the linux-c6x.org git tree temporarily.
Since kernel and uclibc has migrated to the new scheme, I don't worry
about the compatibility issue here.
>
> 2013-06-20 Luis Machado<lgustavo@codesourcery.com>
>
> * linux-low.c: Remove check for PT_GETDSBT.
> (target_loadmap): Remove data structure conditionalized by
> the presence of PT_GETDSBT.
> (LINUX_LOADMAP, LINUX_LOADMAP_EXEC,
> LINUX_LOADMAP_INTERP): Remove definitions.
Not sure we can break words in parentheses into multiple lines. I suggest:
(LINUX_LOADMAP, LINUX_LOADMAP_EXEC): Remove definitions.
(LINUX_LOADMAP_INTERP): Likewise.
the patch is OK to me, but we also need adjustments in solib-dsbt.c.
This patch should go in together with the changes in solib-dsbt.c.
--
Yao (é½å°§)
next prev parent reply other threads:[~2013-06-24 13:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-20 18:57 Luis Machado
2013-06-24 13:47 ` Yao Qi [this message]
2013-06-24 14:25 ` Luis Machado
2013-08-08 16:41 ` Luis Machado
2013-08-09 15:08 ` Pedro Alves
2013-08-09 17:20 ` Luis Machado
2013-08-10 0:33 ` Yao Qi
2013-08-12 13:41 ` Luis Machado
2013-08-12 14:06 ` Pedro Alves
2013-08-26 5:31 ` Mike Frysinger
2013-06-24 16:17 ` Mike Frysinger
2013-06-25 15:03 ` Pedro Alves
2013-06-25 15:04 ` Luis Machado
2013-06-25 16:26 ` Mike Frysinger
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=51C84CBD.10506@codesourcery.com \
--to=yao@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=lgustavo@codesourcery.com \
--cc=vapier@gentoo.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