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
