'info registers' only when hit a breakpoint

'info registers' only when hit a breakpoint

[Kevin Hilman]

I'm working on a target implementation for a new chip our company is
developing.  The current hardware implementation only saves register
state (for 'info registers') in the frame in which a breakpoint was
hit.  The other frames only have minimal information (for function
args, local variables etc.)

Therefore, I want 'info registers' to not work if someone tries an
'up' for example.

Looking at registers_info(), it looks like I want to set
'target_has_registers' to zero.  I'm wondering where is the best place
to implement this feature.  It doesn't seem like modifying
up_command() is the right place since I'd have to keep track of how
many times someone has done up/down.

Any ideas?

NOTE: I'm currently working with gdb 4.17.

-- 
Kevin Hilman               ---  Equator Technologies Inc.
khilman@equator.com        ---  Seattle, WA USA

Re: 'info registers' only when hit a breakpoint

[J.T. Conklin]

>>>>> "Kevin" == Kevin Hilman <khilman@equator.com> writes:
Kevin> I'm working on a target implementation for a new chip our company is
Kevin> developing.  The current hardware implementation only saves register
Kevin> state (for 'info registers') in the frame in which a breakpoint was
Kevin> hit.  The other frames only have minimal information (for function
Kevin> args, local variables etc.)
Kevin>
Kevin> Therefore, I want 'info registers' to not work if someone tries
Kevin> an 'up' for example.

'info registers' displays the current values of the registers.  The
output does not change when you change the frame with frame/up/down.
I guess I'm not sure I understand what you want/need.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From kettenis@wins.uva.nl Fri Jun 09 17:19:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: kevinb@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Comments on U_REGS_OFFSET and fetch_register...
Date: Fri, 09 Jun 2000 17:19:00 -0000
Message-id: <200006100019.e5A0JdW03755@delius.kettenis.local>
References: <1000609192235.ZM24244@ocotillo.lan>
X-SW-Source: 2000-06/msg00070.html
Content-length: 643

Kevin,

I'm pretty sure no other system takes the braind^H^H^H^H^H^Hclever
approach to threads as Linux does.  It's clear that a system that
chooses any other approach won't be using ptrace for
thread-specific things.  HP-UX has ttrace, SVR4 has /proc, Mach-based
systems have a number of thread_ calls (IMHO a very clean interface,
where you can do almost anything to a process given the right
priviliges).

I wouldn't bother trying to get this "right" at this moment.  We'll
have to bit the bullet of getting rid of all the PID munging in the
near future.  Changing the code you outlined in your message will come
up naturally then.

Mark