ld and R_386_GOTOFF relocs

ld and R_386_GOTOFF relocs

[Peter S. Mazinger]

Hello!

I have gotten under peculiar circumstances following:
(sysvinit) init.o: relocation R_386_GOTOFF against protected function 
`main' can not be used when making a shared object

libc.so does not provide a weak 'main', main() is in crt1.o defined in asm 
as '.protected main'.

init is built as -pie executable.

I think this check is valid if a shared lib is created, but not valid for 
a PIE executable.

I think, that a check info->shared should be changed to
info->shared && !info->pie (or !info->executable), to allow pie to be 
linked, but I can't locate the one needed for this.

Thanks, Peter

Please CC to me

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: ld and R_386_GOTOFF relocs

[H. J. Lu]

On Thu, May 12, 2005 at 12:48:46AM +0200, Peter S. Mazinger wrote:
> Hello!
> 
> I have gotten under peculiar circumstances following:
> (sysvinit) init.o: relocation R_386_GOTOFF against protected function 
> `main' can not be used when making a shared object
> 
> libc.so does not provide a weak 'main', main() is in crt1.o defined in asm 
> as '.protected main'.
> 
> init is built as -pie executable.
> 
> I think this check is valid if a shared lib is created, but not valid for 
> a PIE executable.
> 
> I think, that a check info->shared should be changed to
> info->shared && !info->pie (or !info->executable), to allow pie to be 
> linked, but I can't locate the one needed for this.
> 
> Thanks, Peter

This is a gcc bug

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520


H.J.

Re: ld and R_386_GOTOFF relocs

[Peter S. Mazinger]

On Wed, 11 May 2005, H. J. Lu wrote:

> On Thu, May 12, 2005 at 12:48:46AM +0200, Peter S. Mazinger wrote:
> > Hello!
> > 
> > I have gotten under peculiar circumstances following:
> > (sysvinit) init.o: relocation R_386_GOTOFF against protected function 
> > `main' can not be used when making a shared object
> > 
> > libc.so does not provide a weak 'main', main() is in crt1.o defined in asm 
> > as '.protected main'.
> > 
> > init is built as -pie executable.
> > 
> > I think this check is valid if a shared lib is created, but not valid for 
> > a PIE executable.
> > 
> > I think, that a check info->shared should be changed to
> > info->shared && !info->pie (or !info->executable), to allow pie to be 
> > linked, but I can't locate the one needed for this.
> > 
> > Thanks, Peter
> 
> This is a gcc bug
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520

Reading through this, I came to the patch you posted on 2005-02-06 for 
elf32-i386.c. The comment says: 

+2005-02-06  H.J. Lu  <hongjiu.lu@intel.com>
+
+	* elf32-i386.c (elf_i386_relocate_section): Disallow R_386_GOTOFF
+	against protected function when building shared library.

If you intented to do this only for shared libraries, but not for PIE 
executables, then info->shared is incorrect, and as I proposed has to be 
changed.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: ld and R_386_GOTOFF relocs

[H. J. Lu]

On Thu, May 12, 2005 at 08:13:27AM +0200, Peter S. Mazinger wrote:
> On Wed, 11 May 2005, H. J. Lu wrote:
> 
> > On Thu, May 12, 2005 at 12:48:46AM +0200, Peter S. Mazinger wrote:
> > > Hello!
> > > 
> > > I have gotten under peculiar circumstances following:
> > > (sysvinit) init.o: relocation R_386_GOTOFF against protected function 
> > > `main' can not be used when making a shared object
> > > 
> > > libc.so does not provide a weak 'main', main() is in crt1.o defined in asm 
> > > as '.protected main'.
> > > 
> > > init is built as -pie executable.
> > > 
> > > I think this check is valid if a shared lib is created, but not valid for 
> > > a PIE executable.
> > > 
> > > I think, that a check info->shared should be changed to
> > > info->shared && !info->pie (or !info->executable), to allow pie to be 
> > > linked, but I can't locate the one needed for this.
> > > 
> > > Thanks, Peter
> > 
> > This is a gcc bug
> > 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
> 
> Reading through this, I came to the patch you posted on 2005-02-06 for 
> elf32-i386.c. The comment says: 
> 
> +2005-02-06  H.J. Lu  <hongjiu.lu@intel.com>
> +
> +	* elf32-i386.c (elf_i386_relocate_section): Disallow R_386_GOTOFF
> +	against protected function when building shared library.
> 
> If you intented to do this only for shared libraries, but not for PIE 
> executables, then info->shared is incorrect, and as I proposed has to be 
> changed.
> 

