Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kris Warkentin <kewarken@qnx.com>
To: gdb-patches@sources.redhat.com
Subject: Re: Ping: [patch] general updates and improvements to QNX NTO support
Date: Fri, 03 Dec 2004 23:16:00 -0000	[thread overview]
Message-ID: <41B0EEC7.2080104@qnx.com> (raw)

Mark Kettenis wrote:

 > Ah, OK.  Sorry, I misread that.
 >
 >

No problem...kind of a funny looking diff.

 >   I also changed the macro defines so that I can assign and test.  ie.
 >
 >   old:
 >   define nto_regset_fill(regset, data) 
(*current_nto_target.nto_regset_fill) (regset, data)
 >
 >   new:
 >   #define nto_regset_fill (current_nto_target.nto_regset_fill)
 >
 >   That way I can easily switch targets in code.
 >
 > Hmm.  In that case wouldn't it be better to turn current_nto_target
 > into a pointer, and having a `struct nto_target_ops' for each target
 > such that you can switch targets by simply doing a pointer assignment?
 > That would probably get rid of all the macros.
 >
 >

That's a good idea and I actually do something very similar in our 
remote support (which I haven't submitted yet)  As it stands, rather 
than just switching a pointer, I initialize all the members in 
init_i386nto_ops.  I have similar init functions for arm, sh, mips and 
ppc.  I'm not sure how I'd get rid of the macros though....it's still 
convenient to have a generic nto_regset_fill function macro rather than 
having to dereference.  Plus, it's handy to be able to check for 
validity before using a function like in nto_elf_osabi_sniffer.  I'm 
just thinking that if gdb were truly multi-arched, there could be a 
situation where my nto_target_ops haven't been initialized and something 
like a sniffer could crash.  I could be wrong about that though.

 >   I am defining current_nto_target in nto-tdep.h as being extern but 
I   don't declare it there.  Is having a global verboten?  I has assumed 
it   was okay since we have many precedents like inferior_ptid and 
current_target and such.
 >
 > Declaring variables as `extern' in a header file is fine, although you
 > should avoid globals if as much as possible.
 >

I did it that way to be consistent with the current_target idea within 
gdb.  We actually have five targets so it makes it easier to switch 
things around.  I'd welcome any ideas for improvement though.  Not much 
originality on all this - I pretty much tried to do things exactly the 
way target.h does.  I hope I don't lose marks for plaigarism... ;-)

cheers,

Kris


             reply	other threads:[~2004-12-03 22:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-03 23:16 Kris Warkentin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-11-19 20:47 Kris Warkentin
2004-11-26 20:37 ` Ping: " Kris Warkentin
2004-12-03 16:09   ` Kris Warkentin
2004-12-03 16:17     ` Mark Kettenis
2004-12-03 17:01       ` Kris Warkentin
2004-12-03 17:23         ` Kris Warkentin
2004-12-03 17:44         ` Mark Kettenis

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=41B0EEC7.2080104@qnx.com \
    --to=kewarken@qnx.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