[PATCH] ppc64: Avoid copy relocs also in named rodata sections

Bill Schmidt wschmidt at linux.vnet.ibm.com
Thu Mar 13 12:03:00 PDT 2014


Hi Uli,

Yes, this LGTM.  Thanks for the fix!

Bill

On Thu, 2014-03-13 at 19:51 +0100, Ulrich Weigand wrote:
> 
> Hi Bill,
> 
> in r181723 you fixed LLVM to move initialized constants needing relocation
> to the .data.rel.ro section instead of .rodata, which is necessary to avoid
> invalid copy relocs:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130513/174260.html
> 
> 
> This is good as far as it goes, but due to checks like this:
> 
> +  if (DefaultSection != ReadOnlySection)
> +    return DefaultSection;
> 
> your patch only triggers if the constant resides in *the* main .rodata
> section.   However, constants may also reside in *named* .rodata.XXX
> sections, which need the same treatment (i.e. use .data.rel.ro.XXX
> instead).
> 
> The appended patch fixes this by applying the check on "Kind" *before*
> calling the default SelectSectionForGlobal routine, instead of checking on
> the section returned by the default routine.
> (See attached file: diff-llvm-ppc64-vtable-reloc)
> 
> This fixes a number of failing test cases on my system, where due to a
> LD_LIBRARY_PATH setting, the version of libstdc++.so found at run time is
> more recent than the version found by LLVM at compile time.  (This setup
> ought to work fine since the library is upwards compatible.  However, this
> fails with an ld.so error when there are copy relocs on FUNC symbols, which
> we get when vtable constants are placed in a named .rodata section ...)
> 
> Does this look OK?
> 
> 
> Mit freundlichen Gruessen / Best Regards
> 
> Ulrich Weigand
> 
> --
>   Dr. Ulrich Weigand | Phone: +49-7031/16-3727
>   STSM, GNU/Linux compilers and toolchain
>   IBM Deutschland Research & Development GmbH
>   Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
> Wittkopp
>   Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
> Stuttgart, HRB 243294




More information about the llvm-commits mailing list