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