[PATCH] i386_skip_prologue.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] i386_skip_prologue.

pedro_alves (Bugzilla)
Hi all,

(moving this from gdb@, also at http://sources.redhat.com/ml/gdb/2006-11/msg00140.html)

Daniel Jacobowitz escreveu:

> On Sat, Nov 18, 2006 at 03:31:32PM +0000, Pedro Alves wrote:
>>     .loc 1 15 0
>>     pushl     %ebp
>> LCFI0:
>>     movl $16, %eax
>>     movl %esp, %ebp
>> LCFI1:
>>     subl $8, %esp
>> LCFI2:
>>     .loc 1 15 0
>>     andl $-16, %esp
>>     call __alloca
>>     call ___main
>>     .loc 1 17 0
>
>> What do you think could be done to fix this?
>> Is it the .loc directives that are being output wrong? Or is it gdb's
>> prologue reader
>> (if there is such a thing) that is missing the fact that __main is not
>> user code?
>
> Probably both.  The second line number marker normally marks the end of
> the prologue, so GCC is wrong, and GDB might have to be taught about
> _alloca and __main.
>
The i386 targets currently don't look at line number markers
or the symbol table at all in i386_skip_prologue.

I used the attached patch to test the gcc side of the fix,
(http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00633.html)

With the gcc patch above applied, this patch fixes all the runto_main issues
on Cygwin. There are a few other FAILs related to breakpoints and main,
but those are testsuite bugs, unrelated to this. I will send patches for those shortly.

This are my current Cygwin/i386 results:

                === gdb Summary ===

# of expected passes 9897
# of unexpected failures 423
# of unexpected successes 1
# of expected failures 45
# of unknown successes 3
# of known failures 60
# of unresolved testcases 1
# of untested testcases 12
# of unsupported tests 26

(A lot of those seem to be signals related. I guess there are only a
couple of bugs producing all of those failures.)

Cheers,
Pedro Alves

---

2006-12-09  Pedro Alves  <[hidden email]>

         * i386-tdep.c (i386_skip_prologue): Try to find the end of the
         prologue using the symbol table.


Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.225
diff -u -p -r1.225 i386-tdep.c
--- i386-tdep.c 8 Aug 2006 21:36:46 -0000 1.225
+++ i386-tdep.c 9 Dec 2006 19:30:25 -0000
@@ -825,6 +825,29 @@ i386_skip_prologue (CORE_ADDR start_pc)
   CORE_ADDR pc;
   gdb_byte op;
   int i;
+  char *func_name;
+  CORE_ADDR func_addr, func_end = 0;
+
+  /* See what the symbol table says.  */
+
+  if (find_pc_partial_function (start_pc, &func_name, &func_addr, &func_end))
+    {
+      struct symbol *sym;
+      struct symtab_and_line sal;
+
+      /* Found a function.  */
+      sym = lookup_symbol (func_name, NULL, VAR_DOMAIN, NULL, NULL);
+      if (sym && SYMBOL_LANGUAGE (sym) != language_asm)
+        {
+          /* Don't use this trick for assembly source files.  */
+          sal = find_pc_line (func_addr, 0);
+          if ((sal.line != 0) && (sal.end < func_end))
+            return sal.end;
+        }
+    }
+
+  /* Can't find the prologue end in the symbol table, try it the hard way
+     by disassembling the instructions.  */
 
   cache.locals = -1;
   pc = i386_analyze_prologue (start_pc, 0xffffffff, &cache);
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] i386_skip_prologue.

Daniel Jacobowitz-2
On Sat, Dec 09, 2006 at 08:32:00PM +0000, Pedro Alves wrote:

> The i386 targets currently don't look at line number markers
> or the symbol table at all in i386_skip_prologue.
>
> I used the attached patch to test the gcc side of the fix,
> (http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00633.html)
>
> With the gcc patch above applied, this patch fixes all the runto_main issues
> on Cygwin. There are a few other FAILs related to breakpoints and main,
> but those are testsuite bugs, unrelated to this. I will send patches for
> those shortly.

As this is an i386-specific change, I'd been hoping Mark Kettenis could
take a look at it.  Mark, any opinion on this?

