Thanks. Any other questions?
Regards
Gang
On Wed, Apr 18, 2012 at 12:58 PM, Jian-Xin Lai <laij...@gmail.com> wrote:
> The comments should be moved from the middle of the expression.
>
> 2012/4/13 Gang Yu <yugang...@gmail.com>
>
>> Hi,
>>
>> Could a gatekeeper please help review the fix for bug783(
>> https://bugs.open64.net/show_bug.cgi?id=783)?
>>
>> This is a dwalf generation issue for x86_64 target, a joint work from
>> Qing Zhu and myself.
>>
>> a sample case:
>> int __vdso_clock_gettime(){
>> }
>>
>> with the following command:
>> opencc -fpic -m64 -O0 -g vclock_gettime.i -c -o vclock_gettime.o
>>
>> we get the relocation info for the vclock_gettime.o in .debug_frame
>> section:
>> Relocation section '.rela.debug_frame' at offset 0xb70 contains 2 entries:
>> Offset Info Type Sym. Value Sym. Name +
>> Addend
>> 000000000018 00070000000a R_X86_64_32 0000000000000000
>> .debug_frame + 0
>> 00000000001c 00010000000a R_X86_64_32 0000000000000000 .text + 0
>> relocation at offset 00000000001c is not expected, in the -fpic -m64 -g
>> environment, instead of R_X86_64_32, we should generate R_X86_64_64 or
>> R_X86_64_PC32
>>
>> Analysis:
>>
>> open64 handles specially for -fpic -g code, it uses a unified 4byte
>> upointer_size to represent the reference to the code in text in dwarf frame
>> sections no matter -m32 or -m64. So, in handling the relocations in
>> .debug_frame, we should always use PC-relative relocation instead of
>> absolute one like that in .eh_frame. Investigation shows we missed
>> ".debug_frame" in cgdwarf printing routines.
>>
>> Suggested patch:
>>
>> Index: osprey/be/cg/cgdwarf.cxx
>> ===================================================================
>> --- osprey/be/cg/cgdwarf.cxx (revision 3904)
>> +++ osprey/be/cg/cgdwarf.cxx (working copy)
>> @@ -3702,7 +3702,13 @@
>> // don't want to affect other sections, although they may also need
>> // to be updated under fPIC
>> bool gen_pic = ((Gen_PIC_Call_Shared || Gen_PIC_Shared) &&
>> - !strcmp (section_name, EH_FRAME_SECTNAME));
>> + // open64.net bug783.
>> + // Since ".debug_frame" also use PC relative
>> addressing
>> + // R_X86_64_PC32/R_386_PC32
>> + // in the relocating for symbols, we should not
>> miss them.
>> + // Otherwise, wrong relocation generated.
>> + (!strcmp (section_name, EH_FRAME_SECTNAME) ||
>> + !strcmp (section_name, DEBUG_FRAME_SECTNAME)));
>> #endif
>> switch (reloc_buffer[k].drd_type) {
>> case dwarf_drt_none:
>> Would a gatekeeper please help a review? thanks in advance.
>>
>>
>> Regards
>> Gang
>>
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Open64-devel mailing list
>> Open64-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>
>>
>
>
> --
> Regards,
> Lai Jian-Xin
>
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
