From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17047 invoked by alias); 25 Jan 2008 18:50:47 -0000 Received: (qmail 17038 invoked by uid 22791); 25 Jan 2008 18:50:47 -0000 X-Spam-Check-By: sourceware.org Received: from hiauly1.hia.nrc.ca (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 25 Jan 2008 18:50:29 +0000 Received: from hiauly1.hia.nrc.ca (hiauly1.hia.nrc.ca [127.0.0.1] (may be forged)) by hiauly1.hia.nrc.ca (8.14.1/8.14.1) with ESMTP id m0PIncMM004360; Fri, 25 Jan 2008 13:49:44 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.14.1/8.14.1/Submit) id m0PIncQu004356; Fri, 25 Jan 2008 13:49:38 -0500 (EST) Message-Id: <200801251849.m0PIncQu004356@hiauly1.hia.nrc.ca> Subject: Re: arm_addr_bits_remove To: carlos@codesourcery.com (Carlos O'Donell) Date: Fri, 25 Jan 2008 21:24:00 -0000 From: "John David Anglin" Cc: brobecker@adacore.com, pedro@codesourcery.com, jimb@red-bean.com, gdb-patches@sourceware.org, dave.anglin@nrc.ca In-Reply-To: <47996465.6090201@codesourcery.com> from "Carlos O'Donell" at Jan 24, 2008 11:24:05 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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/msg00619.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'? Memory addresses are the same everywhere. In the PA 1.x architecture, there are four qudrants (i.e., the architecture is segmented) each which can address 4 GB of memory. In the hpux and linux runtimes, the addressing is restricted to 1 GB for efficiency. Linux has a flat addressess space (the upper four segment registers for a process are all equivalent). The segments in hpux aren't flat. As a result, calling stubs are more elaborate. The hardware has no concept of "text". Text may be placed anywhere in physical memory. HP-UX typically places text in one quadrant, data in another and shared text in another. Howver, code can execute from anywhere. The text quadrant in HP-UX is readonly. Code can read it and we do this for jump tables in GCC. You have to be aware that instructions can only execute from a four byte aligned location and mask the two least least significant bits when doing arithmetic involving the pc. Other than that, user code isn't really aware of the priority bits and the associated access restrictions. Regarding symbol tables, I would have to check what the two bits are used for. What struct/bits? > 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. > > HP's 32-bit HP-PARISC object format is SOM. > > Dave, binutils still has SOM support? Yes. > We still generate some HP debug info, namely .PARISC.unwind sections, > and AFAIK gdb uses them (readelf shows them correctly)? GCC uses the .stabs format. The .unwind sections are used by gdb, Ada and probably other code that has unwind support. Recent versions of GCC use dwarf2 unwind info in the data section for exception support. I posted a patch a year or so ago to add dwarf2 debug support but nobody commented on it. There is a bit of support that needs to be added to binutils that's not done yet. Other than the unwind sections, HP debug info is only useful for debugging applications compiled with HP tools. HP has provided wdb for years to do this. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)