Re: [PATCH]: Make Sparc Target Multi-Arch

[Michael Snyder <msnyder@cygnus.com>]

Peter.Schauer wrote:
> 
> > I've also included in this patch the ability to do call-dummies
> > using the AT_ENTRY_POINT method, rather than pushing instructions
> > onto the stack (since that isn't allowed in 64-bit Solaris).
> 
> Using AT_ENTRY_POINT will return bad results when calling a Sun cc compiled
> function that returns a struct from within GDB.
> 
> Sun cc generates code which checks the expected structure size against
> the passed structure size (in the extra word after the call) and does not
> copy to the result structure if the sizes don't match.
> Below is the disassembly of a function returning a structure with size 16.

Yuck!  Well, I can't use ON_STACK, because (a) the stack section
is protected against execution in Solaris/Sparc64, and (b) it's
too far from the text section for an ordinary jump/call.

What if I write the return struct size to the entry point address, 
following the trap instruction, and remove it when finished
(like the trap instruction)?
From ezannoni@cygnus.com Tue May 02 13:10:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: Jim Blandy <jimb@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH] in_prologue() fix
Date: Tue, 02 May 2000 13:10:00 -0000
Message-id: <14607.13887.744690.553862@kwikemart.cygnus.com>
References: <14598.9829.764888.505476@kwikemart.cygnus.com> <nphfcojymh.fsf@zwingli.cygnus.com> <14599.32044.511265.33190@kwikemart.cygnus.com>
X-SW-Source: 2000-05/msg00031.html
Content-length: 2507

Ok, just to follow up on this: after personal e-mail/phone exchanges
with Jim, we agreed on a different solution. So this patch is withdrawn.

Elena


Elena Zannoni writes:
 > Jim Blandy writes:
 >  > 
 >  > > It may be that the real fix is to make ecs->stop_func_start be the
 >  > > beginning of the function where the adjusted stop_pc is. However that
 >  > > would require several changes to H.I.E. But in any event in_prologue()
 >  > > is wrong for this particular case.
 >  > 
 >  > My first question is, if HIE can find enough symbolic information to
 >  > set ecs->stop_func_{name,start,end}, how come in_prologue can't find
 >  > it?
 >  > 
 > 
 > I am not sure I understand your question.  in_prologue finds the start
 > and end of the function within which pc is (in the same way HIE does for
 > the wrong pc). Because of the way in_prologue works, the info found is
 > not compared with the input function address. Doing this would be
 > another way to fix the problem, but you would have to rewrite
 > in_prologue. What I am trying to say is that in_prologue takes 2
 > inputs: a pc and a function start address. It has to determine if the
 > pc is within the prologue of the function starting at the address. In
 > this case it gets it wrong because it doesn't think about checking if pc
 > is within the function at all. 
 > 
 > 
 >  > In other words: your explanation implies that HIE has some way to find
 >  > the function extent, but happens to be wrong because of
 >  > DECR_PC_AFTER_BREAK lossage.  But in_prologue knows the correct PC;
 >  > why can't it use the same mechanism HIE used earlier to get the right
 >  > answer?
 >  > 
 > 
 > It does use the same mechanism (find_pc_partial_function) but it
 > doesn't check the results properly.
 > 
 >  > Also, aren't there other adverse consequences when
 >  > ecs->stop_func_{name,start,end} are wrong?  I think the HIE fix is the
 >  > right thing.  HIE is painful for me too, but otherwise, you'll just
 >  > get another CR in a month.
 >  > 
 > 
 > So I thought too. But in case of breakpoint being hit,
 > bpstat_stop_status() computes the stop_pc again, and corrects it. All
 > the info is printed correctly. I haven't looked at this in too much
 > detail though. I can add a FIXME to HIE to warn for the possibility of 
 > problems down the road. I have no time now to try to fix this.
 > 
 >  > If you've tested the change on SPARC and i386, it's okay with me.
 > 
 > I tested on sparc, I will test on linux.
 > 
 > Elena
 > 
From ezannoni@cygnus.com Tue May 02 13:20:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH] in_prologue() fix #2
Date: Tue, 02 May 2000 13:20:00 -0000
Message-id: <14607.14500.451080.510575@kwikemart.cygnus.com>
X-SW-Source: 2000-05/msg00032.html
Content-length: 4726

This patch supercedes the one in:
http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00456.html

