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
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
