From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32493 invoked by alias); 27 Jun 2003 08:13:58 -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 32448 invoked from network); 27 Jun 2003 08:13:57 -0000 Received: from unknown (HELO ns2.uk.superh.com) (193.128.105.170) by sources.redhat.com with SMTP; 27 Jun 2003 08:13:57 -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 h5R89ub22087; Fri, 27 Jun 2003 09:09:56 +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: RE: Dummy Breakpoint Priority Date: Fri, 27 Jun 2003 09:24:00 -0000 Message-ID: <9FF3133289A7A84E81E2ED8F5E56B379604399@sh-uk-ex01.uk.w2k.superh.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Thomas,Stephen" To: "Andrew Cagney" Cc: , "Bowers, Antony" , "McGoogan,Sean" X-SW-Source: 2003-06/txt/msg00502.txt.bz2 Hi Andrew, In the version I'm using (V5.2.1), i386 used ON_STACK. I actually verified = (using gdb!) that x86 gdb really did set a bp of type bp_shlib_event at _st= art. But I just checked the latest sources, & can't find a setting anywhere for = call dummy location. So it looks like i386 uses the default, i.e. AT_ENTRY_= POINT (now set in gdbarch.c). Can you verify that the latest gdb doesn't su= ffer from the same problem? To reproduce, you need to call function in a st= atically linked program. Thanks, Steve Thomas SuperH (UK) Ltd. -----Original Message----- From: Andrew Cagney [mailto:ac131313@redhat.com]=20 Sent: 26 June 2003 18:47 To: Thomas,Stephen Cc: gdb@sources.redhat.com; Bowers, Antony; McGoogan,Sean Subject: Re: Dummy Breakpoint Priority > Hi, >=20 > I am currently porting gdb to the new SuperH SH5 architecture. I have=20 > just hit a problem, which sounds exactly the same as that reported on=20 > 31 Aug 2001 (by Jiri Smid, titled 'Dummy Breakpoint Priority'). >=20 > When a target function is called from the command line, a special=20 > dummy breakpoint is inserted at the program entry point. (We have=20 > CALL_DUMMY_LOCATION defined as AT_ENTRY_POINT). Trouble is, when the=20 > program is statically linked, gdb has already placed an internal=20 > breakpoint at _start, of type bp_shlib_event. On return from the=20 > function, this causes bpstat_what() in breakpoint.c to return an=20 > action which causes gdb to carry on executing (what.main_action =3D=20 > BPSTAT_WHAT_CHECK_SHLIBS). >=20 > The reply to Jiri Smid's mail asked why solib-svr4.c was setting a bp=20 > on the entry point. But it looks like this is the normal thing for gdb=20 > to do - I verified that x86 gdb does the same thing (it doesn't suffer=20 > from this problem though because it doesn't use AT_ENTRY_POINT). Are you sure that the i386 isn't using at 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... I'm puzzled to. Andrew