Dummy Breakpoint Priority

Dummy Breakpoint Priority

[Thomas,Stephen]

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.

Re: Dummy Breakpoint Priority

[Andrew Cagney]

> 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).

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

RE: Dummy Breakpoint Priority

[Thomas,Stephen]

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 _start.

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 suffer from the same problem? To reproduce, you need to call function in a statically linked program.

Thanks,

Steve Thomas
SuperH (UK) Ltd.

-----Original Message-----
From: Andrew Cagney [mailto:ac131313@redhat.com] 
Sent: 26 June 2003 18:47
To: Thomas,Stephen
Cc: gdb@sources.redhat.com; Bowers, Antony; McGoogan,Sean
Subject: Re: 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).

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

dummy breakpoint priority

[Jiri Smid]

  Hello,

  I have a problem with using generic dummy frames
(call_dummy_location - AT_ENTRY_POINT) together with solib-svr4.c.
  At the entry point a breakpoint is created by solib-svr4.c and when
I call hand_function_call() another breakpoint is created at the same place.
  The priority of breakpoints (table in breakpoint.c:bpstat_what())
defines that the main action in this case is BPSTAT_WHAT_CHECK_SHLIBS.
  This leads to the result that execution continues and sigsegvs.
  Shouldn't the dummy breakpoint have higher priority?

-- 
Jiri Smid

---------------------------------------------------------------------
SuSE CR, s.r.o.                                 e-mail: smid@suse.cz
Drahobejlova 27                                tel:+420 2 83095 373
190 00 Praha 9                                 fax:+420 2 83095 374
Ceska republika                                http://www.suse.cz

Re: dummy breakpoint priority

[Kevin Buettner]

On Aug 31, 12:49pm, Jiri Smid wrote:

>   I have a problem with using generic dummy frames
> (call_dummy_location - AT_ENTRY_POINT) together with solib-svr4.c.
>   At the entry point a breakpoint is created by solib-svr4.c and when
> I call hand_function_call() another breakpoint is created at the same place.

Why is solib-svr4.c setting a breakpoint at the entry point?

(This sounds like a bug to me.)

>   The priority of breakpoints (table in breakpoint.c:bpstat_what())
> defines that the main action in this case is BPSTAT_WHAT_CHECK_SHLIBS.
>   This leads to the result that execution continues and sigsegvs.
>   Shouldn't the dummy breakpoint have higher priority?

Perhaps.  For your case, however, it seems to me though that you're
going to have other problems if you invert the priorities.  (I.e,
what happens if you're really at a shlib breakpoint?)

Kevin