This is the mail archive of the gdb-patches@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: [RFA] remote.c: adjust Z packet addr using BREAKPOINT_FROM_PC


>>>>> "Nick" == Nick Duffek <nsd@redhat.com> writes:

Nick> On 8-Jan-2001, J . T . Conklin wrote:
>> The GDB internals manual indicates that BREAKPOINT_FROM_PC() may
>> adjust the address.

Nick> Yes, and that's exactly why I want to move it: so that the target
Nick> architecture can adjust the address.
Nick>
Nick> (Specifically, I want to convert the address from a byte address
Nick> to an instruction space pointer.  This entails (a) removing the
Nick> IMEM_START bit added by the harvard architecture mechanism and
Nick> (b) dividing the address by 8.)

Ok, I'm really confused.

If BREAKPOINT_FROM_PC() is called to change GDB's internal notion of a
breakpoint address to the cannonical target representation, why is it
not used in every *_insert_breakpoint() and *_remove_breakpoint()
vector function?  It would seem to me that this transformation should
be done before the functions are called.

>> I think the reason that BREAKPOINT_FROM_PC() is called is to get the
>> size of the breakpoint.

Nick> That's all it does prior to my patch.  But elsewhere in GDB, namely in
Nick> mem-break.c, BREAKPOINT_FROM_PC serves as a generic way for target
Nick> architectures to modify the address and other attributes of a breakpoint
Nick> before it hits the hardware.

But is these types of changes appropriate when GDB does not know how
the target is going to implement the breakpoint?  

Nick> Maybe that's an argument for replacing target_insert_breakpoint() 
Nick> with a wrapper that calls BREAKPOINT_FROM_PC.

Just read this...  Yes, if address swizzling is necessary, I think it
should be done before the vector functions are called.  This may imply
that BREAKPOINT_FROM_PC() be broken into parts, since returning the 
bytes string containing a break/trap insn is not necesary at that level.

>> but it would seem that the debug agent could then install the break in
>> the wrong location.

Nick> I don't think that's a problem.  BREAKPOINT_FROM_PC doesn't
Nick> modify the address unless the target architecture author
Nick> explicitly causes it to do so, in which case it's presumably the
Nick> right thing to do.

BREAKPOINT_FROM_PC() is at the arch level.  A gdb for a given arch may
support several targets.  I'm still somewhat concerned that address
swizzling for one target may not be appropriate for another.  I'm
probably just being paranoid.  As long as it's only used to convert
GDB's address representation to that used by the architecture, it
might be safe to assume that all targets will need the same thing.

        --jtc

-- 
J.T. Conklin
RedBack Networks

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