* ld and R_386_GOTOFF relocs
@ 2005-05-11 22:57 Peter S. Mazinger
2005-05-12 0:41 ` H. J. Lu
0 siblings, 1 reply; 20+ messages in thread
From: Peter S. Mazinger @ 2005-05-11 22:57 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ld and R_386_GOTOFF relocs
2005-05-11 22:57 ld and R_386_GOTOFF relocs Peter S. Mazinger
@ 2005-05-12 0:41 ` H. J. Lu
2005-05-12 6:29 ` Peter S. Mazinger
0 siblings, 1 reply; 20+ messages in thread
From: H. J. Lu @ 2005-05-12 0:41 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: binutils, gcc
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ld and R_386_GOTOFF relocs
2005-05-12 0:41 ` H. J. Lu
@ 2005-05-12 6:29 ` Peter S. Mazinger
2005-05-12 21:33 ` H. J. Lu
0 siblings, 1 reply; 20+ messages in thread
From: Peter S. Mazinger @ 2005-05-12 6:29 UTC (permalink / raw)
To: H. J. Lu; +Cc: binutils, gcc
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ld and R_386_GOTOFF relocs
2005-05-12 6:29 ` Peter S. Mazinger
@ 2005-05-12 21:33 ` H. J. Lu
2005-05-12 21:36 ` Peter S. Mazinger
2005-05-13 11:34 ` is main() provided by a library valid C ? Peter S. Mazinger
0 siblings, 2 replies; 20+ messages in thread
From: H. J. Lu @ 2005-05-12 21:33 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: binutils, gcc
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: ld and R_386_GOTOFF relocs
2005-05-12 21:33 ` H. J. Lu
@ 2005-05-12 21:36 ` Peter S. Mazinger
2005-05-13 11:34 ` is main() provided by a library valid C ? Peter S. Mazinger
1 sibling, 0 replies; 20+ messages in thread
From: Peter S. Mazinger @ 2005-05-12 21:36 UTC (permalink / raw)
To: H. J. Lu; +Cc: binutils, gcc
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* is main() provided by a library valid C ?
2005-05-12 21:33 ` H. J. Lu
2005-05-12 21:36 ` Peter S. Mazinger
@ 2005-05-13 11:34 ` Peter S. Mazinger
2005-05-13 14:02 ` Daniel Jacobowitz
1 sibling, 1 reply; 20+ messages in thread
From: Peter S. Mazinger @ 2005-05-13 11:34 UTC (permalink / raw)
To: binutils; +Cc: Joakim.Tjernlund
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: is main() provided by a library valid C ?
2005-05-13 11:34 ` is main() provided by a library valid C ? Peter S. Mazinger
@ 2005-05-13 14:02 ` Daniel Jacobowitz
2005-05-18 19:39 ` Peter S. Mazinger
0 siblings, 1 reply; 20+ messages in thread
From: Daniel Jacobowitz @ 2005-05-13 14:02 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: binutils, Joakim.Tjernlund
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: is main() provided by a library valid C ?
2005-05-13 14:02 ` Daniel Jacobowitz
@ 2005-05-18 19:39 ` Peter S. Mazinger
2005-05-18 20:23 ` Daniel Jacobowitz
0 siblings, 1 reply; 20+ messages in thread
From: Peter S. Mazinger @ 2005-05-18 19:39 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: binutils, Joakim.Tjernlund
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: is main() provided by a library valid C ?
2005-05-18 19:39 ` Peter S. Mazinger
@ 2005-05-18 20:23 ` Daniel Jacobowitz
2005-05-18 20:27 ` Peter S. Mazinger
0 siblings, 1 reply; 20+ messages in thread
From: Daniel Jacobowitz @ 2005-05-18 20:23 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: binutils, Joakim.Tjernlund
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: is main() provided by a library valid C ?
2005-05-18 20:23 ` Daniel Jacobowitz
@ 2005-05-18 20:27 ` Peter S. Mazinger
2005-05-19 2:40 ` Daniel Jacobowitz
0 siblings, 1 reply; 20+ messages in thread
From: Peter S. Mazinger @ 2005-05-18 20:27 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: binutils, Joakim.Tjernlund
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: is main() provided by a library valid C ?
2005-05-18 20:27 ` Peter S. Mazinger
@ 2005-05-19 2:40 ` Daniel Jacobowitz
2005-05-19 20:55 ` Joakim Tjernlund
0 siblings, 1 reply; 20+ messages in thread
From: Daniel Jacobowitz @ 2005-05-19 2:40 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: binutils, Joakim.Tjernlund
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: is main() provided by a library valid C ?
2005-05-19 2:40 ` Daniel Jacobowitz
@ 2005-05-19 20:55 ` Joakim Tjernlund
2005-05-19 21:14 ` Daniel Jacobowitz
0 siblings, 1 reply; 20+ messages in thread
From: Joakim Tjernlund @ 2005-05-19 20:55 UTC (permalink / raw)
To: Daniel Jacobowitz, Peter S. Mazinger; +Cc: binutils
> -----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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: is main() provided by a library valid C ?
2005-05-19 20:55 ` Joakim Tjernlund
@ 2005-05-19 21:14 ` Daniel Jacobowitz
2005-05-19 21:19 ` Joakim Tjernlund
0 siblings, 1 reply; 20+ messages in thread
From: Daniel Jacobowitz @ 2005-05-19 21:14 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Peter S. Mazinger, binutils
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: is main() provided by a library valid C ?
2005-05-19 21:14 ` Daniel Jacobowitz
@ 2005-05-19 21:19 ` Joakim Tjernlund
2005-05-19 22:59 ` Daniel Jacobowitz
0 siblings, 1 reply; 20+ messages in thread
From: Joakim Tjernlund @ 2005-05-19 21:19 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Peter S. Mazinger, binutils
>
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: is main() provided by a library valid C ?
2005-05-19 21:19 ` Joakim Tjernlund
@ 2005-05-19 22:59 ` Daniel Jacobowitz
2005-05-20 2:35 ` Joakim Tjernlund
0 siblings, 1 reply; 20+ messages in thread
From: Daniel Jacobowitz @ 2005-05-19 22:59 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Peter S. Mazinger, binutils
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: is main() provided by a library valid C ?
2005-05-19 22:59 ` Daniel Jacobowitz
@ 2005-05-20 2:35 ` Joakim Tjernlund
2005-05-20 7:03 ` Peter S. Mazinger
0 siblings, 1 reply; 20+ messages in thread
From: Joakim Tjernlund @ 2005-05-20 2:35 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Peter S. Mazinger, binutils
>
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: is main() provided by a library valid C ?
2005-05-20 2:35 ` Joakim Tjernlund
@ 2005-05-20 7:03 ` Peter S. Mazinger
2005-05-20 7:28 ` Alan Modra
2005-05-20 13:47 ` H. J. Lu
0 siblings, 2 replies; 20+ messages in thread
From: Peter S. Mazinger @ 2005-05-20 7:03 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Daniel Jacobowitz, binutils
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: is main() provided by a library valid C ?
2005-05-20 7:03 ` Peter S. Mazinger
@ 2005-05-20 7:28 ` Alan Modra
2005-05-20 13:00 ` Daniel Jacobowitz
2005-05-20 13:47 ` H. J. Lu
1 sibling, 1 reply; 20+ messages in thread
From: Alan Modra @ 2005-05-20 7:28 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: binutils
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: is main() provided by a library valid C ?
2005-05-20 7:28 ` Alan Modra
@ 2005-05-20 13:00 ` Daniel Jacobowitz
0 siblings, 0 replies; 20+ messages in thread
From: Daniel Jacobowitz @ 2005-05-20 13:00 UTC (permalink / raw)
To: Peter S. Mazinger, binutils
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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: is main() provided by a library valid C ?
2005-05-20 7:03 ` Peter S. Mazinger
2005-05-20 7:28 ` Alan Modra
@ 2005-05-20 13:47 ` H. J. Lu
1 sibling, 0 replies; 20+ messages in thread
From: H. J. Lu @ 2005-05-20 13:47 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: Joakim Tjernlund, Daniel Jacobowitz, binutils
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2005-05-20 13:00 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-05-11 22:57 ld and R_386_GOTOFF relocs Peter S. Mazinger
2005-05-12 0:41 ` H. J. Lu
2005-05-12 6:29 ` Peter S. Mazinger
2005-05-12 21:33 ` H. J. Lu
2005-05-12 21:36 ` Peter S. Mazinger
2005-05-13 11:34 ` is main() provided by a library valid C ? Peter S. Mazinger
2005-05-13 14:02 ` Daniel Jacobowitz
2005-05-18 19:39 ` Peter S. Mazinger
2005-05-18 20:23 ` Daniel Jacobowitz
2005-05-18 20:27 ` Peter S. Mazinger
2005-05-19 2:40 ` Daniel Jacobowitz
2005-05-19 20:55 ` Joakim Tjernlund
2005-05-19 21:14 ` Daniel Jacobowitz
2005-05-19 21:19 ` Joakim Tjernlund
2005-05-19 22:59 ` Daniel Jacobowitz
2005-05-20 2:35 ` Joakim Tjernlund
2005-05-20 7:03 ` Peter S. Mazinger
2005-05-20 7:28 ` Alan Modra
2005-05-20 13:00 ` Daniel Jacobowitz
2005-05-20 13:47 ` H. J. Lu
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).