PATCH: PR ld/12761: .gnu.warning.* doesn't work when building shared library

PATCH: PR ld/12761: .gnu.warning.* doesn't work when building shared library

[H.J. Lu]

Hi,

We should issure a gnu warning when building shared library.  This patch
implements it.  OK for trunk?

Thanks.


H.J.
---
bfd/

2011-05-16  H.J. Lu  <hongjiu.lu@intel.com>

	PR ld/12761
	* elflink.c (elf_link_add_object_symbols): Also generate warnings
	when building shared libraries.

ld/testsuite/

2011-05-16  H.J. Lu  <hongjiu.lu@intel.com>

	PR ld/12761
	* ld-elf/elf.exp: Compile tmpdir/warn3a.o and tmpdir/warn3b.o.

	* ld-elf/shared.exp (build_tests): Build libbarw.so with
	warn.c.  Add "Build beginwarn.o with PIC".

	* ld-elf/warn.c: New.
	* ld-elf/warn3.d: Likewise.
	* ld-elf/warn3a.c: Likewise.
	* ld-elf/warn3b.c: Likewise.

diff --git a/bfd/elflink.c b/bfd/elflink.c
index e4f728d..8d18ea8 100644
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -3423,7 +3423,7 @@ elf_link_add_object_symbols (bfd *abfd, struct bfd_link_info *info)
      .gnu.warning.SYMBOL are treated as warning symbols for the given
      symbol.  This differs from .gnu.warning sections, which generate
      warnings when they are included in an output file.  */
