Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Kris Warkentin" <kewarken@qnx.com>
To: "Kris Warkentin" <kewarken@qnx.com>,
	"Daniel Jacobowitz" <drow@mvista.com>
Cc: "Gdb-Patches@Sources.Redhat.Com" <gdb-patches@sources.redhat.com>
Subject: Re: [Patch] arch recognition fix for osabi.c
Date: Thu, 19 Jun 2003 12:25:00 -0000	[thread overview]
Message-ID: <047501c3365d$f809dc00$0202040a@catdog> (raw)
In-Reply-To: <08d801c334ea$23fd99c0$0202040a@catdog>

Daniel, did you have any further spare brain cycles to consider my argument?

cheers,

Kris

> > > Changelog:
> > >     * osabi.c (gdbarch_init_osabi): Just check arch for compatability
> rather
> > > identicality.
> >
> > Your mailer is eating indentation again...
>
> Yeah.  It's fine in the editor - it's the cut and paste to Outlook that
> buggers it.
>
> > This half I'm not convinced by.  From our previous exchange I don't
> > think you've fully justified it.  Not approved without more discussion.
>
> Okay.  Let's use mips as an example.  The 'compatible' check returns true
if
> they have the same arch (ie. bfd_arch_mips).  There will be many different
> values for the arch_info pointer, all with bfd_arch_mips and various other
> pieces of info such as which machine type (10k, 4300, etc.) of mips it is.
> The handler was registered for bfd_arch_mips with no other information.
In
> the absence of the ABILITY to do anything smarter, we have to assume that
if
> the handler is for bfd_arch_mips, it should be run.
>
> As it stands, if the bfd reads a file and says 'this is a tx3900' or some
> such, the pointers won't be the same and my backend init_abi won't be run
> even though I want it to run for all mips targets.
>
> > >       (generic_elf_osabi_sniff_abi_tag_sections): Add check for QNX
> Neutrino
> > > binaries.
> >
> > This bit looks fine, except for two things: you've missed the coding
> > standards by four space characters (before left parens), and your
> > "safety first" check overruns the buffer (missing +1 in the alloca).
>
> Doh!  Not very safe was it?  Sorry about that.  Fixed.
>
> cheers,
>
> Kris
>
>
>



  reply	other threads:[~2003-06-19 12:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-17 15:40 Kris Warkentin
2003-06-17 15:51 ` Daniel Jacobowitz
2003-06-17 16:04   ` Kris Warkentin
2003-06-19 12:25     ` Kris Warkentin [this message]
2003-06-19 13:18       ` Daniel Jacobowitz
2003-06-19 14:48         ` Kris Warkentin
2003-06-19 19:09     ` Daniel Jacobowitz
2003-06-19 22:10       ` Kevin Buettner
2003-07-11 15:04       ` [ping] " Kris Warkentin
2003-07-11 16:27         ` Mark Kettenis
2003-07-11 16:32           ` Daniel Jacobowitz
2003-07-18 14:13           ` Andrew Cagney
2003-07-18 14:19             ` 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='047501c3365d$f809dc00$0202040a@catdog' \
    --to=kewarken@qnx.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.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