No. This patch looks good to me except the comments.
2012/4/19 Gang Yu <yugang...@gmail.com>
> 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
>>
>
>
--
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
