From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32352 invoked by alias); 8 Feb 2008 18:06:55 -0000 Received: (qmail 32338 invoked by uid 22791); 8 Feb 2008 18:06:54 -0000 X-Spam-Check-By: sourceware.org Received: from fg-out-1718.google.com (HELO fg-out-1718.google.com) (72.14.220.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 08 Feb 2008 18:06:32 +0000 Received: by fg-out-1718.google.com with SMTP id e12so2902729fga.0 for ; Fri, 08 Feb 2008 10:06:28 -0800 (PST) Received: by 10.82.112.3 with SMTP id k3mr23574410buc.15.1202493988310; Fri, 08 Feb 2008 10:06:28 -0800 (PST) Received: by 10.82.165.12 with HTTP; Fri, 8 Feb 2008 10:06:28 -0800 (PST) Message-ID: <8f2776cb0802081006x17083484t3dac4c46b91648a2@mail.gmail.com> Date: Fri, 08 Feb 2008 18:06:00 -0000 From: "Jim Blandy" To: "Maciej W. Rozycki" Subject: Re: MIPS: Handle manual calls of MIPS16 functions with a call stub Cc: "Daniel Jacobowitz" , gdb-patches@sourceware.org, "Maciej W. Rozycki" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080131220315.GC5085@caradoc.them.org> <20080204163929.GA6642@caradoc.them.org> X-Google-Sender-Auth: 2d8f579cebf9ee17 X-IsSubscribed: yes 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-02/txt/msg00153.txt.bz2 On Feb 8, 2008 6:23 AM, Maciej W. Rozycki wrote: > On Mon, 4 Feb 2008, Daniel Jacobowitz wrote: > > > This is not how any other target that I know of handles extra PC bits. > > I think it's going to cause a whole lot of other similar problems. I > > am reluctant to add new hooks to support storing additional bits in > > addresses, when at the same time we have hooks that other targets use > > - called from overlapping places - to remove extra bits from addresses. > > Well, it is certainly the smallest change that fits the way the MIPS > target is currently handled throughout the toolchain. Not necessarily the > best. > > > Honestly, I'm not just trying to be difficult. But having two targets > > Of course -- I would not have doubted. I have been around for long > enough. > > > solve the same problem in opposite ways makes the core of GDB a mess. > > "Do line table entries include extra non-address bits" is not a > > question that should have different answers on different targets. > > Similarly for function block addresses. > > Your proposal sounds clean enough for me to investigate it further. In > fact I have done so to some extent already. > > > I think that using mips_pc_is_mips16 can be made to work, by analogy > > to ARM. I'd look at this myself, but I don't think I'm set up to run > > It is much more than that, but I think it can be done with some > adjustments to pointer_to_address(), address_to_pointer() and > integer_to_address() methods. If DWARF-2 records could be treated as > pointers (which they are given how the linker processes them) rather than > addresses then such a setup should work. That should be done above the > level of the DWARF-2 interpreter, as losing the LSB from relative data > often contained in records would result in an accumulative error. > > Of course further adjustments might be needed to methods like read_pc(), > write_pc() and unwind_pc() (I am not absolutely sure at this point yet) > and perhaps elsewhere. Just as a proof of concept, with some hacks to the > DWARF-2 parser and elsewhere, including but not limited to functions > mentioned, I got down to just three regressions compared to results with > my proposal. Now the question is whether a similar result may be achieved > using properly architected code. I'll have a look at it soon. > > > mips16 tests (yet). Should I be able to do this with just the GDB > > simulator and a board file? > > I have attached the "mips-sim-sde32" board description file I use and the > necessary linker script. You should be able to use it, though there may > be pitfalls. When running tests you need -Wa,-O0 to disable branch > swapping as it makes MIPS16 code inconsistent with DWARF-2 information in > a fatal way. > > > I don't understand. The stub is not annotated with debug information > > in the example you posted earlier in the thread. It's only "inside > > the block" physically in the assembly file and for the purposes of > > confusing gas (it probably puts the symbol and first instruction in > > different frags, the first of which is zero length, breaking whatever > > gas uses to annotate the symbol value). It's not covered by the range > > [.LFB20, .LEB20] because those labels are in the text section. > > It is still covered by the .loc directive and therefore recognised to be > a part of the code corresponding to the first line of the function. It > makes single-stepping through it possible -- including correct frame > discovery as required by `nexti'/`step'/`next' (not `stepi' though). > > Maciej