From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10571 invoked by alias); 5 Feb 2003 21:23:04 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10548 invoked from network); 5 Feb 2003 21:23:04 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 5 Feb 2003 21:23:04 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id QAA05772; Wed, 5 Feb 2003 16:12:37 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id QAA14955; Wed, 5 Feb 2003 16:23:03 -0500 Message-ID: <1dfb01c2cd5c$b2cf98b0$0202040a@catdog> From: "Kris Warkentin" To: "Mark Kettenis" Cc: References: <1c3601c2cbc1$72eac3b0$0202040a@catdog> <86d6m6e9p7.fsf@elgar.kettenis.dyndns.org> Subject: Re: patch to add QNX NTO i386 support Date: Wed, 05 Feb 2003 21:23:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2003-02/txt/msg00198.txt.bz2 > The i386-target was "multi-arched" a while ago, which unfortunately > means that your patch will need extensive modification before we can > add it. Don't worry, I'll help you where needed. Funny you should write. This is just what I've been working on for the past few hours. > Basically, most of what's in your tm-i386nto.h file will have to go. > Instead you should create a i386nto-tdep.c file where you put and > register an OS/ABI handler for you OS. Based on the contents of yoyr Already made the tdep file. I was just about to email the list to ask about how to register the handler (I had been looking at the i386-interix-tdep.c file) when I got your email. > tm.h file, you should probably base your OS/ABI handler on > i386-tdep.c:i386_svr4_init_abi(). AFAICT, you'll need > set_gdbarch_decr_pc_after_break() and > set_solib_svr4_fetch_link_map_offsets() there. Move > i386_qnx_xvr4_link_map_offsets to that file. Yeah. I had started with an _init function in i386-nto-tdep that just set some gdbarch stuff but I quickly realized that it wasn't the right way to do it. > You'll also need to find a way to distinguish QNX binaries from other > OS'es. The hardware breakpoint stuff will have to be moved to the > nm.h. Most of the other stuff shouldn't be necessary or should be > moved there too. Okay. Not sure how but I'll look into it. Once I've done that, do I register an osabi_sniffer to determine the binary? > You should probably use xm-i386.h as your xm.h file. The other stuff > should either be discarded or moved to your nm.h file too. Okay. > I don't think you should try to match x86-*-nto* in configure.host; > the configure.tgt doesn't either. Probably right. We have a chief architect here that insists that i386 is not correct as a generic specifier and, since our uname doesn't tell you 5 or 686, it returns x86. We take care of that mapping in config.guess though so I believe that the x86 part is redundant now. We still build with --target=ntox86 though. > As Andrew already said, it is probably a good idea to add the QNX i386 > target stuff first, such that we can build cross-debuggers for it. > Then we can look more closely at the native stuff. Sure. The separation went quite well actually. I've got all the remote and native stuff separated and cpu specific tdep files and headers made. The only major work left is cleaning up our stupid config/i386 stuff and getting the gdbarch setup properly. Thanks Kris