This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: New xxx_register gdb-arch function vs pseudo register


    Date: Thu, 24 Aug 2000 20:05:42 +1000
    From: Andrew Cagney <ac131313@cygnus.com>

    Stephane Carrez wrote:

    > 2/ Try to use the pseudo registers framework.
    >    The problem here is that the soft registers are not aliases to other
    >    registers (nor combination of them).  There are several places in GDB-core
    >    where we only take into account the NUM_REGS and not NUM_REGS+PSEUDO_REGS.

    > [...]

    >    Pros: No new multi-arch function, may be fix some PSEUDO_REGS support (not sure)
    >    Cons: More complex, may change the semantics of PSEUDO_REGS

    Could I encourage you to persue this alternative.    It isn't that I
    have something against extra multi-arch entries (ok I do but not in this
    case :-) but rather that the problem you're describing (registers living
    in memory space) is far more common than you might think.  Off hand, I
    can think of at least three targets that have an identical problem.  In
    those cases people ended up shoving hacks into either/and SIM and the
    target stub :-(.

For the processor I'm working on a port for, some of the registers are
banked, and the pc is actually generated by smashing together two
other registers and then modifying the result...  to keep things
simple, I ended up making NUM_REGS 0 -- all registers are PSEUDO_REGS
(some (e.g., fp and sp) more pseudo than others).

Now, I need to capture writes to memory -- all registers are memory
mapped (and there is no memory other than memory mapped registers), so
if you read/write memory, you're actually reading/writing a register...

    > 
    >    For example, the frame structure must handle the saved registers but
    >    it ignores the PSEUDO_REGS.  If I want to use the pseudo registers framework,
    >    it will not work because the soft registers can be saved on the stack.
    > 
    >    There are a few places like this which must be fixed.

    And it won't be easy - the more you look the more tricky it gets, the
    expression evaluator is involved.  If you want I can try some bad ascii
    art drawing out how I think it should work.

Yes, please.

	    Andrew

David

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]