Re: [RFC/TileGX 2/6] simplify the handling of skip prologue for plt stub

[Pedro Alves <palves at redhat dot com>]

On 02/21/2013 01:40 PM, Jiong Wang wrote:
> On 02/20/2013 12:10 PM, Yao Qi wrote:
>> Is it possible that the section layouts on two pages?  I mean, if is possible that NEXT_ADDR is within section FOO and page A, but the end of section FOO is within page A + 1.  If this is true, we need to check to the min (page boundary, section boundary), otherwise, we don't have to worry about it.
> 
>    sure, and I guess the page boundary check is for the risk that the next page is not in memory that need to be paged in.

No, it should be for the case of the next page not being mapped at all.  Like when straddling a segment.
Paging should be transparent to ptrace.

>    but some of the time, we just need to analyze a few instructions then we could get the result, so we only cross a page when necessary, but this do not make sense for disk file access.
> 
>    after a second think, I fell it's reasonable that "section_table_xfer_memory_partial" do not handle those gap between sections, because there is no bit on the disk file for those gap, while if the debuggee is loaded and under running, then target_read_memory will use ptrace to fetch runtime memory, then those gap has physical map in memory, and set to zero.
> 

Right.

>    for x86, this is a issue also. for a simple testcase
> 
> char *fmt = "x%d\n";
> int main(int argc, char **argv)
> {
>         printf(fmt, argc);
>         return 0;
> }
> 
> gcc test.c
> gdb a.out
> (gdb) x/10 fmt
> 0x4005c0 <__dso_handle+8>:    174335352    Cannot access memory at address 0x4005c4
> (gdb) b main
> Breakpoint 1 at 0x4004e0
> (gdb) r
> Starting program: /home/jiwang/GDB-TEST/a.out
> Breakpoint 1, 0x00000000004004e0 in main ()
> (gdb) x/10 fmt
> 0x4005c0 <__dso_handle+8>:    174335352    0    990059265 44
> 0x4005d0:    4    -552    72    -236
> 0x4005e0:    112    -184
> 
> so, I think fix this issue by checking section boundary simultaneously is a bit strange, the clean and proper way is to stop skip_prologue analysis when the pc is in plt stub.

I do agree that trying to find the end of the prologue of a plt stub is futile.  We know plt stubs
aren't "normal" functions, and don't have prologues.

But, I do think the prologue analyzer still has a problem.  You should see this
same issue with any small normal function (with no debug info) that happens to
end up close enough to the end of its section.

I suggest limiting the end address of the analysis with something like
in tilegx_skip_prologue

+ /* Don't straddle a section boundary.  */
+ s = find_pc_section (start_pc);
+ end_pc = start_pc + 8 * TILEGX_BUNDLE_SIZE_IN_BYTES;
+ if (s != NULL)
+   end_pc = min (end_pc, obj_section_endaddr (s));

  return tilegx_analyze_prologue (gdbarch,
				  start_pc,
-				  start_pc + 8 * TILEGX_BUNDLE_SIZE_IN_BYTES,
+				  end_pc,

and also, make tilegx_analyze_prologue never touch memory
over end_addr.  It doesn't seem to take that care currently?

-- 
Pedro Alves