problems when rebuilding minix3 with gcc-4.7.0

[Ping Huang]

Hi all,

Currently I'm trying to port gcc-4.7.0 to minix3 (as a submask of GSoC
2012). Until now, I have built gcc-4.7.0 on minix with pkgsrc (for
simplicity, only enable c and c++, disable fortran). After check with
testsuite in gcc and some simple program such as helloworld, I try to
rebuild the system with it.

There are three problems in the building process:

1. As stage of make -C sys dependall, building failed in bootxx_ext2fs
directory, with the error message "bootxx_ext2fs size 8420 is larger
than 7680". The reason is the size of bootxx_ext2fs generated by
gcc-4.7.0 is 8420, and is larger than BOOTXX_SECTORS * 512.
Currently, BOOTXX_SECTORS is set to 15 due to the restriction of 1.2M
floppy. I'm not sure BOOTXX_SECTORS can be increased to 17, which is
enough for 8420, but I set it to let the building continue.

2. As stage of make install, After commands/make/make is installed,
the install opertion will fail. The cause is that setenv is called
before __libc_env_init (__libc_env_init is called by __libc_init).
However, I don't really see where __libc_init is called by make. Does
anyone encounter the problem before?

3. Also in stage of make install, when install memory, mkimage failed.
The error message is that "elf_begin() failed: invalid ELF_C_*
argument". I have checked the lib/libelf/elf_begin.c, and
usr.bin/mkimage/mkimage.c

In mkimage.c:

if ((e = elf_begin(fd, ELF_C_RDWR, NULL)) == NULL)
errx(EX_SOFTWARE, "elf_begin() failed: %s.", elf_errmsg(-1));

In elf_begin.c:

case ELF_C_RDWR:
if (a != NULL) { /* not allowed for ar(1) archives. */
LIBELF_SET_ERROR(ARGUMENT, 0);
return (NULL);
}
/*FALLTHROUGH*/
case ELF_C_READ:
if (a &&
((a->e_fd != -1 && a->e_fd != fd) || c != a->e_cmd)) {
LIBELF_SET_ERROR(ARGUMENT, 0);
return (NULL);
}
break;

default:
LIBELF_SET_ERROR(ARGUMENT, 0);
return (NULL);

In this case, mkimage will fail as expected. However, mkimage can pass
with clang, So I don't know which file or variable causes it.

Any advice is apprecited.

Thanks,
Ping

