This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Dummy Breakpoint Priority
- From: "Thomas,Stephen" <stephen dot thomas at superh dot com>
- To: <gdb at sources dot redhat dot com>
- Cc: "Bowers, Antony" <antony dot bowers at superh dot com>, "McGoogan,Sean" <sean dot mcgoogan at superh dot com>
- Date: Thu, 26 Jun 2003 13:01:12 +0100
- Subject: Dummy Breakpoint Priority
Hi,
I am currently porting gdb to the new SuperH SH5 architecture. I have just hit a problem, which sounds exactly the same as that reported on 31 Aug 2001 (by Jiri Smid, titled 'Dummy Breakpoint Priority').
When a target function is called from the command line, a special dummy breakpoint is inserted at the program entry point. (We have CALL_DUMMY_LOCATION defined as AT_ENTRY_POINT). Trouble is, when the program is statically linked, gdb has already placed an internal breakpoint at _start, of type bp_shlib_event. On return from the function, this causes bpstat_what() in breakpoint.c to return an action which causes gdb to carry on executing (what.main_action = BPSTAT_WHAT_CHECK_SHLIBS).
The reply to Jiri Smid's mail asked why solib-svr4.c was setting a bp on the entry point. But it looks like this is the normal thing for gdb to do - I verified that x86 gdb does the same thing (it doesn't suffer from this problem though because it doesn't use AT_ENTRY_POINT).
So please can anyone tell me what the resolution of this problem was?
NB: Please reply using 'Reply All' as I am leaving SuperH shortly...
Thanks,
Steve Thomas
SuperH (UK) Ltd.