From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Use insert_step_resume_breakpoint everywhere Date: Wed, 12 May 2004 20:47:00 -0000 Message-id: <40A28D7B.90007@gnu.org> References: <40A01953.7060906@gnu.org> <40A161F4.6050801@gnu.org> <200405122029.i4CKT0r4006056@elgar.kettenis.dyndns.org> X-SW-Source: 2004-05/msg00383.html This patch, or one of your other patches breaks FreeBSD signal trampoline handling. I now get: (Which exact FreeBSD) The value of step_frame_id indicates that we were stepping in handler, and then try to set a step-resume breakpoint in main. It might be relevant to note that on FreeBSD, the signal trampoline calls the handler, and that signal trampoline is provided by the kernel so we don't have debug info for it. If you stepi into the trampoline, does gdb know that its got a signal trampoline? When stepping, this code: if (step_range_end != 1 && (step_over_calls == STEP_OVER_UNDEBUGGABLE || step_over_calls == STEP_OVER_ALL) && get_frame_type (get_current_frame ()) == SIGTRAMP_FRAME) { /* The inferior, while doing a "step" or "next", has ended up in a signal trampoline (either by a signal being delivered or by the signal handler returning). Just single-step until the inferior leaves the trampoline (either by calling the handler or returning). */ keep_going (ecs); return; } should be triggering causing the inferior to single step which makes it setting a breakpoint in main most puzzling. Try moving the above to before: if (step_over_calls == STEP_OVER_UNDEBUGGABLE && ecs->stop_func_name == NULL) { /* There is no symbol, not even a minimal symbol, corresponding to the address where we just stopped. So we just stepped inside undebuggable code. Since we want to step over this kind of code, we keep going until the inferior returns from the current function. */ handle_step_into_function (ecs); return; } Andrew