[testsuite] What's the expected behaviour of dg-require-effective-target shared?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[testsuite] What's the expected behaviour of dg-require-effective-target shared?

Iain Sandoe-5
Hi Christophe,

we’ve been looking at some cases where Darwin tests fail or pass unexpectedly depending on
options.  It came as a surprise to see it failing a test for shared support (since it’s always
supported shared libs).

-----

It’s a long time ago, but in r216117 you added this to target-supports.

# Return 1 if -shared is supported, as in no warnings or errors
# emitted, 0 otherwise.

proc check_effective_target_shared { } {
 # Note that M68K has a multilib that supports -fpic but not
 # -fPIC, so we need to check both.  We test with a program that
 # requires GOT references.
 return [check_no_compiler_messages shared executable {
   extern int foo (void); extern int bar;
  int baz (void) { return foo () + bar; }
 } "-shared -fpic”
}

====

The thing is that this is testing two things:

1) if the target consumes -shared -fpic without warning

2) assuming that those cause a shared lib to be made it also tests that
the target will allow a link of that to complete with undefined symbols.

So Darwin *does* support  “-shared -fpic” and is very happy to make
shared libraries.  However, it doesn’t (by default) allow  undefined symbols
in the link.

So my question is really about the intent of the test:

  if the intent is to see if the target supports shared libs, then we should
  arrange for Darwin to pass - either by hardwiring it (since all Darwin
  versions do support shared) or by adding suitable options to suppress
  the error.

  if the intent is to check that the target supports linking a shared lib with
 undefined external symbols, then perhaps we need a different test for the
 “just supports shared libs”

===

(note, also the comment doesn’t match what’s actually done, but that’s prob
 a cut & pasto).

thanks
Iain




Reply | Threaded
Open this post in threaded view
|

Re: [testsuite] What's the expected behaviour of dg-require-effective-target shared?

David Edelsohn-2
On Fri, Jun 21, 2019 at 10:29 AM Iain Sandoe <[hidden email]> wrote:

>
> Hi Christophe,
>
> we’ve been looking at some cases where Darwin tests fail or pass unexpectedly depending on
> options.  It came as a surprise to see it failing a test for shared support (since it’s always
> supported shared libs).
>
> -----
>
> It’s a long time ago, but in r216117 you added this to target-supports.
>
> # Return 1 if -shared is supported, as in no warnings or errors
> # emitted, 0 otherwise.
>
> proc check_effective_target_shared { } {
>  # Note that M68K has a multilib that supports -fpic but not
>  # -fPIC, so we need to check both.  We test with a program that
>  # requires GOT references.
>  return [check_no_compiler_messages shared executable {
>    extern int foo (void); extern int bar;
>   int baz (void) { return foo () + bar; }
>  } "-shared -fpic”
> }
>
> ====
>
> The thing is that this is testing two things:
>
> 1) if the target consumes -shared -fpic without warning
>
> 2) assuming that those cause a shared lib to be made it also tests that
> the target will allow a link of that to complete with undefined symbols.
>
> So Darwin *does* support  “-shared -fpic” and is very happy to make
> shared libraries.  However, it doesn’t (by default) allow  undefined symbols
> in the link.

AIX similarly does not allow undefined symbols in a link by default.

>
> So my question is really about the intent of the test:
>
>   if the intent is to see if the target supports shared libs, then we should
>   arrange for Darwin to pass - either by hardwiring it (since all Darwin
>   versions do support shared) or by adding suitable options to suppress
>   the error.
>
>   if the intent is to check that the target supports linking a shared lib with
>  undefined external symbols, then perhaps we need a different test for the
>  “just supports shared libs”

Thanks, David
Reply | Threaded
Open this post in threaded view
|

Re: [testsuite] What's the expected behaviour of dg-require-effective-target shared?

Christophe Lyon-2
In reply to this post by Iain Sandoe-5
On Fri, 21 Jun 2019 at 16:28, Iain Sandoe <[hidden email]> wrote:

>
> Hi Christophe,
>
> we’ve been looking at some cases where Darwin tests fail or pass unexpectedly depending on
> options.  It came as a surprise to see it failing a test for shared support (since it’s always
> supported shared libs).
>
> -----
>
> It’s a long time ago, but in r216117 you added this to target-supports.
>
> # Return 1 if -shared is supported, as in no warnings or errors
> # emitted, 0 otherwise.
>
> proc check_effective_target_shared { } {
>  # Note that M68K has a multilib that supports -fpic but not
>  # -fPIC, so we need to check both.  We test with a program that
>  # requires GOT references.
>  return [check_no_compiler_messages shared executable {
>    extern int foo (void); extern int bar;
>   int baz (void) { return foo () + bar; }
>  } "-shared -fpic”
> }
>
> ====
>
> The thing is that this is testing two things:
>
> 1) if the target consumes -shared -fpic without warning
>
> 2) assuming that those cause a shared lib to be made it also tests that
> the target will allow a link of that to complete with undefined symbols.
>
> So Darwin *does* support  “-shared -fpic” and is very happy to make
> shared libraries.  However, it doesn’t (by default) allow  undefined symbols
> in the link.
>
> So my question is really about the intent of the test:
>
>   if the intent is to see if the target supports shared libs, then we should
>   arrange for Darwin to pass - either by hardwiring it (since all Darwin
>   versions do support shared) or by adding suitable options to suppress
>   the error.
>
>   if the intent is to check that the target supports linking a shared lib with
>  undefined external symbols, then perhaps we need a different test for the
>  “just supports shared libs”
>
> ===

The patch was posted in https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00596.html
so it's really a matter of testing whether shared libs are supported.

> (note, also the comment doesn’t match what’s actually done, but that’s prob
>  a cut & pasto).
Indeed.... looks like I cut & pasted too much from check_effective_target_fpic

Thanks,

Christophe

> thanks
> Iain
>
>
>
>