RE: Patch for GDB top of trunk

[Nat Gurumoorthy <nat dot gurumoorthy at ubicom dot com>]

Elena,
    The problem will occur in the following circumstances.
You have a file which has code in multiple sections. The code looks
as follows

--- Start Section1 ----
- Code from file1
- Code from file2
--- Function f1 ()
--- Function f2 ()
--- Function we are disassembling foo(). It is the last
function in file2 belonging to Section1
- Code from file 3 ----
--- End Section1 ----


---- Start Section2 ----
- Code from file1
- Code from file2
--- Function foofoo1() 
--- Function foofoo2()
- Code from file3
---- End Section2 ----

  "symtab->linetable" points to all the line table entries with
belong to a file. In our case the file of interest if file2.

mi-disas-cmds.c does the following

      /* Assume symtab is valid for whole PC range */
      symtab = find_pc_symtab (low);

      if (!symtab || !symtab->linetable)
	goto assembly_only;

      /* First, convert the linetable to a bunch of my_line_entry's.  */

      le = symtab->linetable->item;
      nlines = symtab->linetable->nitems;

The line table entry for the last line of the function foo() in file2
is immediately followed by the line table entry for the first line of
function foofoo1() of file2.

Now as the routine converts the "le" entries into "mles" (my_line_entries)
it will set the end_pc for the last line of function foo() to be the pc
of the first line of the function foofoo1(). Now you it looks as if the
last line of the funtion foo() streches from one section over to some
other section. If you do not properly clamp the end_pc, this for loop

	  for (pc = mle[i].start_pc; pc < mle[i].end_pc;)

will now run for a long time incorrectly disassembling code which does not
belong to the function foo(). Besides at some point "build_address_symbolic"
will notice the crossing of section boundary and cause an error exit
printing
some stuff like "Cannot access address xxxxxx".

An earlier call to find_pc_partial_function (start, NULL, &low, &high)
correctly sets "high" to an address which will be in section1. In my fix
I chose to call find_pc_line to figure out the end_pc when I detect that
end_pc is an address which is >= high. May be the proper thing to do is
to clamp end_pc to the lower of what comes back from find_pc_line and high.

Hope this long winded explanation makes sense.

I do not know if Ubicom has assignment on file. Is there any way could let
me know if I have to file the assignment.

Regards.
Nat


-----Original Message-----
From: Elena Zannoni [mailto:ezannoni@cygnus.com]
Sent: Monday, June 25, 2001 1:24 PM
To: Nat Gurumoorthy
Cc: 'gdb-patches@sourceware.cygnus.com'; Tibet Mimar
Subject: Re: Patch for GDB top of trunk



Nat, in theory, and for future reference, this patch should be split
into 3 separate ones, because it addresses 3 separate issues.

I agree with the mi-main.c patch, and the xfree patch, they can go in,
but I don't understand the other mi-cmd-disassemble patch.  Can you
provide some more details on the circumstances in which this occurs?

Also, do you have an assignment on file with the FSF?

Thanks
Elena

 > 	In mi-cmd-disas.c in the function "mi_cmd_disassemble"
 > there is for loop which converts le entries to mle entries. The
 > mle[i].end_pc is created by
 > mld[i].end_pc = le[i+1].pc. There will be cases where 
 > end_pc >= high and hence has to wrong address for the last line
 > of a function. We need to clamp by calling find_pc_line and letting
 > it figure out the end_pc for this line and copying it in place.
 >