-  if (info->executable)
+  if (info->executable || info->shared)
     {
       asection *s;
 
diff --git a/ld/testsuite/ld-elf/elf.exp b/ld/testsuite/ld-elf/elf.exp
index b9ff0bd..2a8886d 100644
--- a/ld/testsuite/ld-elf/elf.exp
+++ b/ld/testsuite/ld-elf/elf.exp
@@ -40,6 +40,14 @@ if { [is_remote host] } then {
     remote_download host merge.ld
 }
 
+if ![ld_compile "$CC -fPIC" $srcdir/$subdir/warn3a.c tmpdir/warn3a.o] {
+    fail "warn3a.c with PIC"
+}
+
+if ![ld_compile "$CC -fPIC" $srcdir/$subdir/warn3b.c tmpdir/warn3b.o] {
+    fail "warn3b.c with PIC"
+}
+
 set test_list [lsort [glob -nocomplain $srcdir/$subdir/*.d]]
 foreach t $test_list {
     # We need to strip the ".d", but can leave the dirname.
diff --git a/ld/testsuite/ld-elf/shared.exp b/ld/testsuite/ld-elf/shared.exp
index d0c3478..2fc31c8 100644
--- a/ld/testsuite/ld-elf/shared.exp
+++ b/ld/testsuite/ld-elf/shared.exp
@@ -47,7 +47,10 @@ set build_tests {
    {begin.c end.c} {} "libbar.so"}
   {"Build warn libbar.so"
    "-shared" "-fPIC"
-   {beginwarn.c end.c} {} "libbarw.so"}
+   {warn.c} {} "libbarw.so"}
+  {"Build beginwarn.o with PIC"
+   "" "-fPIC"
+   {beginwarn.c} {} "libdummy.a"}
   {"Build hidden libbar.so"
    "-shared" "-fPIC"
    {begin.c endhidden.c} {} "libbarh.so"}
diff --git a/ld/testsuite/ld-elf/warn.c b/ld/testsuite/ld-elf/warn.c
new file mode 100644
index 0000000..8d01db2
--- /dev/null
+++ b/ld/testsuite/ld-elf/warn.c
@@ -0,0 +1,8 @@
+static const char _evoke_link_warning_foo []
+  __attribute__ ((used, section (".gnu.warning.foo")))
+    = "function foo is deprecated";
+
+void
+foo (void)
+{
+}
diff --git a/ld/testsuite/ld-elf/warn3.d b/ld/testsuite/ld-elf/warn3.d
new file mode 100644
index 0000000..65eb6e1
--- /dev/null
+++ b/ld/testsuite/ld-elf/warn3.d
@@ -0,0 +1,15 @@
+#source: empty.s
+#ld: -shared tmpdir/warn3a.o tmpdir/warn3b.o
+#warning: \A[^\n]*warn3a.o: In function `bar':\n[^\n]*warn3a.c:.* warning: function foo is deprecated\Z
+#readelf: -s
+#notarget: "sparc64-*-solaris2*" "sparcv9-*-solaris2*"
+#xfail: arc-*-* d30v-*-* dlx-*-* fr30-*-* frv-*-elf i860-*-* i960-*-*
+#xfail: iq*-*-* mn10200-*-* moxie-*-* msp*-*-* mt-*-* or32-*-* pj*-*-*
+# if not using elf32.em, you don't get fancy section handling
+
+# Check that warnings are generated for the symbols in .gnu.warning
+# construct and that the symbol still appears as expected.
+
+#...
+ +[0-9]+: +[0-9a-f]+ +[0-9]+ +FUNC +GLOBAL +DEFAULT +[1-9] foo
+#pass
diff --git a/ld/testsuite/ld-elf/warn3a.c b/ld/testsuite/ld-elf/warn3a.c
new file mode 100644
index 0000000..eae278d
--- /dev/null
+++ b/ld/testsuite/ld-elf/warn3a.c
@@ -0,0 +1,7 @@
+extern void foo (void);
+
+void
+bar (void)
+{
+  foo ();
+}
diff --git a/ld/testsuite/ld-elf/warn3b.c b/ld/testsuite/ld-elf/warn3b.c
new file mode 100644
index 0000000..ad82105
--- /dev/null
+++ b/ld/testsuite/ld-elf/warn3b.c
@@ -0,0 +1,5 @@
+static const char _evoke_link_warning_foo []
+  __attribute__ ((used, section (".gnu.warning.foo")))
+    = "function foo is deprecated";
+
+void foo (void) {} 

Re: PATCH: PR ld/12761: .gnu.warning.* doesn't work when building shared library

[Alan Modra]

On Mon, May 16, 2011 at 12:05:12PM -0700, H.J. Lu wrote:
> @@ -3423,7 +3423,7 @@ elf_link_add_object_symbols (bfd *abfd, struct bfd_link_info *info)
>       .gnu.warning.SYMBOL are treated as warning symbols for the given
>       symbol.  This differs from .gnu.warning sections, which generate
>       warnings when they are included in an output file.  */
> -  if (info->executable)
> +  if (info->executable || info->shared)
>      {
>        asection *s;
>  

Can one of the old-timers comment on this?  rev 1.1 of bfd/elflink.h
specifically excluded shared libs..

1.1          (rth      03-May-99):   if (! info->shared)

-- 
Alan Modra
Australia Development Lab, IBM

Re: PATCH: PR ld/12761: .gnu.warning.* doesn't work when building shared library

[Ian Lance Taylor]

"H.J. Lu" <hongjiu.lu@intel.com> writes:

> We should issure a gnu warning when building shared library.  This patch
> implements it.  OK for trunk?

No, this is not how warning symbols are supposed to work.  We only want
to issue the warning for a warning symbol if there is some reference to
the symbol in the main program.  If we issue the warnings for a shared
library, then we will wind up issuing the warnings even if the program
does not ever refer to the symbol.  That is undesirable and will almost
certainly break some uses of warning symbols.

I think it would be reasonable to issue a warning when building a shared
library for a reference to a symbol defined in some other shared
library, but it is necessary to not give a warning for references to
symbols defined in the library being created.

Ian

Re: PATCH: PR ld/12761: .gnu.warning.* doesn't work when building shared library

[H.J. Lu]

On Mon, May 16, 2011 at 11:03 PM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hongjiu.lu@intel.com> writes:
>
>> We should issure a gnu warning when building shared library.  This patch
>> implements it.  OK for trunk?
>
> No, this is not how warning symbols are supposed to work.  We only want
> to issue the warning for a warning symbol if there is some reference to
> the symbol in the main program.  If we issue the warnings for a shared
> library, then we will wind up issuing the warnings even if the program
> does not ever refer to the symbol.  That is undesirable and will almost
> certainly break some uses of warning symbols.

We aren't consistent:

1. Gold always issues a warning when building a shared library.
2. Ld sometimes issues a warning when building a shared library:

static void
gld${EMULATION_NAME}_before_allocation (void)
{
...
  /* Look for any sections named .gnu.warning.  As a GNU extensions,
     we treat such sections as containing warning messages.  We print
     out the warning message, and then zero out the section size so
     that it does not get copied into the output file.  */

My patch makes it consistent within ld as well as with gold.

> I think it would be reasonable to issue a warning when building a shared
> library for a reference to a symbol defined in some other shared
> library, but it is necessary to not give a warning for references to
> symbols defined in the library being created.
>

What is the difference between defined inside vs outside of DSO?
They both reference a function with a warning.

-- 
H.J.

Re: PATCH: PR ld/12761: .gnu.warning.* doesn't work when building shared library

[Ian Lance Taylor]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Mon, May 16, 2011 at 11:03 PM, Ian Lance Taylor <iant@google.com> wrote:
>> "H.J. Lu" <hongjiu.lu@intel.com> writes:
>>
>>> We should issure a gnu warning when building shared library.  This patch
>>> implements it.  OK for trunk?
>>
>> No, this is not how warning symbols are supposed to work.  We only want
>> to issue the warning for a warning symbol if there is some reference to
>> the symbol in the main program.  If we issue the warnings for a shared
>> library, then we will wind up issuing the warnings even if the program
>> does not ever refer to the symbol.  That is undesirable and will almost
>> certainly break some uses of warning symbols.
>
> We aren't consistent:
>
> 1. Gold always issues a warning when building a shared library.
> 2. Ld sometimes issues a warning when building a shared library:

Hmmm, that's interesting.  Sounds like an oversight on my part, but
perhaps it doesn't matter.


>> I think it would be reasonable to issue a warning when building a shared
>> library for a reference to a symbol defined in some other shared
>> library, but it is necessary to not give a warning for references to
>> symbols defined in the library being created.
>>
>
> What is the difference between defined inside vs outside of DSO?
> They both reference a function with a warning.

The difference is that the author of a shared library can call a
function with a warning safely from another externally visible function
which does not require a warning.

But I'm willing to let other people decide this issue.

Ian

Re: PATCH: PR ld/12761: .gnu.warning.* doesn't work when building shared library

[H.J. Lu]

On Tue, May 17, 2011 at 7:30 AM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> On Mon, May 16, 2011 at 11:03 PM, Ian Lance Taylor <iant@google.com> wrote:
>>> "H.J. Lu" <hongjiu.lu@intel.com> writes:
>>>
>>>> We should issure a gnu warning when building shared library.  This patch
>>>> implements it.  OK for trunk?
>>>
>>> No, this is not how warning symbols are supposed to work.  We only want
>>> to issue the warning for a warning symbol if there is some reference to
>>> the symbol in the main program.  If we issue the warnings for a shared
>>> library, then we will wind up issuing the warnings even if the program
>>> does not ever refer to the symbol.  That is undesirable and will almost
>>> certainly break some uses of warning symbols.
>>
>> We aren't consistent:
>>
>> 1. Gold always issues a warning when building a shared library.
>> 2. Ld sometimes issues a warning when building a shared library:
>
> Hmmm, that's interesting.  Sounds like an oversight on my part, but
> perhaps it doesn't matter.
>
>
>>> I think it would be reasonable to issue a warning when building a shared
>>> library for a reference to a symbol defined in some other shared
>>> library, but it is necessary to not give a warning for references to
>>> symbols defined in the library being created.
>>>
>>
>> What is the difference between defined inside vs outside of DSO?
>> They both reference a function with a warning.
>
> The difference is that the author of a shared library can call a
> function with a warning safely from another externally visible function
> which does not require a warning.
>

How does linker know warning is from the author of a shared library.
A shared library may contain many 3rd party objects.

-- 
H.J.

Re: PATCH: PR ld/12761: .gnu.warning.* doesn't work when building shared library

[Ian Lance Taylor]

"H.J. Lu" <hjl.tools@gmail.com> writes:

>> The difference is that the author of a shared library can call a
>> function with a warning safely from another externally visible function
>> which does not require a warning.
>>
>
> How does linker know warning is from the author of a shared library.
> A shared library may contain many 3rd party objects.

Sure, but it's hardly the common case.

Ian

Re: PATCH: PR ld/12761: .gnu.warning.* doesn't work when building shared library

[H.J. Lu]

On Tue, May 17, 2011 at 8:02 AM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>>> The difference is that the author of a shared library can call a
>>> function with a warning safely from another externally visible function
>>> which does not require a warning.
>>>
>>
>> How does linker know warning is from the author of a shared library.
>> A shared library may contain many 3rd party objects.
>
> Sure, but it's hardly the common case.
>

3rd party may be a team member or the warning may be written
by the same author many years ago.


-- 
H.J.

Re: PATCH: PR ld/12761: .gnu.warning.* doesn't work when building shared library

[Ian Lance Taylor]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> On Tue, May 17, 2011 at 8:02 AM, Ian Lance Taylor <iant@google.com> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>>>> The difference is that the author of a shared library can call a
>>>> function with a warning safely from another externally visible function
>>>> which does not require a warning.
>>>>
>>>
>>> How does linker know warning is from the author of a shared library.
>>> A shared library may contain many 3rd party objects.
>>
>> Sure, but it's hardly the common case.
>>
>
> 3rd party may be a team member or the warning may be written
> by the same author many years ago.

Sure, but it's hardly the common case.

Ian