Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: lgustavo@codesourcery.com
Cc: "'gdb-patches@sourceware.org'" <gdb-patches@sourceware.org>
Subject: Re: [RFC, gdbserver] Avoid defining linux_read_offsets when the target does not need it
Date: Wed, 15 May 2013 18:51:00 -0000	[thread overview]
Message-ID: <201305151451.52667.vapier@gentoo.org> (raw)
In-Reply-To: <5193CEE3.4040506@codesourcery.com>

[-- Attachment #1: Type: Text/Plain, Size: 2054 bytes --]

On Wednesday 15 May 2013 14:07:31 Luis Machado wrote:
> On 05/15/2013 07:12 PM, Mike Frysinger wrote:
> > On Wednesday 15 May 2013 12:26:06 Luis Machado wrote:
> >> On 05/15/2013 06:06 PM, Mike Frysinger wrote:
> >>> On Wednesday 15 May 2013 07:25:34 Luis Machado wrote:
> >>>> We have a target that uses loadmaps as opposed to the above mechanism.
> >>>> It is just another ptrace request, but it doesn't use
> >>>> linux_read_offsets at all.
> >>> 
> >>> you mean FDPIC ?  gdb already supports that and uses a different set of
> >>> ptrace requests for that.  ideally, gdb nor gdbserver should not be
> >>> tied to a specific file format (what format it happened to be compiled
> >>> for). instead, gdbserver should support all formats and then gdb
> >>> detects the format and changes its requests based on that.
> >> 
> >> Not FDPIC, but DSBT. I agree gdb/gdbserver should be format-agnostic,
> >> but it grew like this. Let's not extend the uglyness though.
> > 
> > i thought someone already committed support for DSBT, and i helped merge
> > some of the FDPIC differences.  it was for the c6x port iirc.
> 
> That is correct, but there are a few differences in the loadmap format
> between targets.  My idea is to clean that up and make it more generic
> without having to use #if blocks inside linux-low.c.

as long as the functionality isn't based on the format gdbserver itself is 
compiled as, sounds fine.  i believe we cleaned up all the DSBT logic so that 
it isn't fighting with FLAT (i know on Blackfin we have a single gdbserver that 
can support FLAT or FDPIC).

glancing at the code, we do fail slightly in that it's currently DSBT||FDPIC, 
but in practice that hasn't mattered as no one has implemented both formats 
for the same architecture.

personally, i'd be interested in why DSBT was conceived in the first place 
instead of using the existing FDPIC.  are the minor differences on purpose ?  
by accident ?  or why people are using a different format from either DSBT or 
FDPIC ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

      reply	other threads:[~2013-05-15 18:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-15 11:25 Luis Machado
2013-05-15 14:14 ` Pedro Alves
2013-05-16 10:34   ` Luis Machado
2013-05-15 14:17 ` Yao Qi
2013-05-15 16:06 ` Mike Frysinger
2013-05-15 16:26   ` Luis Machado
2013-05-15 17:12     ` Mike Frysinger
2013-05-15 18:08       ` Luis Machado
2013-05-15 18:51         ` Mike Frysinger [this message]

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=201305151451.52667.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=gdb-patches@sourceware.org \
    --cc=lgustavo@codesourcery.com \
    /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