I checked in the following patch.

FYI, using protected function in executable has no benefit since
noone can override function in executable anyway.


H.J.
----
2005-05-12  H.J. Lu  <hongjiu.lu@intel.com>

	* elf32-i386.c (elf_i386_relocate_section): Allow R_386_GOTOFF
	against protected function when building executable.

--- bfd/elf32-i386.c.pie	2005-05-12 10:00:49.000000000 -0700
+++ bfd/elf32-i386.c	2005-05-12 13:55:04.000000000 -0700
@@ -2390,6 +2390,7 @@ elf_i386_relocate_section (bfd *output_b
 	     for shared library since it may not be local when used
 	     as function address.  */
 	  if (info->shared
+	      && !info->executable
 	      && h
 	      && h->def_regular
 	      && h->type == STT_FUNC

Re: ld and R_386_GOTOFF relocs

[Peter S. Mazinger]

On Thu, 12 May 2005, H. J. Lu wrote:

> On Thu, May 12, 2005 at 08:13:27AM +0200, Peter S. Mazinger wrote:
> > On Wed, 11 May 2005, H. J. Lu wrote:
> > 
> > > On Thu, May 12, 2005 at 12:48:46AM +0200, Peter S. Mazinger wrote:
> > > > Hello!
> > > > 
> > > > I have gotten under peculiar circumstances following:
> > > > (sysvinit) init.o: relocation R_386_GOTOFF against protected function 
> > > > `main' can not be used when making a shared object
> > > > 
> > > > libc.so does not provide a weak 'main', main() is in crt1.o defined in asm 
> > > > as '.protected main'.
> > > > 
> > > > init is built as -pie executable.
> > > > 
> > > > I think this check is valid if a shared lib is created, but not valid for 
> > > > a PIE executable.
> > > > 
> > > > I think, that a check info->shared should be changed to
> > > > info->shared && !info->pie (or !info->executable), to allow pie to be 
> > > > linked, but I can't locate the one needed for this.
> > > > 
> > > > Thanks, Peter
> > > 
> > > This is a gcc bug
> > > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
> > 
> > Reading through this, I came to the patch you posted on 2005-02-06 for 
> > elf32-i386.c. The comment says: 
> > 
> > +2005-02-06  H.J. Lu  <hongjiu.lu@intel.com>
> > +
> > +	* elf32-i386.c (elf_i386_relocate_section): Disallow R_386_GOTOFF
> > +	against protected function when building shared library.
> > 
> > If you intented to do this only for shared libraries, but not for PIE 
> > executables, then info->shared is incorrect, and as I proposed has to be 
> > changed.
> > 
> 
> I checked in the following patch.

Thanks, your patched solved it.

Peter

> 
> FYI, using protected function in executable has no benefit since
> noone can override function in executable anyway.
> 
> 
> H.J.
> ----
> 2005-05-12  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* elf32-i386.c (elf_i386_relocate_section): Allow R_386_GOTOFF
> 	against protected function when building executable.
> 
> --- bfd/elf32-i386.c.pie	2005-05-12 10:00:49.000000000 -0700
> +++ bfd/elf32-i386.c	2005-05-12 13:55:04.000000000 -0700
> @@ -2390,6 +2390,7 @@ elf_i386_relocate_section (bfd *output_b
>  	     for shared library since it may not be local when used
>  	     as function address.  */
>  	  if (info->shared
> +	      && !info->executable
>  	      && h
>  	      && h->def_regular
>  	      && h->type == STT_FUNC
> 
> 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

is main() provided by a library valid C ?

[Peter S. Mazinger]

Hello!

Is it valid C to have main() been provided by a library instead of an 
object at link time?

2 apps (bind and subversion) fail their tests, because the object 
providing main() is packed into an archive or is provided by a shared 
library and the library is used at link time instead of the object.

The failure at link time:
ld: protected symbol 'main' isn't defined
ld: final link failed: Nonrepresentable section on output

If I modify the Makefile to use the object instead of the library then 
linking succeeds.

The circumstances:
The weak definition of main() is moved from libc.so to crt1.o written in 
asm as '.protected main'.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: is main() provided by a library valid C ?

[Daniel Jacobowitz]

On Fri, May 13, 2005 at 09:47:01AM +0200, Peter S. Mazinger wrote:
> The circumstances:
> The weak definition of main() is moved from libc.so to crt1.o written in 
> asm as '.protected main'.

Why?

You certainly can't declare main as a protected symbol if it lives in a
library.  I don't see why you want it to be a protected symbol, either.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: is main() provided by a library valid C ?

[Peter S. Mazinger]

On Fri, 13 May 2005, Daniel Jacobowitz wrote:

> On Fri, May 13, 2005 at 09:47:01AM +0200, Peter S. Mazinger wrote:
> > The circumstances:
> > The weak definition of main() is moved from libc.so to crt1.o written in 
> > asm as '.protected main'.
> 
> Why?
> 
> You certainly can't declare main as a protected symbol if it lives in a
> library.  I don't see why you want it to be a protected symbol, either.

I wasn't clear enough.
libc does not define anything about main (not even as weak:
glibc/uclibc/dietlibc). It is obvious that it can't be defined as 
protected in a library. To remove any weak declaration of main from libc, 
one solution was to put it into crt1.o. This change (although .protected) 
does not fail on most of the apps, but fails 2 tests (subversion and 
bind), because those tests "deliver" main() from a library.

My question is:
Is it valid to provide main() from a library or not? If it is valid, then 
the solution to do '.protected main' in crt1.S is not ok and/or linker 
fails. If it is not valid, then the apps themselves should be corrected.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: is main() provided by a library valid C ?

[Daniel Jacobowitz]

On Wed, May 18, 2005 at 09:34:53PM +0200, Peter S. Mazinger wrote:
> On Fri, 13 May 2005, Daniel Jacobowitz wrote:
> 
> > On Fri, May 13, 2005 at 09:47:01AM +0200, Peter S. Mazinger wrote:
> > > The circumstances:
> > > The weak definition of main() is moved from libc.so to crt1.o written in 
> > > asm as '.protected main'.
> > 
> > Why?
> > 
> > You certainly can't declare main as a protected symbol if it lives in a
> > library.  I don't see why you want it to be a protected symbol, either.
> 
> I wasn't clear enough.
> libc does not define anything about main (not even as weak:
> glibc/uclibc/dietlibc). It is obvious that it can't be defined as 
> protected in a library. To remove any weak declaration of main from libc, 
> one solution was to put it into crt1.o. This change (although .protected) 
> does not fail on most of the apps, but fails 2 tests (subversion and 
> bind), because those tests "deliver" main() from a library.
> 
> My question is:
> Is it valid to provide main() from a library or not? If it is valid, then 
> the solution to do '.protected main' in crt1.S is not ok and/or linker 
> fails. If it is not valid, then the apps themselves should be corrected.

No, my question above is my response to this, which is what I figured
you were doing.  You haven't explained why you're making this change.
What is the problem with a weak reference from libc?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: is main() provided by a library valid C ?

[Peter S. Mazinger]

On Wed, 18 May 2005, Daniel Jacobowitz wrote:

> On Wed, May 18, 2005 at 09:34:53PM +0200, Peter S. Mazinger wrote:
> > On Fri, 13 May 2005, Daniel Jacobowitz wrote:
> > 
> > > On Fri, May 13, 2005 at 09:47:01AM +0200, Peter S. Mazinger wrote:
> > > > The circumstances:
> > > > The weak definition of main() is moved from libc.so to crt1.o written in 
> > > > asm as '.protected main'.
> > > 
> > > Why?
> > > 
> > > You certainly can't declare main as a protected symbol if it lives in a
> > > library.  I don't see why you want it to be a protected symbol, either.
> > 
> > I wasn't clear enough.
> > libc does not define anything about main (not even as weak:
> > glibc/uclibc/dietlibc). It is obvious that it can't be defined as 
> > protected in a library. To remove any weak declaration of main from libc, 
> > one solution was to put it into crt1.o. This change (although .protected) 
> > does not fail on most of the apps, but fails 2 tests (subversion and 
> > bind), because those tests "deliver" main() from a library.
> > 
> > My question is:
> > Is it valid to provide main() from a library or not? If it is valid, then 
> > the solution to do '.protected main' in crt1.S is not ok and/or linker 
> > fails. If it is not valid, then the apps themselves should be corrected.
> 
> No, my question above is my response to this, which is what I figured
> you were doing.  You haven't explained why you're making this change.
> What is the problem with a weak reference from libc?

the change would be "good to have", to be able to build libc w/ -z defs, 
that weak is "disturbing" this ;)

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: is main() provided by a library valid C ?

[Daniel Jacobowitz]

On Wed, May 18, 2005 at 10:23:24PM +0200, Peter S. Mazinger wrote:
> On Wed, 18 May 2005, Daniel Jacobowitz wrote:
> 
> > On Wed, May 18, 2005 at 09:34:53PM +0200, Peter S. Mazinger wrote:
> > > On Fri, 13 May 2005, Daniel Jacobowitz wrote:
> > > 
> > > > On Fri, May 13, 2005 at 09:47:01AM +0200, Peter S. Mazinger wrote:
> > > > > The circumstances:
> > > > > The weak definition of main() is moved from libc.so to crt1.o written in 
> > > > > asm as '.protected main'.
> > > > 
> > > > Why?
> > > > 
> > > > You certainly can't declare main as a protected symbol if it lives in a
> > > > library.  I don't see why you want it to be a protected symbol, either.
> > > 
> > > I wasn't clear enough.
> > > libc does not define anything about main (not even as weak:
> > > glibc/uclibc/dietlibc). It is obvious that it can't be defined as 
> > > protected in a library. To remove any weak declaration of main from libc, 
> > > one solution was to put it into crt1.o. This change (although .protected) 
> > > does not fail on most of the apps, but fails 2 tests (subversion and 
> > > bind), because those tests "deliver" main() from a library.
> > > 
> > > My question is:
> > > Is it valid to provide main() from a library or not? If it is valid, then 
> > > the solution to do '.protected main' in crt1.S is not ok and/or linker 
> > > fails. If it is not valid, then the apps themselves should be corrected.
> > 
> > No, my question above is my response to this, which is what I figured
> > you were doing.  You haven't explained why you're making this change.
> > What is the problem with a weak reference from libc?
> 
> the change would be "good to have", to be able to build libc w/ -z defs, 
> that weak is "disturbing" this ;)

Then how about doing it the same way glibc does, by a non-protected
reference?

You're going to a lot of effort to do something invalid, for a cosmetic
benefit.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: is main() provided by a library valid C ?

[Joakim Tjernlund]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org]
> On Wed, May 18, 2005 at 10:23:24PM +0200, Peter S. Mazinger wrote:
> > On Wed, 18 May 2005, Daniel Jacobowitz wrote:
> > 
> > > On Wed, May 18, 2005 at 09:34:53PM +0200, Peter S. Mazinger wrote:
> > > > On Fri, 13 May 2005, Daniel Jacobowitz wrote:
> > > > 
> > > > > On Fri, May 13, 2005 at 09:47:01AM +0200, Peter S. Mazinger wrote:
> > > > > > The circumstances:
> > > > > > The weak definition of main() is moved from libc.so to crt1.o written in 
> > > > > > asm as '.protected main'.
> > > > > 
> > > > > Why?
> > > > > 
> > > > > You certainly can't declare main as a protected symbol if it lives in a
> > > > > library.  I don't see why you want it to be a protected symbol, either.
> > > > 
> > > > I wasn't clear enough.
> > > > libc does not define anything about main (not even as weak:
> > > > glibc/uclibc/dietlibc). It is obvious that it can't be defined as 
> > > > protected in a library. To remove any weak declaration of main from libc, 
> > > > one solution was to put it into crt1.o. This change (although .protected) 
> > > > does not fail on most of the apps, but fails 2 tests (subversion and 
> > > > bind), because those tests "deliver" main() from a library.
> > > > 
> > > > My question is:
> > > > Is it valid to provide main() from a library or not? If it is valid, then 
> > > > the solution to do '.protected main' in crt1.S is not ok and/or linker 
> > > > fails. If it is not valid, then the apps themselves should be corrected.
> > > 
> > > No, my question above is my response to this, which is what I figured
> > > you were doing.  You haven't explained why you're making this change.
> > > What is the problem with a weak reference from libc?
> > 
> > the change would be "good to have", to be able to build libc w/ -z defs, 
> > that weak is "disturbing" this ;)
> 
> Then how about doing it the same way glibc does, by a non-protected
> reference?
> 
> You're going to a lot of effort to do something invalid, for a cosmetic
> benefit.

If my memory serves me right, to build libc w/ -z defs, main needs to be declared
weak in libc. Doing so introduces another problem, compiling an app that has no main
does NOT fail with an error message about missing main function. To solve that,
main was declared .protected in crtX.S but that led to the problem Peter mentioned
above.

Is the above problem solved in glibc and, if so, how?

 Jocke

Re: is main() provided by a library valid C ?

[Daniel Jacobowitz]

On Thu, May 19, 2005 at 10:40:07PM +0200, Joakim Tjernlund wrote:
> If my memory serves me right, to build libc w/ -z defs, main needs to be declared
> weak in libc.

Incorrect.  Libc doesn't need to mention main at all.  Please look at
glibc's CRT files.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: is main() provided by a library valid C ?

[Joakim Tjernlund]

> 
> On Thu, May 19, 2005 at 10:40:07PM +0200, Joakim Tjernlund wrote:
> > If my memory serves me right, to build libc w/ -z defs, main needs to be declared
> > weak in libc.
> 
> Incorrect.  Libc doesn't need to mention main at all.  Please look at
> glibc's CRT files.

Ahh, now I understand why you pass main as argument from start.S to libc, right?
Is this the only reason you do that or is there more to it?

While we are at the at it, I don't understand the alignment code in start.S for i386
This code:
/* Before pushing the arguments align the stack to a 16-byte
        (SSE needs 16-byte alignment) boundary to avoid penalties from
        misaligned accesses.  Thanks to Edward Seidl <seidl@janed.com>
        for pointing this out.  */
        andl $0xfffffff0, %esp

Aligns the stack to 16-byte, then the code below does 8 pushl at which point the
stack is 16-byte aligned again and finally a call to __libc_start_main. The call to 
__libc_start_main will add 4 bytes to the stack ptr and now the stack isn't 16-byte
aligned when __libc_start_main starts to execute. Is this the way it is supposed to work?

        pushl %eax                /* Push garbage because we allocate
                                   28 more bytes.  */

        /* Provide the highest stack address to the user code (for stacks
           which grow downwards).  */
        pushl %esp

        pushl %edx                /* Push address of the shared library
                                   termination function.  */

#ifdef SHARED
        /* Load PIC register.  */
        call 1f
        addl $_GLOBAL_OFFSET_TABLE_, %ebx

        /* Push address of our own entry points to .fini and .init.  */
        leal __libc_csu_fini@GOTOFF(%ebx), %eax
        pushl %eax
        leal __libc_csu_init@GOTOFF(%ebx), %eax
        pushl %eax

        pushl %ecx                /* Push second argument: argv.  */
        pushl %esi                /* Push first argument: argc.  */

        pushl BP_SYM (main)@GOT(%ebx)

        /* Call the user's main function, and exit with its value.
           But let the libc call main.    */
        call BP_SYM (__libc_start_main)@PLT

Re: is main() provided by a library valid C ?

[Daniel Jacobowitz]

On Thu, May 19, 2005 at 11:14:25PM +0200, Joakim Tjernlund wrote:
> > 
> > On Thu, May 19, 2005 at 10:40:07PM +0200, Joakim Tjernlund wrote:
> > > If my memory serves me right, to build libc w/ -z defs, main needs to be declared
> > > weak in libc.
> > 
> > Incorrect.  Libc doesn't need to mention main at all.  Please look at
> > glibc's CRT files.
> 
> Ahh, now I understand why you pass main as argument from start.S to libc, right?
> Is this the only reason you do that or is there more to it?

I didn't write it; I have no idea.  It seems like a sounder design.

> Aligns the stack to 16-byte, then the code below does 8 pushl at which point the
> stack is 16-byte aligned again and finally a call to __libc_start_main. The call to 
> __libc_start_main will add 4 bytes to the stack ptr and now the stack isn't 16-byte
> aligned when __libc_start_main starts to execute. Is this the way it is supposed to work?

Presumably this is the ABI-mandated behavior.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: is main() provided by a library valid C ?

[Joakim Tjernlund]

> 
> On Thu, May 19, 2005 at 11:14:25PM +0200, Joakim Tjernlund wrote:
> > > 
> > > On Thu, May 19, 2005 at 10:40:07PM +0200, Joakim Tjernlund wrote:
> > > > If my memory serves me right, to build libc w/ -z defs, main needs to be declared
> > > > weak in libc.
> > > 
> > > Incorrect.  Libc doesn't need to mention main at all.  Please look at
> > > glibc's CRT files.
> > 
> > Ahh, now I understand why you pass main as argument from start.S to libc, right?
> > Is this the only reason you do that or is there more to it?
> 
> I didn't write it; I have no idea.  It seems like a sounder design.

OK, thanks.

> 
> > Aligns the stack to 16-byte, then the code below does 8 pushl at which point the
> > stack is 16-byte aligned again and finally a call to __libc_start_main. The call to 
> > __libc_start_main will add 4 bytes to the stack ptr and now the stack isn't 16-byte
> > aligned when __libc_start_main starts to execute. Is this the way it is supposed to work?
> 
> Presumably this is the ABI-mandated behavior.

hmm probably, but it is a little strange to require 16-byte aligned stack ptr before
calling a function instead of having the called function begin execution with a 16-byte aligned
stack ptr.

 Jocke

RE: is main() provided by a library valid C ?

[Peter S. Mazinger]

On Fri, 20 May 2005, Joakim Tjernlund wrote:

> > 
> > On Thu, May 19, 2005 at 11:14:25PM +0200, Joakim Tjernlund wrote:
> > > > 
> > > > On Thu, May 19, 2005 at 10:40:07PM +0200, Joakim Tjernlund wrote:
> > > > > If my memory serves me right, to build libc w/ -z defs, main needs to be declared
> > > > > weak in libc.
> > > > 
> > > > Incorrect.  Libc doesn't need to mention main at all.  Please look at
> > > > glibc's CRT files.
> > > 

This is becoming out of topic, my question isn't answered though:

Is it allowed (as of linking) that the function main() been provided by a 
shared or static library instead of an object (*.o) ?

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: is main() provided by a library valid C ?

[Alan Modra]

On Fri, May 20, 2005 at 08:38:47AM +0200, Peter S. Mazinger wrote:
> Is it allowed (as of linking) that the function main() been provided by a 
> shared or static library instead of an object (*.o) ?

The linker doesn't care.  main in a static library will definitely work.
main in a shared lib will probably require a special startup file,
ie. the code that runs from _start to main.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: is main() provided by a library valid C ?

[Daniel Jacobowitz]

On Fri, May 20, 2005 at 04:33:22PM +0930, Alan Modra wrote:
> On Fri, May 20, 2005 at 08:38:47AM +0200, Peter S. Mazinger wrote:
> > Is it allowed (as of linking) that the function main() been provided by a 
> > shared or static library instead of an object (*.o) ?
> 
> The linker doesn't care.  main in a static library will definitely work.
> main in a shared lib will probably require a special startup file,
> ie. the code that runs from _start to main.

Well, it works without anything special on GNU/Linux as far as I know.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: is main() provided by a library valid C ?

[H. J. Lu]

On Fri, May 20, 2005 at 08:38:47AM +0200, Peter S. Mazinger wrote:
> On Fri, 20 May 2005, Joakim Tjernlund wrote:
> 
> > > 
> > > On Thu, May 19, 2005 at 11:14:25PM +0200, Joakim Tjernlund wrote:
> > > > > 
> > > > > On Thu, May 19, 2005 at 10:40:07PM +0200, Joakim Tjernlund wrote:
> > > > > > If my memory serves me right, to build libc w/ -z defs, main needs to be declared
> > > > > > weak in libc.
> > > > > 
> > > > > Incorrect.  Libc doesn't need to mention main at all.  Please look at
> > > > > glibc's CRT files.
> > > > 
> 
> This is becoming out of topic, my question isn't answered though:
> 
> Is it allowed (as of linking) that the function main() been provided by a 
> shared or static library instead of an object (*.o) ?
> 

Linker doesn't really know/care main. If you find out that you have to
make main protected, please provide a small testcase. I will look into
it.


H.J.