* PR25882, .gnu.attributes are not checked for shared libraries @ 2020-05-01 5:54 Alan Modra 2020-05-01 22:23 ` Joseph Myers 0 siblings, 1 reply; 6+ messages in thread From: Alan Modra @ 2020-05-01 5:54 UTC (permalink / raw) To: binutils This allows backend merge_private_bfd_data to examine shared library e_flags and/or .gnu.attributes. ARM and PowerPC have done so when using ld.gold for a long time. (The tic6x change below is dead code due to the earlier FIXME, but this is probably one of the changes needed there.) PR 25882 bfd/ * elf32-tic6x.c (elf32_tic6x_merge_attributes): Don't transfer Tag_ABI_PIC or Tag_ABI_PID from dynamic objects to the output. ld/ * ldlang.c (lang_check): Call bfd_merge_private_bfd_data for shared libraries. diff --git a/bfd/elf32-tic6x.c b/bfd/elf32-tic6x.c index d07902fe8a..20e4324b09 100644 --- a/bfd/elf32-tic6x.c +++ b/bfd/elf32-tic6x.c @@ -3866,6 +3866,9 @@ elf32_tic6x_merge_attributes (bfd *ibfd, struct bfd_link_info *info) case Tag_ABI_PIC: case Tag_ABI_PID: + /* Don't transfer these tags from dynamic objects. */ + if ((ibfd->flags & DYNAMIC) != 0) + continue; if (out_attr[i].i > in_attr[i].i) out_attr[i].i = in_attr[i].i; break; diff --git a/ld/ldlang.c b/ld/ldlang.c index 2ef234f90b..b2cdb3603a 100644 --- a/ld/ldlang.c +++ b/ld/ldlang.c @@ -6938,11 +6938,12 @@ lang_check (void) bfd_printable_name (input_bfd), input_bfd, bfd_printable_name (link_info.output_bfd)); } - else if (bfd_count_sections (input_bfd)) - { - /* If the input bfd has no contents, it shouldn't set the - private data of the output bfd. */ + /* If the input bfd has no contents, it shouldn't set the + private data of the output bfd. */ + else if ((input_bfd->flags & DYNAMIC) != 0 + || bfd_count_sections (input_bfd) != 0) + { bfd_error_handler_type pfn = NULL; /* If we aren't supposed to warn about mismatched input -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR25882, .gnu.attributes are not checked for shared libraries 2020-05-01 5:54 PR25882, .gnu.attributes are not checked for shared libraries Alan Modra @ 2020-05-01 22:23 ` Joseph Myers 2020-05-01 23:48 ` H.J. Lu 0 siblings, 1 reply; 6+ messages in thread From: Joseph Myers @ 2020-05-01 22:23 UTC (permalink / raw) To: Alan Modra; +Cc: binutils, murphyp, tuliom This binutils patch breaks glibc "make check" for big-endian powerpc (32-bit and 64-bit). https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html Errors of the form: /scratch/jmyers/glibc-bot/install/compilers/powerpc64-linux-gnu/lib/gcc/powerpc64-glibc-linux-gnu/11.0.0/../../../../powerpc64-glibc-linux-gnu/bin/ld: /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/test-nldbl-redirect.o uses 64-bit long double, /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/libm.so.6 uses 128-bit long double I don't know whether this is a problem with binutils, or it indicates that BE powerpc glibc needs to use -mno-gnu-attribute on some files like LE does to avoid such errors. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR25882, .gnu.attributes are not checked for shared libraries 2020-05-01 22:23 ` Joseph Myers @ 2020-05-01 23:48 ` H.J. Lu 2020-05-02 3:28 ` Alan Modra 0 siblings, 1 reply; 6+ messages in thread From: H.J. Lu @ 2020-05-01 23:48 UTC (permalink / raw) To: Joseph Myers; +Cc: Alan Modra, Tulio Magno Quites Machado Filho, Binutils On Fri, May 1, 2020 at 4:22 PM Joseph Myers <joseph@codesourcery.com> wrote: > > This binutils patch breaks glibc "make check" for big-endian powerpc > (32-bit and 64-bit). > > https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html > > Errors of the form: > > /scratch/jmyers/glibc-bot/install/compilers/powerpc64-linux-gnu/lib/gcc/powerpc64-glibc-linux-gnu/11.0.0/../../../../powerpc64-glibc-linux-gnu/bin/ld: /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/test-nldbl-redirect.o uses 64-bit long double, /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/libm.so.6 uses 128-bit long double > > I don't know whether this is a problem with binutils, or it indicates that > BE powerpc glibc needs to use -mno-gnu-attribute on some files like LE > does to avoid such errors. It is odd to check .gnu.attributes on shared libraries since shared libraries used at link-time can be very different from run-time. Checking .gnu.attributes on shared libraries gives you very little. For PT_GNU_PROPERTY, .note.gnu.property section is ignored on shared libraries and shared library check is done at run-time. -- H.J. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR25882, .gnu.attributes are not checked for shared libraries 2020-05-01 23:48 ` H.J. Lu @ 2020-05-02 3:28 ` Alan Modra 2020-05-02 4:24 ` H.J. Lu 2020-05-22 4:06 ` Alan Modra 0 siblings, 2 replies; 6+ messages in thread From: Alan Modra @ 2020-05-02 3:28 UTC (permalink / raw) To: H.J. Lu; +Cc: Joseph Myers, Tulio Magno Quites Machado Filho, Binutils On Fri, May 01, 2020 at 04:48:38PM -0700, H.J. Lu wrote: > On Fri, May 1, 2020 at 4:22 PM Joseph Myers <joseph@codesourcery.com> wrote: > > > > This binutils patch breaks glibc "make check" for big-endian powerpc > > (32-bit and 64-bit). > > > > https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html > > > > Errors of the form: > > > > /scratch/jmyers/glibc-bot/install/compilers/powerpc64-linux-gnu/lib/gcc/powerpc64-glibc-linux-gnu/11.0.0/../../../../powerpc64-glibc-linux-gnu/bin/ld: /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/test-nldbl-redirect.o uses 64-bit long double, /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/libm.so.6 uses 128-bit long double Hmm, is the Tag_GNU_Power_ABI_FP claim of ibm long double strictly correct? Doesn't libm also support 64-bit long double too? In which case libm ought to be silent about long double support. That of course can be accomplished by compiling all the object files going into libm.so that provide long double functions (or call such functions) with -mno-gnu-attributes. Another method with slightly more finesse is to compile all files with the default -mgnu-attributes but link with --no-warn-mismatch. That way the linker will not give an error and also not emit the particular Tag with a conflict. (This method assumes that assembly files emit the correct tags.) > > I don't know whether this is a problem with binutils, or it indicates that > > BE powerpc glibc needs to use -mno-gnu-attribute on some files like LE > > does to avoid such errors. > > It is odd to check .gnu.attributes on shared libraries since shared libraries > used at link-time can be very different from run-time. You can say the same about many properties of shared libraries. ld.gold on both arm and powerpc does check these attributes for shared libraries. And it's necessary to use ld.gold to link split-stack and non-split-stack object files if you want to ensure the non-split-stack functions are called with something like the normal stack allocation. If you use ld.bfd then non-split-stack functions might be called with very small stacks. So arm and powerpc have a history of checking shared library .gnu.attributes. > Checking .gnu.attributes > on shared libraries gives you very little. Checking .gnu.attributes protects the user from linking against a shared library that say, provides ibm long double math function when the user is compiling for ieee long double. That was the idea behind the binutils patch. There are of course some negatives, chief of which is that .gnu.attributes is nowhere near fine enough grained to work well with libraries that provide multiple areas of support. You may hit a link error regarding functions you do not use in your app. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR25882, .gnu.attributes are not checked for shared libraries 2020-05-02 3:28 ` Alan Modra @ 2020-05-02 4:24 ` H.J. Lu 2020-05-22 4:06 ` Alan Modra 1 sibling, 0 replies; 6+ messages in thread From: H.J. Lu @ 2020-05-02 4:24 UTC (permalink / raw) To: Alan Modra; +Cc: Joseph Myers, Tulio Magno Quites Machado Filho, Binutils On Fri, May 1, 2020 at 8:28 PM Alan Modra <amodra@gmail.com> wrote: > > On Fri, May 01, 2020 at 04:48:38PM -0700, H.J. Lu wrote: > > On Fri, May 1, 2020 at 4:22 PM Joseph Myers <joseph@codesourcery.com> wrote: > > > > > > This binutils patch breaks glibc "make check" for big-endian powerpc > > > (32-bit and 64-bit). > > > > > > https://sourceware.org/pipermail/libc-testresults/2020q2/006097.html > > > > > > Errors of the form: > > > > > > /scratch/jmyers/glibc-bot/install/compilers/powerpc64-linux-gnu/lib/gcc/powerpc64-glibc-linux-gnu/11.0.0/../../../../powerpc64-glibc-linux-gnu/bin/ld: /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/test-nldbl-redirect.o uses 64-bit long double, /scratch/jmyers/glibc-bot/build/glibcs/powerpc64-linux-gnu/glibc/math/libm.so.6 uses 128-bit long double > > Hmm, is the Tag_GNU_Power_ABI_FP claim of ibm long double strictly > correct? Doesn't libm also support 64-bit long double too? In which > case libm ought to be silent about long double support. > > That of course can be accomplished by compiling all the object files > going into libm.so that provide long double functions (or call such > functions) with -mno-gnu-attributes. Another method with slightly > more finesse is to compile all files with the default -mgnu-attributes > but link with --no-warn-mismatch. That way the linker will not give > an error and also not emit the particular Tag with a conflict. (This > method assumes that assembly files emit the correct tags.) > > > > I don't know whether this is a problem with binutils, or it indicates that > > > BE powerpc glibc needs to use -mno-gnu-attribute on some files like LE > > > does to avoid such errors. > > > > It is odd to check .gnu.attributes on shared libraries since shared libraries > > used at link-time can be very different from run-time. > > You can say the same about many properties of shared libraries. > ld.gold on both arm and powerpc does check these attributes for shared > libraries. And it's necessary to use ld.gold to link split-stack and > non-split-stack object files if you want to ensure the non-split-stack > functions are called with something like the normal stack allocation. > If you use ld.bfd then non-split-stack functions might be called with > very small stacks. So arm and powerpc have a history of checking > shared library .gnu.attributes. > > > Checking .gnu.attributes > > on shared libraries gives you very little. > > Checking .gnu.attributes protects the user from linking against a > shared library that say, provides ibm long double math function when > the user is compiling for ieee long double. That was the idea behind > the binutils patch. There are of course some negatives, chief of > which is that .gnu.attributes is nowhere near fine enough grained to > work well with libraries that provide multiple areas of support. You > may hit a link error regarding functions you do not use in your app. > I don't think checking .gnu.attributes in shared libraries at link-time can protect shared libraries with different long double math functions at run-time. That is the main reason why I introduced .note.gnu.property section. -- H.J. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: PR25882, .gnu.attributes are not checked for shared libraries 2020-05-02 3:28 ` Alan Modra 2020-05-02 4:24 ` H.J. Lu @ 2020-05-22 4:06 ` Alan Modra 1 sibling, 0 replies; 6+ messages in thread From: Alan Modra @ 2020-05-22 4:06 UTC (permalink / raw) To: H.J. Lu; +Cc: Joseph Myers, Tulio Magno Quites Machado Filho, Binutils On Sat, May 02, 2020 at 12:58:00PM +0930, Alan Modra wrote: > Checking .gnu.attributes protects the user from linking against a > shared library that say, provides ibm long double math function when > the user is compiling for ieee long double. That was the idea behind > the binutils patch. There are of course some negatives, chief of > which is that .gnu.attributes is nowhere near fine enough grained to > work well with libraries that provide multiple areas of support. You > may hit a link error regarding functions you do not use in your app. I've been convinced we can't make a .gnu.attributes FP tag mismatch an error, due to the current glibc/libm advertising 128-bit IBM long double but in practice also supporting 64-bit long double via a compatibility archive. Linking those together should at most give a warning. PR 25882 bfd/ * elf32-ppc.c (_bfd_elf_ppc_merge_fp_attributes): Don't init FP attributes from shared libraries, and do not return an error if they don't match. gold/ * powerpc.cc (merge_object_attributes): Replace name param with obj param. Update callers. Don't init FP attributes from shared libraries, and do not emit an error if they don't match. diff --git a/bfd/elf32-ppc.c b/bfd/elf32-ppc.c index a900abe35e..d1c5e1b224 100644 --- a/bfd/elf32-ppc.c +++ b/bfd/elf32-ppc.c @@ -3557,6 +3557,17 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info) obj_attribute *in_attr, *in_attrs; obj_attribute *out_attr, *out_attrs; bfd_boolean ret = TRUE; + bfd_boolean warn_only; + + /* We only warn about shared library mismatches, because common + libraries advertise support for a particular long double variant + but actually support more than one variant. For example, glibc + typically supports 128-bit IBM long double in the shared library + but has a compatibility static archive for 64-bit long double. + The linker doesn't have the smarts to see that an app using + object files marked as 64-bit long double call the compatibility + layer objects and only from there call into the shared library. */ + warn_only = (ibfd->flags & DYNAMIC) != 0; in_attrs = elf_known_obj_attributes (ibfd)[OBJ_ATTR_GNU]; out_attrs = elf_known_obj_attributes (obfd)[OBJ_ATTR_GNU]; @@ -3574,9 +3585,12 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info) ; else if (out_fp == 0) { - out_attr->type = ATTR_TYPE_FLAG_INT_VAL; - out_attr->i ^= in_fp; - last_fp = ibfd; + if (!warn_only) + { + out_attr->type = ATTR_TYPE_FLAG_INT_VAL; + out_attr->i ^= in_fp; + last_fp = ibfd; + } } else if (out_fp != 2 && in_fp == 2) { @@ -3584,7 +3598,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info) /* xgettext:c-format */ (_("%pB uses hard float, %pB uses soft float"), last_fp, ibfd); - ret = FALSE; + ret = warn_only; } else if (out_fp == 2 && in_fp != 2) { @@ -3592,7 +3606,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info) /* xgettext:c-format */ (_("%pB uses hard float, %pB uses soft float"), ibfd, last_fp); - ret = FALSE; + ret = warn_only; } else if (out_fp == 1 && in_fp == 3) { @@ -3600,7 +3614,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info) /* xgettext:c-format */ (_("%pB uses double-precision hard float, " "%pB uses single-precision hard float"), last_fp, ibfd); - ret = FALSE; + ret = warn_only; } else if (out_fp == 3 && in_fp == 1) { @@ -3608,7 +3622,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info) /* xgettext:c-format */ (_("%pB uses double-precision hard float, " "%pB uses single-precision hard float"), ibfd, last_fp); - ret = FALSE; + ret = warn_only; } in_fp = in_attr->i & 0xc; @@ -3617,9 +3631,12 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info) ; else if (out_fp == 0) { - out_attr->type = ATTR_TYPE_FLAG_INT_VAL; - out_attr->i ^= in_fp; - last_ld = ibfd; + if (!warn_only) + { + out_attr->type = ATTR_TYPE_FLAG_INT_VAL; + out_attr->i ^= in_fp; + last_ld = ibfd; + } } else if (out_fp != 2 * 4 && in_fp == 2 * 4) { @@ -3627,7 +3644,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info) /* xgettext:c-format */ (_("%pB uses 64-bit long double, " "%pB uses 128-bit long double"), ibfd, last_ld); - ret = FALSE; + ret = warn_only; } else if (in_fp != 2 * 4 && out_fp == 2 * 4) { @@ -3635,7 +3652,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info) /* xgettext:c-format */ (_("%pB uses 64-bit long double, " "%pB uses 128-bit long double"), last_ld, ibfd); - ret = FALSE; + ret = warn_only; } else if (out_fp == 1 * 4 && in_fp == 3 * 4) { @@ -3643,7 +3660,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info) /* xgettext:c-format */ (_("%pB uses IBM long double, " "%pB uses IEEE long double"), last_ld, ibfd); - ret = FALSE; + ret = warn_only; } else if (out_fp == 3 * 4 && in_fp == 1 * 4) { @@ -3651,7 +3668,7 @@ _bfd_elf_ppc_merge_fp_attributes (bfd *ibfd, struct bfd_link_info *info) /* xgettext:c-format */ (_("%pB uses IBM long double, " "%pB uses IEEE long double"), ibfd, last_ld); - ret = FALSE; + ret = warn_only; } } diff --git a/gold/powerpc.cc b/gold/powerpc.cc index 2010c1e3d2..318c41744b 100644 --- a/gold/powerpc.cc +++ b/gold/powerpc.cc @@ -1204,7 +1204,7 @@ class Target_powerpc : public Sized_target<size, big_endian> // Merge object attributes from input object with those in the output. void - merge_object_attributes(const char*, const Attributes_section_data*); + merge_object_attributes(const Object*, const Attributes_section_data*); private: @@ -9481,7 +9481,7 @@ Target_powerpc<size, big_endian>::do_finalize_sections( Powerpc_relobj<size, big_endian>* ppc_relobj = static_cast<Powerpc_relobj<size, big_endian>*>(*p); if (ppc_relobj->attributes_section_data()) - this->merge_object_attributes(ppc_relobj->name().c_str(), + this->merge_object_attributes(ppc_relobj, ppc_relobj->attributes_section_data()); } for (Input_objects::Dynobj_iterator p = input_objects->dynobj_begin(); @@ -9491,7 +9491,7 @@ Target_powerpc<size, big_endian>::do_finalize_sections( Powerpc_dynobj<size, big_endian>* ppc_dynobj = static_cast<Powerpc_dynobj<size, big_endian>*>(*p); if (ppc_dynobj->attributes_section_data()) - this->merge_object_attributes(ppc_dynobj->name().c_str(), + this->merge_object_attributes(ppc_dynobj, ppc_dynobj->attributes_section_data()); } @@ -9514,7 +9514,7 @@ Target_powerpc<size, big_endian>::do_finalize_sections( template<int size, bool big_endian> void Target_powerpc<size, big_endian>::merge_object_attributes( - const char* name, + const Object* obj, const Attributes_section_data* pasd) { // Return if there is no attributes section data. @@ -9530,12 +9530,14 @@ Target_powerpc<size, big_endian>::merge_object_attributes( Object_attribute* out_attr = this->attributes_section_data_->known_attributes(vendor); + const char* name = obj->name().c_str(); const char* err; const char* first; const char* second; int tag = elfcpp::Tag_GNU_Power_ABI_FP; int in_fp = in_attr[tag].int_value() & 0xf; int out_fp = out_attr[tag].int_value() & 0xf; + bool warn_only = obj->is_dynamic(); if (in_fp != out_fp) { err = NULL; @@ -9543,10 +9545,13 @@ Target_powerpc<size, big_endian>::merge_object_attributes( ; else if ((out_fp & 3) == 0) { - out_fp |= in_fp & 3; - out_attr[tag].set_int_value(out_fp); - out_attr[tag].set_type(Object_attribute::ATTR_TYPE_FLAG_INT_VAL); - this->last_fp_ = name; + if (!warn_only) + { + out_fp |= in_fp & 3; + out_attr[tag].set_int_value(out_fp); + out_attr[tag].set_type(Object_attribute::ATTR_TYPE_FLAG_INT_VAL); + this->last_fp_ = name; + } } else if ((out_fp & 3) != 2 && (in_fp & 3) == 2) { @@ -9579,10 +9584,13 @@ Target_powerpc<size, big_endian>::merge_object_attributes( ; else if ((out_fp & 0xc) == 0) { - out_fp |= in_fp & 0xc; - out_attr[tag].set_int_value(out_fp); - out_attr[tag].set_type(Object_attribute::ATTR_TYPE_FLAG_INT_VAL); - this->last_ld_ = name; + if (!warn_only) + { + out_fp |= in_fp & 0xc; + out_attr[tag].set_int_value(out_fp); + out_attr[tag].set_type(Object_attribute::ATTR_TYPE_FLAG_INT_VAL); + this->last_ld_ = name; + } } else if ((out_fp & 0xc) != 2 * 4 && (in_fp & 0xc) == 2 * 4) { @@ -9612,10 +9620,16 @@ Target_powerpc<size, big_endian>::merge_object_attributes( if (err) { if (parameters->options().warn_mismatch()) - gold_error(_(err), first, second); + { + if (warn_only) + gold_warning(_(err), first, second); + else + gold_error(_(err), first, second); + } // Arrange for this attribute to be deleted. It's better to // say "don't know" about a file than to wrongly claim compliance. - out_attr[tag].set_type(0); + if (!warn_only) + out_attr[tag].set_type(0); } } -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-05-22 4:06 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-01 5:54 PR25882, .gnu.attributes are not checked for shared libraries Alan Modra 2020-05-01 22:23 ` Joseph Myers 2020-05-01 23:48 ` H.J. Lu 2020-05-02 3:28 ` Alan Modra 2020-05-02 4:24 ` H.J. Lu 2020-05-22 4:06 ` Alan Modra
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).