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

Yao Qi yao@codesourcery.com
Sat Feb 16 04:50:00 GMT 2013


On 01/18/2013 11:12 PM, Jiong Wang wrote:
> this is because tilegx skip_prologue will invoke
> tilegx_analyze_prologue, which
> will prefetch 32*8 bytes.
>
> while for when the address is in plt stub,  you can see it near the
> eh_frame_hdr section
>
>     [14] .plt                         0000000000010a00 000a00 0000a0 28
> AX  0   0 64
>     ...
>     [16] .eh_frame_hdr     0000000000010ac0 000ac0 000024 00   A  0 0  4
>     [17] .eh_frame             0000000000010ae8 000ae8 0000b4 00   A 0   0  8
>
> the .eh_frame_hdr aligns to 4, there is a hole between .eh_frame_hdr and
> .eh_frame, and this
> will cause trouble for section_table_xfer_memory_partial.
>
> after fetch memory starting from 0x10ac0 to 0x10ae4, then the memaddr
> will be 0x10ae4 in section_table_xfer_memory_partial,
> while this function did not consider this hole situation, so goes to
> line 666, error occured.

Wang Jiong,

AFAICT, the root cause of this problem is GDB prefetches too much 
contents in one time that exceeds the boundary of a section.

At the beginning of tilegx_analyze_prologue, I notice this comment

   /* To cut down on round-trip overhead, we fetch multiple bundles
      at once.  These variables describe the range of memory we have
      prefetched.  */

Can't we fetch one bundle in one time?  Fetching multiple bundles causes 
this problem, so we have to disable it.

Even we still decide to use fetching multiple bundle in one time, we 
should take care of the boundary and existing code does this, see this 
comment,

	  /* Figure out how many bytes to fetch.  Don't span a page
	     boundary since that might cause an unnecessary memory
	     error.  */

Looks existing code takes care of not crossing the page boundary, 
similarly, we should also take care of not crossing the section 
boundary.  What do you think?

-- 
Yao (齐尧)



More information about the Gdb-patches mailing list