We've been going back and forth on prologue skipping choices for a long
time now.  We have at least four options, each with at least two users:

  - skip_prologue_using_sal
  - refine_prologue_limit
  - this simple approach using line numbers, i.e. what you did
  - sticking to analysis of the instructions

Aside from how difficult the analysis is, there's very little target
dependent about this.  It's a shame we've got so many different ways
to do it.

Is there a general philosophy we could adopt that would apply to most
or all targets?

Here's a proposal to get us started: when skipping the prologue to
place a breakpoint or finish single stepping (skip_prologue), try to
skip to the end of the first sal.  But some targets may optionally run
their prologue analyzer and make sure it doesn't see anything it
objects to - like jumps.  That would mean the i386 prologue analyzer
would need to know about this new call to __main.  When scanning the
prologue to build frame unwind information, ignore sals entirely.
Scan until we hit the saved PC or until we believe we understand
the entire frame.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] i386_skip_prologue.

Mark Kettenis
> Date: Sat, 30 Dec 2006 15:48:26 -0500
> From: Daniel Jacobowitz <[hidden email]>
>
> On Sat, Dec 09, 2006 at 08:32:00PM +0000, Pedro Alves wrote:
> > The i386 targets currently don't look at line number markers
> > or the symbol table at all in i386_skip_prologue.
> >
> > I used the attached patch to test the gcc side of the fix,
> > (http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00633.html)
> >
> > With the gcc patch above applied, this patch fixes all the runto_main issues
> > on Cygwin. There are a few other FAILs related to breakpoints and main,
> > but those are testsuite bugs, unrelated to this. I will send patches for
> > those shortly.
>
> As this is an i386-specific change, I'd been hoping Mark Kettenis could
> take a look at it.  Mark, any opinion on this?

I'm sorry.  I tend to suffer from packet loss at my side.

> We've been going back and forth on prologue skipping choices for a long
> time now.  We have at least four options, each with at least two users:
>
>   - skip_prologue_using_sal
>   - refine_prologue_limit
>   - this simple approach using line numbers, i.e. what you did
>   - sticking to analysis of the instructions
>
> Aside from how difficult the analysis is, there's very little target
> dependent about this.  It's a shame we've got so many different ways
> to do it.

Yes, that's my general feeling.  But last time I brought it up, we
didn't reach a real conclusion.

> Is there a general philosophy we could adopt that would apply to most
> or all targets?
>
> Here's a proposal to get us started: when skipping the prologue to
> place a breakpoint or finish single stepping (skip_prologue), try to
> skip to the end of the first sal.  But some targets may optionally run
> their prologue analyzer and make sure it doesn't see anything it
> objects to - like jumps.  That would mean the i386 prologue analyzer
> would need to know about this new call to __main.  When scanning the
> prologue to build frame unwind information, ignore sals entirely.
> Scan until we hit the saved PC or until we believe we understand
> the entire frame.

The last time I tried using sals on i386, I simply encountered too
many cases where the line number information couldn't be trusted and
putting a breakpoint on a function that was defenitely called never
hit.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] i386_skip_prologue.

Daniel Jacobowitz-2
On Sat, Dec 30, 2006 at 10:20:52PM +0100, Mark Kettenis wrote:
> I'm sorry.  I tend to suffer from packet loss at my side.

No problem - that's what I'm here for :-)

> > Is there a general philosophy we could adopt that would apply to most
> > or all targets?
> >
> > Here's a proposal to get us started: when skipping the prologue to
> > place a breakpoint or finish single stepping (skip_prologue), try to
> > skip to the end of the first sal.  But some targets may optionally run
> > their prologue analyzer and make sure it doesn't see anything it
> > objects to - like jumps.  That would mean the i386 prologue analyzer
> > would need to know about this new call to __main.  When scanning the
> > prologue to build frame unwind information, ignore sals entirely.
> > Scan until we hit the saved PC or until we believe we understand
> > the entire frame.
>
> The last time I tried using sals on i386, I simply encountered too
> many cases where the line number information couldn't be trusted and
> putting a breakpoint on a function that was defenitely called never
> hit.

Yeah.  That's definitely the biggest risk.

I think the first step, for Pedro's specific problem, should be
to recognize the call to __main as special and skippable.  We can
play with sals later.

--
Daniel Jacobowitz
CodeSourcery