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

Yao Qi
2013-02-16T04:50:58Z

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 (é½å°§)