bugThe GNU Hurd - Bugs: bug #17647, glibc: GCC vs. init-first.c

 
 

bug #17647: glibc: GCC vs. init-first.c

Submitter:  Thomas Schwinge <tschwinge>
Submitted:  Fri 08 Sep 2006 08:40:03 AM UTC
   
 
Category:  glibc Severity:  5 - Blocker
Priority:  9 - Immediate Item Group:  Standard Compliance
Status:  Fixed Privacy:  Public
Assigned to:  tschwinge Originator Name: 
Open/Closed:  Closed Reproducibility:  Every Time
Size (loc):  None Planned Release:  None
Effort:  0.00
Wiki-like text discussion box: 


* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 12 May 2012 02:58:04 AM UTC, comment #7: 

18bad2ae1bd1797782d51231d24f7b773c2bfff6

Thomas Schwinge <tschwinge>
Group administrator
Sat 15 Oct 2011 10:35:51 AM UTC, comment #6: 

Fixed in t/init-first.c branch.

Tested with current Debian GNU/Hurd gcc-4.4, gcc-4.5, gcc-4.6.  Additionally with a hello world program (both regular and -static) with cross-gnu with GCC trunk as of some weeks ago.

Not yet built and tested any (static) Hurd translators.  Hopefully no bad surprises there...

Thomas Schwinge <tschwinge>
Group administrator
  Spam posted by susancai
Sun 19 Nov 2006 10:59:29 PM UTC, comment #4: 

And indeed: reverting the following makes the `libc.so' again work with GCC 4.1.  Probably reverting the similar ones will be needed for non-shared stuff, which I didn't test so far.

| #v+
| [...]
| void
| -_dl_init_first (int argc, ...)
| +_dl_init_first (void)
| {
| first_init ();
|
| - init (&argc);
| + init ((int *) __builtin_frame_address (0) + 2);
| }
| [...]
| #v-


So, how can this be explained?

Thomas Schwinge <tschwinge>
Group administrator
Sun 19 Nov 2006 10:49:18 PM UTC, comment #3: 

| #v+
| $ gcc-4.0 test.c && ./a.out
| main:fa = 3216472808 fa[1] = 3084724428 ra = 3084724428
| func:fa[0] = 3216472808 fa[1] = 134513645 ra = 134513645
| #v-
|
| This is what I would expect. However:
|
| #v+
| main:fa = 3220364948 fa[1] = 3220365064 ra = 3085416652
| func:fa[0] = 3220364952 fa[1] = 134513639 ra = 134513639
| #v-

The second example is with GCC 4.1, I should perhaps have mentioned...

Thomas Schwinge <tschwinge>
Group administrator
Sun 19 Nov 2006 10:33:45 PM UTC, comment #2: 

I had a look today.  But now I think I need Roland's or someone else's help.  The problem is --- so far --- only in `sysdeps/mach/hurd/i386/init-first.c'.  As soon as I compile that file with GCC 4.0 and everything else with GCC 4.1, the resulting `libc.so' doesn't fail anymore.  (I was only testing with a primitive ``int main (void) { return 0; }'' so far, but that's already something.)

So, what did I find.  The problem may be related to this change:

#v+
2005-10-16  Roland McGrath  <roland@frob.com>
[...]
        [BZ #1253]
        * sysdeps/mach/hurd/i386/init-first.c (init): Make cast kosher.
        (_hurd_stack_setup): Don't declare with arguments and ellipsis.
        Use __builtin_frame_address and __builtin_return_address.
        (_dl_init_first): Likewise.
#v-

#v+
[...]
 void
-_dl_init_first (int argc, ...)
+_dl_init_first (void)
 {
   first_init ();
 
-  init (&argc);
+  init ((int *) __builtin_frame_address (0) + 2);
 }
[...]
#v-


Now, experimenting a bit, there is a strange thing going on when using GCC 4.1 and `__builtin_frame_address':

Consider this test program:

#v+
#include <stdio.h>

void func (void)
{
  int *ra = __builtin_return_address (0);
  int *fa = __builtin_frame_address (0);

  printf ("%s:fa[0] = %u\tfa[1] = %u\tra = %u\n", _func_, fa[0], fa[1], ra);
}

int main (void)
{
  int *ra = __builtin_return_address (0);
  int *fa = __builtin_frame_address (0);

  printf ("%s:fa = %u\tfa[1] = %u\tra = %u\n", _func_, fa, fa[1], ra);

  func ();
}
#v-

#v+
$ gcc-4.0 test.c && ./a.out
main:fa = 3216472808    fa[1] = 3084724428      ra = 3084724428
func:fa[0] = 3216472808 fa[1] = 134513645       ra = 134513645
#v-

This is what I would expect.  However:

#v+
main:fa = 3220364948    fa[1] = 3220365064      ra = 3085416652
func:fa[0] = 3220364952 fa[1] = 134513639       ra = 134513639
#v-

When applying optimizations via `-O' even the GCC 4.0 one produces unexpected results, but that's due to function-inlining then, I guess.


So, perhaps there's something wrong with the usage of `__builtin_frame_address' in `_dl_init_first'?

Thomas Schwinge <tschwinge>
Group administrator
Sat 23 Sep 2006 03:47:40 PM UTC, comment #1: 

A short note: building the Debian glibc package (version 2.3.6.ds1-4) with `-fstrict-aliasing' changed to `-fno-strict-aliasing' in HOST_CFLAGS in debian/rules and removing the gcc-4.0 lines from debian/sysdeps/hurd.mk (i.e. switch to the default GCC 4.1) does not ``fix'' this issue.

Thomas Schwinge <tschwinge>
Group administrator
Fri 08 Sep 2006 08:40:03 AM UTC, original submission:  

A GCC 4.1-built glibc doesn't work correctly: it already fails during the building process, as soon as the newly created libc.so is being used (might also be ld.so, I don't remember exactly).

Thomas Schwinge <tschwinge>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by tschwinge (Posted a comment)
  • -email is unavailable- added by tschwinge
  • -email is unavailable- added by susancai (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-05-12 tschwinge StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2011-10-15 tschwinge StatusIn Progress Ready For Test
        Assigned toNone tschwinge
        Summaryglibc: GCC 4.1 glibc: GCC vs. init-first.c
        Carbon-Copy- Added civodul
    2006-11-19 tschwinge StatusNone In Progress
        Carbon-Copy- Added roland

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code