From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30432 invoked by alias); 25 Jan 2008 04:24:38 -0000 Received: (qmail 30424 invoked by uid 22791); 25 Jan 2008 04:24:37 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Jan 2008 04:24:19 +0000 Received: (qmail 15974 invoked from network); 25 Jan 2008 04:24:17 -0000 Received: from unknown (HELO ?192.168.2.10?) (carlos@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Jan 2008 04:24:17 -0000 Message-ID: <47996465.6090201@codesourcery.com> Date: Fri, 25 Jan 2008 09:56:00 -0000 From: Carlos O'Donell User-Agent: Mozilla-Thunderbird 2.0.0.9 (X11/20080110) MIME-Version: 1.0 To: Joel Brobecker CC: Pedro Alves , Jim Blandy , gdb-patches , Dave Anglin Subject: Re: arm_addr_bits_remove References: <479752C8.8030201@portugalmail.pt> <8f2776cb0801231121r3fe9aea0q6f3c3d6887fcb251@mail.gmail.com> <20080123192842.GA22477@caradoc.them.org> <8f2776cb0801231311o19c31781h8a4663c405bcd22b@mail.gmail.com> <479819E2.1030603@portugalmail.pt> <8f2776cb0801232227n64502d4akef4642b051e77772@mail.gmail.com> <4798871B.4080207@codesourcery.com> <20080124133844.GA15771@caradoc.them.org> <20080124214849.GF3979@adacore.com> <47992419.1070201@codesourcery.com> <20080125025555.GH3979@adacore.com> In-Reply-To: <20080125025555.GH3979@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00603.txt.bz2 Joel Brobecker wrote: >> /* The low two bits of the PC on the PA contain the privilege level. >> Some genius implementing a (non-GCC) compiler apparently decided >> this means that "addresses" in a text section therefore include a >> privilege level, and thus symbol tables should contain these bits. >> This seems like a bonehead thing to do--anyway, it seems to work >> for our purposes to just ignore those bits. */ > > I just love the comment :). I'm so happy I'm not the HP genius > in question :-). Seriously, I think we should be careful not to > add more sarcastic comments like this in the future, it's not > very serious nor very useful. That being said, I love sarcasm, > so I had a good laugh. What do they mean by `"addresses" in a text section'? The only thing that should have a privilege level (PL) is the PC (IAOQ) at runtime, and it should match the PL of the executing instruction. If you start talking about addresses, and symbol tables, you wander into the realm of function addresses and official procedure descriptors (OPD). On 32-bit hppa-linux-gnu the address of a function may point to the function or the official procedure descriptor (On 64-bit you always have an OPD). The OPD address has bit 2 set, and bit 1 is reserved (See pg 31 of the 32-bit SOM Runtime). The OPD is a struct { ELF32 ip; ELF32 gp}. If ( & 3) is true you have a function address, otherwise an OPD. To read the OPD you strip the bottom 2 bits, cast to a struct, and use ip and gp. Might the writer of the comment gotten confused? >> I guess that compiler would be HP's. If the symbols had the bits set, >> so could the line info. > > Right. That's why I mentioned the fact that part of my toolchain > was from GNU tools. > >> Do we still support HP's object format and debug info ? > > Not sure. HP's 32-bit HP-PARISC object format is SOM. Dave, binutils still has SOM support? We still generate some HP debug info, namely .PARISC.unwind sections, and AFAIK gdb uses them (readelf shows them correctly)? Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos@codesourcery.com (650) 331-3385 x716