[Patrick Mc(avery]

Hi Ping

I am sorry I don't have any suggestions here, I am just learning about
Minix.

Could I ask a favour though?

Once you have gcc 4.7 working with C/C++ could you try to recompile it
with Ada support? If it fails, I don't want to add more work for you but
if it compiles without errors, it will add a really high reliability
language to Minix.

I hope I can help you someday, sorry it's not today-Patrick

> ((a->e_fd != -1&& a->e_fd != fd) || c != a->e_cmd)) {

[BeakGwangMoon]

Hi Ping Huang

> 2. As stage of make install, After commands/make/make is installed,
> the install opertion will fail. The cause is that setenv is called
> before __libc_env_init (__libc_env_init is called by __libc_init).
> However, I don't really see where __libc_init is called by make. Does
> anyone encounter the problem before?

I have a just one suggestion here, I am just learning about Minix.

Please, Use an linker option, -lc, when you compile it.

I hope this help.

With a kind regards.

moon.

[pikpik]

Hi,

On Jun 17, 2:09 pm, BeakGwangMoon wrote:

> > 2. As stage of make install, After commands/make/make is installed,
> > the install opertion will fail. The cause is that setenv is called
> > before __libc_env_init (__libc_env_init is called by __libc_init).
> > However, I don't really see where __libc_init is called by make. Does
> > anyone encounter the problem before?

> Please, Use an  linker option, -lc, when you compile it.

If that isn't already used, then I guess it could help.

I have seen something like this before when my C library used symbol
type definitions that were different from what were in a program.

1. To see if it's the issue,

(a) # grep ".type" /usr/src/lib/generateasm.mk
(b) # grep ".type" /usr/src/lib/libc/compat__sigaction14.S

2. If the results of (a) and (b) are different (one has ".type" and
the other doesn't), then you have a problem.

(If you're tracking current, then ".type" should appear in both.)

3. To fix it:

# rm /usr/src/lib/libc/compat_*.S

...then build everything again.

Of course, that might not be the problem.

I hope this helps,
pikpik

[Antoine LECA]

Ping Huang wrote:
> 1. As stage of make -C sys dependall, building failed in bootxx_ext2fs
> directory, with the error message "bootxx_ext2fs size 8420 is larger
> than 7680".

Do not worry for that file: it is not used anyway; currently MINIX only
boots from a MinixFS (bootxx_minixfs3), and it does so using special
tricks in the partition layout; in order to boot from a ext2 file system
(or UFS, or FAT), you need to set up things manually anyway.
Furthermore, the 15 sectors limit applies when you are installing that
file as part of a NetBSD disklabel (where there is only 15 sectors free,
hence the limit), and I do not believe anybody is using that.

On the other hand, it is important to know there is a problem here,
because it is likely to affect NetBSD (which is using the same boot
loader) when/if they switch to GCC 4.7.

> 2. As stage of make install, After commands/make/make is installed,
> the install opertion will fail. The cause is that setenv is called
> before __libc_env_init (__libc_env_init is called by __libc_init).
> However, I don't really see where __libc_init is called by make. Does
> anyone encounter the problem before?

This one, or things seeming it, is something we already saw, but the
reverse way, when we switched to clang! If I understand correctly, we
solved it installing our own crtbegin.o and crtend.o in /usr/lib,
compiled for clang, which adequately calls the constructors within
crti.o, which is in turn from where __libc_init() is called.
Since GCC comes with its own version of crtstuff, I guess the problem is
that the GCC version is picked up, and that either it does not look for
or call the /usr/lib/crti.o stuff, or it does it at the wrong moment

> 3. Also in stage of make install, when install memory, mkimage failed.

Do you mean, mkimage is failing while processing memory?
Mkimage processes all the boot-time services in a row, to adjust their
start address to be one after the other in the final memory map; if it
stumps on the first service, ds, then the problem is likely to be with
our code; but if the problem occurs only for memory, which is the 8th
service examined, then it is likely to be a specific problem with it.
Memory is special in two ways: it is by far the biggest service, because
it embeds the initial file system; and it is built from two object
(relocatable) files, one [memory.o] being normal but the other one,
imgrd.o, is created with objcopy.


Antoine

[Antoine LECA]

BeakGwangMoon wrote:
>> However, I don't really see where __libc_init is called by make. Does
>> anyone encounter the problem before?
>
> I have a just one suggestion here, I am just learning about Minix.
>
> Please, Use an linker option, -lc, when you compile it.

I believe __libc_init is already linked in, because he does not mention
a missing symbol, rather the fact the function is not called.

If you grep for it
(http://git.minix3.org/?p=minix.git&a=search&h=HEAD&st=grep&s=__libc_init),
__libc_init is used in two places:

* in libc/stdlib/exit.c, the symbol is forced in by a reference (the
names are pretty explicit);

* in libc/misc/initfini.c, the function itself is defined, but there is
an additional important feature: it is marked with
__attribute__((__constructor__, __used__));
The first attribute, constructor, asks the linker to include it such as
it should be called before main() by the runtime support (the second
one, used, does the same as above, it forces inclusion of that code.)


Antoine

[Ping Huang]

Hi Patrick,

2012/6/18, Patrick Mc(avery <spell_go...@spellingbeewinnars.org>:

> Once you have gcc 4.7 working with C/C++ could you try to recompile it
> with Ada support? If it fails, I don't want to add more work for you but
> if it compiles without errors, it will add a really high reliability
> language to Minix.

I will give it a try after I succeed to support C/C++, and tell you the result.

Thanks,
Ping

[Ping Huang]

Hi moon,

2012/6/18, BeakGwangMoon <moonl...@naver.com>:

> I have a just one suggestion here, I am just learning about Minix.
>
> Please, Use an linker option, -lc, when you compile it.

Thank you for your suggestion. As Antoine said, the object indeed has
linked in.

Best,
Ping

[Ping Huang]

Hi pikpik,

2012/6/18, pikpik <pikpi...@gmail.com>:

> (a) # grep ".type" /usr/src/lib/generateasm.mk
> (b) # grep ".type" /usr/src/lib/libc/compat__sigaction14.S
>
> 2. If the results of (a) and (b) are different (one has ".type" and
> the other doesn't), then you have a problem.
>
> (If you're tracking current, then ".type" should appear in both.)

Thank you for your detailed suggestion!
I did grep ".type", Unfortunately, the two files both have ".type". So
I don't think this is the cause.

Best,
Ping

[Ping Huang]

Hi Antoine,

2012/6/18, Antoine LECA <antoine...@gmail.com>:

> * in libc/misc/initfini.c, the function itself is defined, but there is
> an additional important feature: it is marked with
> __attribute__((__constructor__, __used__));
> The first attribute, constructor, asks the linker to include it such as
> it should be called before main() by the runtime support (the second
> one, used, does the same as above, it forces inclusion of that code.)

Thank you for your detailed and patient reply!
For initfini, I remember that I add "--enable-initfini-array" to gcc
confiure args, because otherwise, the system would crash when checking
whether "--enable-initfini-array" was given. I don't know this option
would have something to do with "make" problem. What's your opinion?

Thanks,
Ping

[Antoine LECA]

Ping Huang wrote:
> For initfini, I remember that I add "--enable-initfini-array"

Hmmm... I am not sure our [NetBSD's] csu ("CRT start-up") code supports
that option; and when I look at lib/csu/arch/i386/crti.S, it only shows
.init and .fini, and not .init_array, which is a bad signal for me...

As a side point, I find some material about it in an ancient thread,
http://mail-index.netbsd.org/tech-toolchain/2005/07/18/0003.html
Unfortunately the thread went nowhere.

I found patches for FreeBSD (e.g.
http://people.freebsd.org/~kib/misc/init_array.*.patch)

> to gcc
> confiure args, because otherwise, the system would crash when checking
> whether "--enable-initfini-array" was given.

Did you try with explicit --disable-initfini-array ?

It seems this crept into GCC in December 2010, there is a H.J. Lu's
patch proposal about it, it might raises paths.

Also look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 (which
also advise for --disable) and http://patchwork.ozlabs.org/patch/136728/



Antoine

[Patrick]

Was 4.7 able to be ported to Minix?

-Patrick

[Antoine LECA]

Patrick wrote:
> Was 4.7 able to be ported to Minix?

http://wiki.minix3.org/en/SummerOfCode2012/GnuToolchain says 100% done


Antoine

[Alex Buell]

You do know that both 4.7.0 and 4.7.1 have broken ABIs which were fixed
with 4.7.2. Basically code built with both 4.7.0 and 4.7.1 may not be
compatible with older revisions or with 4.7.2 either.
--
Tactical Nuclear Kittens

[Patrick Mc(avery]

I just downloaded the current snapshot(3.2.1) and ran pkgin update,
pkgin search gcc and I don't see 4.7 there.

How do I get 4.7 ?

Thanks

[Ping Huang]

Hi Patrick,

You can find the pkgsrc package of gcc 4.7 here:
git://git.minix3.org/pkgsrc, gcc 4.7 is in the minix-master branch.
Note that it's source patches, not binary. You have to build it
yourself.

I'm sorry that these days I'm very busy with my dissertation and job
hunting, thus have little time to continue this project.

Best,
Ping

2012/10/5 Patrick Mc(avery <spell_go...@spellingbeewinnars.org>:

> --
> You received this message because you are subscribed to the Google Groups
> "minix3" group.
> To post to this group, send email to min...@googlegroups.com.
> To unsubscribe from this group, send email to
> minix3+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/minix3?hl=en.
>

[Antoine LECA]

Alex Buell wrote:
> On Thu, 2012-10-04 at 20:41 +0200, Antoine LECA wrote:
>> Patrick wrote:
>>> Was 4.7 able to be ported to Minix?
>>
>> http://wiki.minix3.org/en/SummerOfCode2012/GnuToolchain says 100% done
>
> You do know that both 4.7.0 and 4.7.1 have broken ABIs

No I did not. But I did not use any version of Gcc beyond 4.5.3 either,
and I did not use any version 4.x of g++, so *I* am not affected by such
a problem.


Antoine

[Alex Buell]

On Fri, 2012-10-05 at 16:51 +0200, Antoine LECA wrote:

> > You do know that both 4.7.0 and 4.7.1 have broken ABIs
>
> No I did not. But I did not use any version of Gcc beyond 4.5.3 either,
> and I did not use any version 4.x of g++, so *I* am not affected by such
> a problem.

Then you'll be OK. I'd suggest using 4.7.2 instead when the time comes
to put a 4.7.x compiler into the pkgsrc tree.
--
Tactical Nuclear Kittens

[Patrick Mc(avery]

Thanks Ping

Good luck with your job hunt, it's a tough job itself. I hope you get a
great one