From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5019 invoked by alias); 26 Jun 2003 12:00:44 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 5008 invoked from network); 26 Jun 2003 12:00:44 -0000 Received: from unknown (HELO ns2.uk.superh.com) (193.128.105.170) by sources.redhat.com with SMTP; 26 Jun 2003 12:00:44 -0000 Received: from sh-uk-ex01.uk.w2k.superh.com (sh-uk-ex01 [192.168.16.17]) by ns2.uk.superh.com (8.11.6+Sun/8.11.6) with ESMTP id h5QBukb21747 for ; Thu, 26 Jun 2003 12:56:46 +0100 (BST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: Dummy Breakpoint Priority Date: Thu, 26 Jun 2003 12:00:00 -0000 Message-ID: <9FF3133289A7A84E81E2ED8F5E56B379604398@sh-uk-ex01.uk.w2k.superh.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Thomas,Stephen" To: Cc: "Bowers, Antony" , "McGoogan,Sean" X-SW-Source: 2003-06/txt/msg00483.txt.bz2 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 200= 1 (by Jiri Smid, titled 'Dummy Breakpoint Priority'). When a target function is called from the command line, a special dummy bre= akpoint is inserted at the program entry point. (We have CALL_DUMMY_LOCATIO= N defined as AT_ENTRY_POINT). Trouble is, when the program is statically li= nked, gdb has already placed an internal breakpoint at _start, of type bp_s= hlib_event. On return from the function, this causes bpstat_what() in break= point.c to return an action which causes gdb to carry on executing (what.ma= in_action =3D BPSTAT_WHAT_CHECK_SHLIBS). The reply to Jiri Smid's mail asked why solib-svr4.c was setting a bp on th= e 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 pro= blem 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.