Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro_alves@portugalmail.pt>
To: gdb-patches@sourceware.org
Subject: [PATCH] i386_skip_prologue.
Date: Sat, 09 Dec 2006 20:32:00 -0000	[thread overview]
Message-ID: <457B1D40.7060302@portugalmail.pt> (raw)
In-Reply-To: <20061118163738.GA14800@nevyn.them.org>

[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]

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  <pedro_alves@portugalmail.pt>

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


[-- Attachment #2: symtabprol.diff --]
[-- Type: text/plain, Size: 1226 bytes --]

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	other threads:[~2006-12-09 20:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <455EE79E.6000109@portugalmail.pt>
     [not found] ` <uveldatp9.fsf@gnu.org>
     [not found]   ` <455EF845.40902@portugalmail.pt>
     [not found]     ` <455F2754.5060703@portugalmail.pt>
     [not found]       ` <20061118163738.GA14800@nevyn.them.org>
2006-12-09 20:32         ` Pedro Alves [this message]
2006-12-30 20:48           ` Daniel Jacobowitz
2006-12-30 21:21             ` Mark Kettenis
2006-12-30 21:31               ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=457B1D40.7060302@portugalmail.pt \
    --to=pedro_alves@portugalmail.pt \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox