[RFC] Is inside_entry_file useful and needed?

[Corinna Vinschen <vinschen at redhat dot com>]

Hi,

the reason I'm going to discuss the inside_entry_file() function is that
I had trouble with the asm-source.exp tests on both platforms I currently
care about, Cygwin and XStormy16, one native, one embedded target.

Both targets have the same failures in the asm-source.exp tests:

(gdb) FAIL: gdb.asm/asm-source.exp: bt ALL in foo2
(gdb) FAIL: gdb.asm/asm-source.exp: bt 2 in foo2
(gdb) FAIL: gdb.asm/asm-source.exp: bt 3 in foo3
(gdb) FAIL: gdb.asm/asm-source.exp: finish from foo3
(gdb) FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s
(gdb) FAIL: gdb.asm/asm-source.exp: info line
(gdb) FAIL: gdb.asm/asm-source.exp: next over foo3

After some debugging it turned out that the cause for these failures is
a misbehaving of the frame code due to the return value of inside_entry_file().

This function returns "true" for all functions implemented in asmsrc1.s
for obvious reasons - the assembler test is not linked with an actual
startup file like crt0.o.

Due to the return code of inside_entry_file(), get_prev_frame() misbehaves
in the first place.  It returns NULL prematurely, no chance left to
ask the target dependent code if a prev frame might exist.

The second place where it goes wrong is frame_chain_valid(), called from
legacy_get_prev_frame().  Here the same happens again, the inside_entry_file()
function is called before the target dependent code might express another
opinion about the validity of the frame chain.

In the case of XStorm16, everything's ok when removing the calls to
inside_entry_file().  Cygwin, on the other hand still is wrong. 5
out of these 7 error are still left on a Cygwin box.  Why?

Digging a bit more I found that once more inside_entry_file() was the
culprit.  This time in i386_frame_chain().  That function ends with:

  if (! inside_entry_file (get_frame_pc (frame)))
    return read_memory_unsigned_integer (get_frame_base (frame), 4);
  return 0;

which invariably fails to return the correct address in the above case.

For testing purposes I've changed the above three lines to just one:

  return read_memory_unsigned_integer (get_frame_base (frame), 4);

Now everythings ok for Cygwin as well.  With these three changes, both
targets behave fine and no regressions are introduced in the testsuite.


Q1: Is there actually a target which depends on the inside_entry_file()
    function?

Q2: If Q1 has to be answered with "yes", I'd like to propose the introduction
    of a predicate which can be set by the target code to disable the
    inside_entry_file() function as already noted in two comments in the
    gdb source code:

frame.c::get_prev_frame():

  /* If we're inside the entry file, it isn't valid.  Don't apply this
     test to a dummy frame - dummy frame PC's typically land in the
     entry file.  Don't apply this test to the sentinel frame.
     Sentinel frames should always be allowed to unwind.  */
  /* NOTE: drow/2002-12-25: should there be a way to disable this
     check?  It assumes a single small entry file, and the way some
     debug readers (e.g.  dbxread) figure out which object is the
     entry file is somewhat hokey.  */
  /* NOTE: cagney/2003-01-10: If there is a way of disabling this test
     then it should probably be moved to before the ->prev_p test,
     above.  */

blockframe.c::frame_chain_valid():

  /* If we're inside the entry file, it isn't valid.  */
  /* NOTE/drow 2002-12-25: should there be a way to disable this check?  It
     assumes a single small entry file, and the way some debug readers (e.g.
     dbxread) figure out which object is the entry file is somewhat hokey.  */


Thoughts?

Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen at redhat dot com