break $function in coff/pe doesn't break exactly before the first statement?

[Pedro Alves]

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


Here is a quick list of which target does what:

I see that there are a lot of targets that have similar
code in their *_skip_prologue version.

Most use something like:

form1:

   if (find_pc_partial_function (pc, NULL, &func_addr, &func_end))
     {
       struct symtab_and_line sal;

       sal = find_pc_line (func_addr, 0);
       if (sal.line != 0 && sal.end < func_end)
	return sal.end;

       /* Either there's no line info, or the line after the prologue is after
	 the end of the function.  In this case, there probably isn't a
	 prologue.  */
       return pc;
     }

Some targets do the above and add a check for SYMBOL_LANGUAGE (sym) != language_asm:

check_asm:

       /* Don't use line number debug info for assembly source files. */
       if (sym && SYMBOL_LANGUAGE (sym) != language_asm)
	{
	  sal = find_pc_line (func_addr, 0);
	  if (sal.end && sal.end < func_end)
	    {
	      /* Found a line number, use it as end of prologue.  */
	      return sal.end;
	    }
	}

A few others use skip_prologue_using_sal,

Some others don't look at the line info at all,
and others need to tweak the algorithm a bit, not falling in the
previous groups so I called them other/other.

Makes me wonder what is the best method of skipping the prologue in the presence of
debug info, and if it worth it to clean all the targets by having a common function?

nothing:
	s390-tdep.c, spu-tdep.c, rs6000-tdep.c, m68k-tdep.c,
	ia64-tdep.c, i386-tdep.c, amd64-tdep.c

form1 (find_pc_line):
	sh64-tdep.c, sh-tdep.c, sparc64-tdep.c, sparc-tdep.c, v850-tdep.c,
	m32r-tdep.c, hppa-tdep.c, h8300-tdep.c, frv-tdep.c, cris-tdep.c

form2 (skip_prologue_using_sal):
	mips-tdep.c

check_asm:
	mt-tdep.c, arm-tdep.c,

other/extra:
	xtensa-tdep.c, xstormy-tdep.c, xstormy16-tdep.c, mn10300-tdep.c,
	m32c-tdep.c, alpha-tdep.c,

I'm posting a i386 only patch at gdb-patches for now.

Cheers,
Pedro Alves