This is a rewrite of in_prologue(). Jim is the real author of this
patch, I have tested it on d10v (solves the original problem),
solaris/sparc, linux/i386 w/ no regressions in the testsuite.

I'll check this in tomorrow, if there are no objections.
Elena

Tue May  2 13:17:21 2000  Elena Zannoni  (ezannoni@makita.cygnus.com)

        * symtab.c (in_prologue): From Jim Blandy. Rewrite, more
        intelligently, making sure we use the information from the 
        symbol tables fully.


Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.3
diff -u -p -r1.3 symtab.c
--- symtab.c    2000/04/04 02:08:52     1.3
+++ symtab.c    2000/05/02 20:15:12
@@ -4402,43 +4402,64 @@ in_prologue (pc, func_start)
   struct symtab_and_line sal;
   CORE_ADDR func_addr, func_end;
 
-  if (!find_pc_partial_function (pc, NULL, &func_addr, &func_end))
-    goto nosyms;               /* Might be in prologue */
+  /* We have several sources of information we can consult to figure
+     this out.
+     - Compilers usually emit line number info that marks the prologue
+       as its own "source line".  So the ending address of that "line"
+       is the end of the prologue.  If available, this is the most
+       reliable method.
+     - The minimal symbols and partial symbols, which can usually tell
+       us the starting and ending addresses of a function.
+     - If we know the function's start address, we can call the
+       architecture-defined SKIP_PROLOGUE function to analyze the
+       instruction stream and guess where the prologue ends.
+     - Our `func_start' argument; if non-zero, this is the caller's
+       best guess as to the function's entry point.  At the time of
+       this writing, handle_inferior_event doesn't get this right, so
+       it should be our last resort.  */
+
+  /* Consult the partial symbol table, to find which function
+     the PC is in.  */
+  if (! find_pc_partial_function (pc, NULL, &func_addr, &func_end))
+    {
+      CORE_ADDR prologue_end;
+
+      /* We don't even have minsym information, so fall back to using
+         func_start, if given.  */
+      if (! func_start)
+       return 1;               /* We *might* be in a prologue.  */
 
-  sal = find_pc_line (func_addr, 0);
-
-  if (sal.line == 0)
-    goto nosyms;
-
-  /* sal.end is the address of the first instruction past sal.line. */
-  if (sal.end > func_addr
-      && sal.end <= func_end)  /* Is prologue in function? */
-    return pc < sal.end;       /* Yes, is pc in prologue? */
-
-  /* The line after the prologue seems to be outside the function.  In this
-     case, tell the caller to find the prologue the hard way.  */
+      prologue_end = SKIP_PROLOGUE (func_start);
 
-  return 1;
+      return func_start <= pc && pc < prologue_end;
+    }
 
-/* Come here when symtabs don't contain line # info.  In this case, it is
-   likely that the user has stepped into a library function w/o symbols, or
-   is doing a stepi/nexti through code without symbols.  */
-
-nosyms:
-
-/* If func_start is zero (meaning unknown) then we don't know whether pc is
-   in the prologue or not.  I.E. it might be. */
-
-  if (!func_start)
-    return 1;
+  /* If we have line number information for the function, that's
+     usually pretty reliable.  */
+  sal = find_pc_line (func_addr, 0);
 
-/* We need to call the target-specific prologue skipping functions with the
-   function's start address because PC may be pointing at an instruction that
-   could be mistakenly considered part of the prologue.  */
+  /* Now sal describes the source line at the function's entry point,
+     which (by convention) is the prologue.  The end of that "line",
+     sal.end, is the end of the prologue.
+
+     Note that, for functions whose source code is all on a single
+     line, the line number information doesn't always end up this way.
+     So we must verify that our purported end-of-prologue address is
+     *within* the function, not at its start or end.  */
+  if (sal.line == 0
+      || sal.end <= func_addr
+      || func_end <= sal.end)
+    {
+      /* We don't have any good line number info, so use the minsym
+        information, together with the architecture-specific prologue
+        scanning code.  */
+      CORE_ADDR prologue_end = SKIP_PROLOGUE (func_addr);
 
-  func_start = SKIP_PROLOGUE (func_start);
+      return func_addr <= pc && pc < prologue_end;
+    }
 
-  return pc < func_start;
+  /* We have line number info, and it looks good.  */
+  return func_addr <= pc && pc < sal.end;
 }