From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20416 invoked by alias); 17 May 2002 12:35:46 -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 20368 invoked from network); 17 May 2002 12:35:43 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 17 May 2002 12:35:43 -0000 Received: by fw-cam.cambridge.arm.com; id NAA24948; Fri, 17 May 2002 13:35:42 +0100 (BST) Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma024802; Fri, 17 May 02 13:35:31 +0100 Received: from cam-mail2.cambridge.arm.com (cam-mail2.cambridge.arm.com [172.16.1.91]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id NAA03650; Fri, 17 May 2002 13:35:30 +0100 (BST) Received: from sun18.cambridge.arm.com (sun18.cambridge.arm.com [172.16.2.18]) by cam-mail2.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id NAA22247; Fri, 17 May 2002 13:35:30 +0100 (BST) Message-Id: <200205171235.NAA22247@cam-mail2.cambridge.arm.com> To: Jason R Thorpe cc: gdb-patches@sources.redhat.com, Richard.Earnshaw@arm.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: [PATCH/RFA] Generic OS ABI handling In-reply-to: Your message of "Thu, 16 May 2002 19:52:55 PDT." <20020516195255.G4613@dr-evil.shagadelic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 May 2002 05:35:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-05/txt/msg00703.txt.bz2 thorpej@wasabisystems.com said: > Okay, here we go.. This has the includes cleaned up as suggested. > This patch also includes the changes for SH (already approved by > Elena), ARM (Richard? Does this patch look okay to you?), Alpha > (maintainerless, but it looks okay to me :-), and MIPS (HI ANDREW :-) Sorry Jason, I don't think this is correct. I don't think that it will correctly handle the fact that existing GNU binutils tools for ARM set the ELFOSABI field to ELFOSABI_ARM for starters, or the fact that ARM's toolkit uses the top eight bits of the ELF EI_FLAGS field to set the ABI in use. We either need to be able to extend the generic ELF sniffer or to supply an answer that overrides it. Please take another look at the existing ARM/ELF sniffer code in arm-tdep.c. Maybe a sniffer registration should be able to set a priority level (maybe just SPECIFIC/GENERIC) in a return field, then a SPECIFIC selection will always override a GENERIC selection. A generic sniffer would always be registered as returning a GENERIC match, and specific system sniffers could override that. Also, this comment + /* When elfosabi is ELFOSABI_NONE (0), this is supposed to indicate + that we're on a SVR4 system. However, some systems use note sections + to record OS/ABI info, but leave e_ident[EI_OSABI] zero. So we + have to check the note sections, too. */ Is not strictly correct (it's a derivative of a comment that I wrote before I fully understood the meaning of this field). A more accurate comment might be: When elfosabi is ELFOSABI_NONE (0), then the ELF structures in the file are conforming to the base specification for that machine (there are no OS-specific extensions). In order to determine the real OS in use we must look for OS notes that have been added. R.