bugThe GNU Hurd - Bugs: bug #17647, glibc: GCC 4.1

 
 
Show feedback again

bug #17647: glibc: GCC 4.1

Submitted by:  Thomas Schwinge <tschwinge>
Submitted on:  Fri 08 Sep 2006 08:40:03 AM UTC  
 
Category: glibcSeverity: 5 - Blocker
Priority: 9 - ImmediateItem Group: Standard Compliance
Status: In ProgressPrivacy: Public
Assigned to: NoneOriginator Name: 
Open/Closed: OpenReproducibility: Every Time
Size (loc): NonePlanned Release: None
Effort: 0.00
Wiki-like text discussion box: 

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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>
Project 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>
Project 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>
Project 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>
Project Administrator

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter 421 here (basic anti-spam test):

 

 

Follow 2 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sun 19 Nov 2006 10:33:45 PM UTCtschwingeStatusNone=>In Progress
  Carbon-Copy-=>Added roland
Show feedback again

Back to the top


Powered by Savane 3.1-cleanup