From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19705 invoked by alias); 12 Jun 2003 14:27:21 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 19689 invoked from network); 12 Jun 2003 14:27:21 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.54) by sources.redhat.com with SMTP; 12 Jun 2003 14:27:21 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id PAA22323; Thu, 12 Jun 2003 15:27:19 +0100 (BST) Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id h5CERJR20619; Thu, 12 Jun 2003 15:27:19 +0100 Message-Id: <200306121427.h5CERJR20619@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: "Kris Warkentin" cc: Richard.Earnshaw@arm.com, "Gdb@Sources.Redhat.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: Elf OS ABI Number In-reply-to: Your message of "Wed, 11 Jun 2003 13:20:43 EDT." <09cc01c3303d$ca16b550$0202040a@catdog> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Jun 2003 14:27:00 -0000 From: Richard Earnshaw X-SW-Source: 2003-06/txt/msg00203.txt.bz2 > > > Does anyone know how to get one of these? I was rooting around on > Caldera's > > > website but didn't see anything. I've realized that we need to have a > > > practical way to identify QNX binaries and this looks like the way to > go. > > > > > > > A fairly common question, to which most times the answer is that you don't > > need one. > > > > You should only be using the OS ABI field if you are changing the meaning > > of the ELF specifics for a processor (new relocs, for example) which a > > linker not trained to recognise these would be unable to handle. It > > shouldn't be used to represent things that are encoded in the instructions > > inside sections (eg library calls specific to your OS, etc). > > Actually, we do have a few things that are different - QNX specific > relocations, different MIPS ABI, etc. It seems like having the ABI number > can do no harm but can certainly be useful. As I said before, new relocations is a valid reason for an OS_ABI field change. However, an ABI change (calling standard) is not -- it doesn't change the meaning of the ELF container, which is what the field is about. The harm is that a linker is supposed to reject an OS_ABI field setting it doesn't understand. Is there a good reason why you've invented your own relocs? If the processor vendor (who generally own the reloc space allocation for their processor) where to allocate a reloc that conflicts with your usage at a later date you might have a major problem on your hands. > The problem with things like > .note sections for identifying binaries is that a stripped binary can no > longer be identified. No, .note sections are not symbols, so are not removed by strip. The only way to remove a .note section is to use objcopy and tell it not to copy that section. R.