[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

Alex S  changed:

   What|Removed |Added

 CC||iwt...@gmail.com

--- Comment #22 from Alex S  ---
(In reply to Dimitry Andric from comment #20)

https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-init.c;h=3e72fa3013a6aaeda05fe61a0ae7af5d46640826;hb=HEAD#l58

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

--- Comment #21 from David Chisnall  ---
It's also worth noting that functions declared with this attribute can have
some complex interaction with threading.  If a process spawns a thread which
calls `dlopen` then all of the library's constructors will be called in that
thread.  At this point, it's not clear whether the run-time linker will even
have access to the arguments that you want.  It's also not clear what `envp`
should be (the current environment, or the environment from process creation
time?)

I believe glibc provides an `__arguments` variable, along the same lines as
`__environ`, which allows the process to get access to the arguments from
arbitrary points in the code.  Implementing something like this would probably
be the best solution for this use case.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

Dimitry Andric  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |Works As Intended

--- Comment #20 from Dimitry Andric  ---
Unfortunately, as you both point out, the exact signature of C constructors and
destructors is not explicitly documented.  However, glibc calls them without
any arguments, and ignores the return value:

https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/soinit.c;h=fe9935732b2dcc3d71b5c0f2e52c32efc642d160;hb=HEAD#l20

and all its test cases and examples use void func(void).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

--- Comment #19 from Mark Millard  ---
(In reply to dstaesse from comment #18)

You are welcome.

My guess is that this is outside POSIX completely and
is just ABI material for what you are doing.

In fact, looking around I found an ARM document
indicating an empty parameter list for its
.init_array context:

 Each translation unit provides a fragment of the constructor vector in an ELF
section called .init_array of type SHT_INIT_ARRAY (=0xE) and section flags
SHF_ALLOC + SHF_WRITE.

 Each element of the vector contains the address of a function of type extern
“C” void (* const)(void) that, when called, performs part or all of the global
object construction for the translation unit. Producers must treat .init_array
sections as if they were read-only.

( http://infocenter.arm.com/help/topic/com.arm.doc.ihi0041e/IHI0041E_cppabi.pdf
page 19 of 24.)

So, not portable across all ABIs that have .init_array .

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

--- Comment #16 from dstaesse  ---
Your comments make a lot of sense. I updated the library code to call the
functions in the .init_array and .fini_array, and it looks like this works for
our testcases.

This is probably the answer I was looking for.

Thanks a million!

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

--- Comment #15 from dstaesse  ---
Created attachment 188130
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=188130=edit
updated library code

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

--- Comment #14 from Mark Millard  ---
(In reply to Mark Millard from comment #13)

Beyond my "form" vs "from" typo and "erguments"
vs. "arguments" typo, I probably also should
have put the word "called" in quotes: the
__attribute__ ((constructor)) routines might end
up inlined in the proper sequence for all
I know.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

--- Comment #13 from Mark Millard  ---
(In reply to dstaesse from comment #10)

The materials that you have referenced
indicate that __attribute__ ((constructor))
gets no arguments. Details follow.

>From the materials you referenced:

QUOTE
The .preinit_array and .init_array sections must contain function pointers (NOT
code!) The prototype of these functions must be
void func(int argc,char** argv,char** envp)
__libc_csu_init execute them in the following order:
Function pointers in .preinit_array section
Functions marked as __attribute__ ((constructor)), via _init
Function pointers in .init_array section
END QUOTE

Note that __attribute__ ((constructor)) is not for the
*init_array usage, just for usage inside _init .

And from the elf-init.c that you listed:

#ifndef NO_INITFINI
  _init ();
#endif

has no arguments.

So, __attribute__ ((constructor)) routines are called
form a context not explicitly having the erguments
available.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

--- Comment #12 from dstaesse  ---
(In reply to Mark Millard from comment #11)

Interesting.

Doesn't the list of func_ptrs have the arguments here as well?

/usr/src/lib/csu/common/ignore_init.c:extern void (*__init_array_start[])(int,
char **, char **) __hidden;

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

--- Comment #11 from Mark Millard  ---
(In reply to dstaesse from comment #8)

(In reply to dstaesse from comment #8)

I took a quick grep for -r325700 (head):

# grep -r __init_array_start /usr/src/* | more
/usr/src/contrib/llvm/tools/lld/ELF/Writer.cpp:  Define("__init_array_start",
"__init_array_end", Out::InitArray);
/usr/src/contrib/binutils/ld/scripttempl/elf.sc:
${RELOCATING+${CREATE_SHLIB-PROVIDE_HIDDEN
(${USER_LABEL_PREFIX}__init_array_start = .);}}
/usr/src/contrib/binutils/ld/ChangeLog-2006:(__preinit_array_start,
__preinit_array_end, __init_array_start,
/usr/src/lib/csu/common/ignore_init.c:extern void (*__init_array_start[])(int,
char **, char **) __hidden;
/usr/src/lib/csu/common/ignore_init.c:  array_size = __init_array_end -
__init_array_start;
/usr/src/lib/csu/common/ignore_init.c:  fn = __init_array_start[n];
/usr/src/sys/conf/ldscript.amd64: PROVIDE_HIDDEN (__init_array_start = .);
/usr/src/sys/conf/ldscript.i386: PROVIDE_HIDDEN (__init_array_start = .);
/usr/src/sys/contrib/octeon-sdk/cvmx-shared-linux-o32.ld:  PROVIDE
(__init_array_start = .);
/usr/src/sys/contrib/octeon-sdk/cvmx-shared-linux.ld: PROVIDE_HIDDEN
(__init_array_start = .);
/usr/src/sys/contrib/octeon-sdk/cvmx-shared-linux-n32.ld: PROVIDE_HIDDEN
(__init_array_start = .);

Note the ldscript.* are limited to amd64 and i386 mentioning
__init_array_start explicitly.  The whole block of text:

  .preinit_array :
  {
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(.preinit_array))
PROVIDE_HIDDEN (__preinit_array_end = .);
  }
  .init_array :
  {
 PROVIDE_HIDDEN (__init_array_start = .);
 KEEP (*(SORT(.init_array.*)))
 KEEP (*(.init_array))
 PROVIDE_HIDDEN (__init_array_end = .);
  }
  .fini_array :
  {
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(.fini_array))
KEEP (*(SORT(.fini_array.*)))
PROVIDE_HIDDEN (__fini_array_end = .);
  }

seems to only to be for those two ldscript.*'s.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

--- Comment #10 from dstaesse  ---
(In reply to Mark Millard from comment #9)

Thanks a lot for taking time to help me out. I'm definitely no expert on this
matter. Our target is restricted to POSIX.

I've found mostly posts on stackoverflow, definitely nothing that's official
documentation. 
But this gave me some insights:
https://www.cs.stevens.edu/~jschauma/810/elf.html

Here is says that:

The .preinit_array and .init_array sections must contain function pointers (NOT
code!) The prototype of these functions must be

void func(int argc,char** argv,char** envp)

But this may be specific for x86_64.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

--- Comment #9 from Mark Millard  ---
(In reply to dstaesse from comment #7)

I did not manage to find anything that mentioned
the parameters/arguments: You found materials that
I did not. What context(s) were they from?

"portable way": what range of portability? Even having
shared libraries is likely not universal to all C/C++
contexts. Windows .DLL's have a different mechanism
if I remember right. And so on.

But even for a narrower Unix/BSD/Linux context: as far
as I know the conventions are just local/ABI conventions
and the compiler does not drive which conventions are
used: the environment does something to impose the
environment's desired rules.

[I'm no expert on POSIX rules so there might be material
from that direction that I'm not aware of.]

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

--- Comment #8 from dstaesse  ---
I agree that the documentation could be more specific about the nature of the
functions that can have this attribute.

It's true that most examples use functions without arguments but that could
just be because they are examples and keep things as simple as possible. Most
of the examples have a main() without arguments as well...

Of course it's glibc specific, but the elf-init.c seems to define the functions
that go into the pre_init array as having (int, char **, char **) arguments:

https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=csu/elf-init.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

--- Comment #7 from dstaesse  ---
(In reply to Mark Millard from comment #5)

Good point, we only tried amd64 and i386. 

This feature seems to be very sparsely documented, with some sources saying
everything but void func(void) is undefined behaviour and others stating that
it can have the same signature as the main() function. The GNU compiler
documentation doesn't give details and clang doesn't document it at all. I've
seen other projects use this, though.

The compiler doesn't seem to check the function signature at all, I've tried to
set the constructor attribute to functions with all sorts of parameters and
complaints.

If this is undefined behaviour, do you know of a portable way to access argv
from a shared library without passing it as a function parameter to some init
call?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

Mark Millard  changed:

   What|Removed |Added

 CC||mar...@dsl-only.net

--- Comment #5 from Mark Millard  ---
(In reply to dstaesse from comment #4)

What processor architectures have you tried
(in those contexts that allow a variety)?
powerpc64? powerpc? armv7? aaarch64? . . .

I expect that it will appear to work only for
some processor architectures: ABI differences
would likely matter.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

--- Comment #4 from dstaesse  ---
Are you 100% sure about that? Doesn't this attribute work with functions that
have a signature that is allowable for a main() function? I haven't heard any
compiler complain, and we tried combinations of GNU/Linux, OS X and FreeBSD
compiling with gcc or (Apple)clang. So far, it worked flawlessly except on
FreeBSD when compiling with clang.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

David Chisnall  changed:

   What|Removed |Added

 CC||thera...@freebsd.org

--- Comment #3 from David Chisnall  ---
This doesn't look like a bug.  `__attribute__((constructor))` is only defined
for functions that take no arguments (for gcc and clang).  I'm very surprised
if you don't get a compile-time warning.  If `argc`, `argv` and `envp` are
appearing as arguments, it's because, on some platforms / architectures these
happen to be the values in argument registers when the constructors are
invoked, but it's not intended behaviour.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

[Bug 223752] clang __attribute__((constructor)) gets wrong input parameters

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223752

Conrad Meyer  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-toolchain@FreeBSD.o
   ||rg
 CC||d...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"