ARMv7 - EABI - Cross Compiler

[Vassilis Laganakos]

Hello,

I recently started working on getting a later version of GCC as a cross-compiler for FreeBSD.
The main reason is that I'm interested in having support for the "new" ARM EABI that will give
the benefits of ARMv5TE onwards, to all the boards that use it (Mistral EVM, BeagleBoard, etc)

I've built gcc 4.4.1 (rev 147925) and binutils (2.19.51.20090527), using the 7-STABLE headers where appropriate.
I'm now trying to built libc from the same branch. I'm trying to pull out libc from the building tree, and
build it with the above toolchain so that it will be available to use it with that (once done, I'll commit a port for this);
at the same time I'm try to drop the GCC 4.4.1 in the build tree to be able to use it for building the world.

Please let me know whether I'm  going down the wrong path or not :o) Tips and advice pointers towards
the right direction would be more than helpful!

I don't know if someone else is working on something similar, but if the answer is "yes" I would be quite
happy to be of help. If not, any kind of help would be most appreciated :o)

Kind regards,
Vassilis L.



     
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Sam Leffler-2]

Vassilis Laganakos wrote:

> Hello,
>
> I recently started working on getting a later version of GCC as a cross-compiler for FreeBSD.
> The main reason is that I'm interested in having support for the "new" ARM EABI that will give
> the benefits of ARMv5TE onwards, to all the boards that use it (Mistral EVM, BeagleBoard, etc)
>
> I've built gcc 4.4.1 (rev 147925) and binutils (2.19.51.20090527), using the 7-STABLE headers where appropriate.
> I'm now trying to built libc from the same branch. I'm trying to pull out libc from the building tree, and
> build it with the above toolchain so that it will be available to use it with that (once done, I'll commit a port for this);
> at the same time I'm try to drop the GCC 4.4.1 in the build tree to be able to use it for building the world.
>
> Please let me know whether I'm  going down the wrong path or not :o) Tips and advice pointers towards
> the right direction would be more than helpful!
>
> I don't know if someone else is working on something similar, but if the answer is "yes" I would be quite
> happy to be of help. If not, any kind of help would be most appreciated :o)
>
>  

Your basic approach sounds fine.  I believe you will find many small
changes to base code required by the later version of gcc (depending on
compile options).  If you work with HEAD instead of RELENG_7 then these
changes can likely be merged and will simplify your effort in the
future.  Ideally you should be able to install the gcc port, pull
freebsd code, and then use the xdev  build mechanism to cross-build w/
the toolchain.

    Sam

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Vassilis Laganakos]

Hello Sam,

----- Original Message ----

> From: Sam Leffler <[hidden email]>
> To: Vassilis Laganakos <[hidden email]>
> Cc: [hidden email]
> Sent: Tuesday, June 2, 2009 5:39:36 PM
> Subject: Re: ARMv7 - EABI - Cross Compiler
>
> Vassilis Laganakos wrote:
> > Hello,
> >
> > I recently started working on getting a later version of GCC as a
> cross-compiler for FreeBSD.
> > The main reason is that I'm interested in having support for the "new" ARM
> EABI that will give the benefits of ARMv5TE onwards, to all the boards that use
> it (Mistral EVM, BeagleBoard, etc)
> >
> > I've built gcc 4.4.1 (rev 147925) and binutils (2.19.51.20090527), using the
> 7-STABLE headers where appropriate. I'm now trying to built libc from the same
> branch. I'm trying to pull out libc from the building tree, and
> > build it with the above toolchain so that it will be available to use it with
> that (once done, I'll commit a port for this); at the same time I'm try to drop
> the GCC 4.4.1 in the build tree to be able to use it for building the world.
> >
> > Please let me know whether I'm  going down the wrong path or not :o) Tips and
> advice pointers towards
> > the right direction would be more than helpful!
> >
> > I don't know if someone else is working on something similar, but if the
> answer is "yes" I would be quite happy to be of help. If not, any kind of help
> would be most appreciated :o)
> >
> >  
>
> Your basic approach sounds fine.  
>

Thanks for confirming the sanity of the approach. It's good to know that I'm walking
the right path. :o)

> I believe you will find many small changes to
> base code required by the later version of gcc (depending on compile options).  
>
Ok, I'll log everything down.

> If you work with HEAD instead of RELENG_7 then these changes can likely be
> merged and will simplify your effort in the future.  
>
Great. Although I want to track RELENG-7 for my box, until RELENG-8 moves to
stable :o) Would I have to use the latest binutils too, or these are already there
in HEAD?

> Ideally you should be able
> to install the gcc port, pull freebsd code, and then use the xdev  build
> mechanism to cross-build w/ the toolchain.
>
Thanks for the outline. Do you mean an existing gcc port, or the port I'm trying to pull
together? Haven't used xdev before, I just build stuff by defining TARGET
and TARGET_ARCH.

I'll look more into this and I'll get back with more results and almost certainly more
questions! :o)

Many thanks,

Vassilis L.


     

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Chuck Robey-5]

Sam Leffler wrote:

> Vassilis Laganakos wrote:
>> Hello,
>>
>> I recently started working on getting a later version of GCC as a
>> cross-compiler for FreeBSD.
>> The main reason is that I'm interested in having support for the "new"
>> ARM EABI that will give the benefits of ARMv5TE onwards, to all the
>> boards that use it (Mistral EVM, BeagleBoard, etc)
>>
>> I've built gcc 4.4.1 (rev 147925) and binutils (2.19.51.20090527),
>> using the 7-STABLE headers where appropriate. I'm now trying to built
>> libc from the same branch. I'm trying to pull out libc from the
>> building tree, and
>> build it with the above toolchain so that it will be available to use
>> it with that (once done, I'll commit a port for this); at the same
>> time I'm try to drop the GCC 4.4.1 in the build tree to be able to use
>> it for building the world.
>>
>> Please let me know whether I'm  going down the wrong path or not :o)
>> Tips and advice pointers towards
>> the right direction would be more than helpful!
>>
>> I don't know if someone else is working on something similar, but if
>> the answer is "yes" I would be quite happy to be of help. If not, any
>> kind of help would be most appreciated :o)
>>
>>  
>
> Your basic approach sounds fine.  I believe you will find many small
> changes to base code required by the later version of gcc (depending on
> compile options).  If you work with HEAD instead of RELENG_7 then these
> changes can likely be merged and will simplify your effort in the
> future.  Ideally you should be able to install the gcc port, pull
> freebsd code, and then use the xdev  build mechanism to cross-build w/
> the toolchain.

Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?
That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
processor until 4.3.0.  I was able to build a cross-gcc easily using a target of
"arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
FreeBSD.  I'll worry about getting that gcc into the build, but will it work for
me on a binary basis?
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Sam Leffler-2]

Chuck Robey wrote:

> Sam Leffler wrote:
>  
>> Vassilis Laganakos wrote:
>>    
>>> Hello,
>>>
>>> I recently started working on getting a later version of GCC as a
>>> cross-compiler for FreeBSD.
>>> The main reason is that I'm interested in having support for the "new"
>>> ARM EABI that will give the benefits of ARMv5TE onwards, to all the
>>> boards that use it (Mistral EVM, BeagleBoard, etc)
>>>
>>> I've built gcc 4.4.1 (rev 147925) and binutils (2.19.51.20090527),
>>> using the 7-STABLE headers where appropriate. I'm now trying to built
>>> libc from the same branch. I'm trying to pull out libc from the
>>> building tree, and
>>> build it with the above toolchain so that it will be available to use
>>> it with that (once done, I'll commit a port for this); at the same
>>> time I'm try to drop the GCC 4.4.1 in the build tree to be able to use
>>> it for building the world.
>>>
>>> Please let me know whether I'm  going down the wrong path or not :o)
>>> Tips and advice pointers towards
>>> the right direction would be more than helpful!
>>>
>>> I don't know if someone else is working on something similar, but if
>>> the answer is "yes" I would be quite happy to be of help. If not, any
>>> kind of help would be most appreciated :o)
>>>
>>>  
>>>      
>> Your basic approach sounds fine.  I believe you will find many small
>> changes to base code required by the later version of gcc (depending on
>> compile options).  If you work with HEAD instead of RELENG_7 then these
>> changes can likely be merged and will simplify your effort in the
>> future.  Ideally you should be able to install the gcc port, pull
>> freebsd code, and then use the xdev  build mechanism to cross-build w/
>> the toolchain.
>>    
>
> Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?
> That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
> processor until 4.3.0.  I was able to build a cross-gcc easily using a target of
> "arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
> FreeBSD.  I'll worry about getting that gcc into the build, but will it work for
> me on a binary basis?
>  

Yes, I was thinking Warner had committed some other stuff he and I had
talked about.  I haven't touched the buildtools in a while so not sure
what's required specifically for freebsd (like printf extensions).

    Sam

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Guillaume Ballet]

> Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?
> That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
> processor until 4.3.0.  I was able to build a cross-gcc easily using a target of
> "arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
> FreeBSD.  I'll worry about getting that gcc into the build, but will it work for
> me on a binary basis?
>

I used arm-none-eabi to compile my loader for the BeagleBoard so as to
get rid of the linux-specific stuff by default. But maybe you should
define something like arm-freebsd-eabi in gcc's build configuration?
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Vassilis Laganakos]

> > Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?

> > That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
> > processor until 4.3.0.  I was able to build a cross-gcc easily using a target
> of
> > "arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
> > FreeBSD.  I'll worry about getting that gcc into the build, but will it work
> for
> > me on a binary basis?
> >
>
> I used arm-none-eabi to compile my loader for the BeagleBoard so as to
> get rid of the linux-specific stuff by default. But maybe you should
> define something like arm-freebsd-eabi in gcc's build configuration?
>

The arm-none-eabi will give you stuff for bare-metal applications, and the
arm-linux-eabi (or arm-linux-gnueabi)  will give you stuff for linux. For FreeBSD now,
from what I've read there is no arm-freebsd-eabi; I tried that when I built GCC 4.4.1
and it wouldn't accept it.

What I've build is arm-unknown-freebsd, although the "unknown" part could
be ommited. Please bear with me while I look for the URL I found the naming
conventions...

Thanks,
Vasi



     

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Guillaume Ballet]

> The arm-none-eabi will give you stuff for bare-metal applications, and the
> arm-linux-eabi (or arm-linux-gnueabi)  will give you stuff for linux. For FreeBSD now,
> from what I've read there is no arm-freebsd-eabi; I tried that when I built GCC 4.4.1
> and it wouldn't accept it.

Yeah, you would have to explicitely create it by tweaking the platform
definition files.

> What I've build is arm-unknown-freebsd, although the "unknown" part could
> be ommited. Please bear with me while I look for the URL I found the naming
> conventions...

That could actually be what we are looking for. Do you know if this
definition uses eabi?
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Chuck Robey-5]

Vassilis Laganakos wrote:

>
>
>>> Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?
>
>>> That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
>>> processor until 4.3.0.  I was able to build a cross-gcc easily using a target
>> of
>>> "arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
>>> FreeBSD.  I'll worry about getting that gcc into the build, but will it work
>> for
>>> me on a binary basis?
>>>
>> I used arm-none-eabi to compile my loader for the BeagleBoard so as to
>> get rid of the linux-specific stuff by default. But maybe you should
>> define something like arm-freebsd-eabi in gcc's build configuration?
>>

Thanks SO much, giving me the info on the targets was the item I most badly
needed, but you're the only fella who addressed that directly.  Basically, you
got rid of my single remaining problem (at the pre-build level, at least), it's
something that no amount of Googling would show me.

I'm so damned pleased!  From all the hints I got, there appears to be
vanishingly little chance of our tree going to gcc-4.3.+, because everyone wants
to use LLVM.  I don't stand against that, but I don't want to wait, either, and
(as of today) llvm doesn't support the Cortex-A8 (it will soon).

Actually, I'm rereading my Dragon book, so I can understand the llvm better.  It
does look to be better organized than gcc, from first glance.  I can't find the
code (outside ports) to build llvm, do you have any idea where it is?  If it's
in a p4 archive, you have a URL for it?

> The arm-none-eabi will give you stuff for bare-metal applications, and the
> arm-linux-eabi (or arm-linux-gnueabi)  will give you stuff for linux. For FreeBSD now,
> from what I've read there is no arm-freebsd-eabi; I tried that when I built GCC 4.4.1
> and it wouldn't accept it.
>
> What I've build is arm-unknown-freebsd, although the "unknown" part could
> be ommited. Please bear with me while I look for the URL I found the naming
> conventions...
>
> Thanks,
> Vasi
>
>
>
>      
>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Chuck Robey-5]

Vassilis Laganakos wrote:

>
>
>>> Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?
>
>>> That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
>>> processor until 4.3.0.  I was able to build a cross-gcc easily using a target
>> of
>>> "arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
>>> FreeBSD.  I'll worry about getting that gcc into the build, but will it work
>> for
>>> me on a binary basis?
>>>
>> I used arm-none-eabi to compile my loader for the BeagleBoard so as to
>> get rid of the linux-specific stuff by default. But maybe you should
>> define something like arm-freebsd-eabi in gcc's build configuration?
>>

Thanks SO much, giving me the info on the targets was the item I most badly
needed, but you're the only fella who addressed that directly.  Basically, you
got rid of my single remaining problem (at the pre-build level, at least), it's
something that no amount of Googling would show me.

I'm so damned pleased!  From all the hints I got, there appears to be
vanishingly little chance of our tree going to gcc-4.3.+, because everyone wants
to use LLVM.  I don't stand against that, but I don't want to wait, either, and
(as of today) llvm doesn't support the Cortex-A8 (it will soon).

Actually, I'm rereading my Dragon book, so I can understand the llvm better.  It
does look to be better organized than gcc, from first glance.  I can't find the
code (outside ports) to build llvm, do you have any idea where it is?  If it's
in a p4 archive, you have a URL for it?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
FORGET about the llvm question, I just saw the mail about it being imported to svn.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> The arm-none-eabi will give you stuff for bare-metal applications, and the
> arm-linux-eabi (or arm-linux-gnueabi)  will give you stuff for linux. For FreeBSD now,
> from what I've read there is no arm-freebsd-eabi; I tried that when I built GCC 4.4.1
> and it wouldn't accept it.
>
> What I've build is arm-unknown-freebsd, although the "unknown" part could
> be ommited. Please bear with me while I look for the URL I found the naming
> conventions...
>
> Thanks,
> Vasi
>
>
>
>      
>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Vassilis Laganakos]

Hi Mark,

> What configuration options are you using for an ARM cross compiler?
>
Please bear with me while I put everything in a wiki/log page to be accessible
- and visible for inspection :o) - to everyone. (should I submit this to the
freebsd/arm page as a howto as well?). Have to repeat though the procedure
now that I switched to HEAD.


> The cross compile fails for me when it gets to the arm "multilib" build.
> I tried with gcc44 and gcc45. I am trying one last time with the configuration
> option "--disable-multilib", but I am not holding my breath.
>
I had faced the same problem. The problem is possibly something that
was reported as a bug against gcc, that involves acx.m4  getting the wrong path
to ${host_subddir} 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40191

What I did was hand editing the Makefile and changing the offended variable
$host_subdir to what it should be. For me it was "host-i386-unknown-freebsd"
Then restarted gmake. So it doesn't seem to be --multilib, and although I had
thought exactly the same (disabling it!) it looks like it is required.

You will come across a few more sub-packages that face the same problem.
The treatment is the same. :o)

It will ultimately stop (fail) when it will try to find libc... That's where I am now :o)

Kind regards,
Vassilis L.


     

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Vassilis Laganakos]

> > What I've build is arm-unknown-freebsd, although the "unknown" part could
> > be ommited. Please bear with me while I look for the URL I found the naming
> > conventions...
>
> That could actually be what we are looking for. Do you know if this
> definition uses eabi?
>
I think in GCC 4.3 is where you get ARMv7 architecture support, (see
http://gcc.gnu.org/gcc-4.3/changes.html), which is EABI and at GCC 4.4
you have "EABI-compatible profiling interface for EABI targets." (again see
http://gcc.gnu.org/gcc-4.4/changes.html).

So I've chosen to work on 4.4 just to be sure, and it also supports Cortex-A9, as
well as VFPv3 (yeah!).

If you meant whether "arm-unknown-freebsd" implies "arm-unknown-freebsd-eabi"
(and I've been mumbling about sth else :o) ) that answer I think is "yes".  Of course,
if I'm mistaken please someone correct me!

Kind regards,
Vassilis L.



     

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Stanislav Sedov-3]

On Thu, 04 Jun 2009 12:22:33 -0400
Chuck Robey <[hidden email]> mentioned:

>
> Actually, I'm rereading my Dragon book, so I can understand the llvm better.  It
> does look to be better organized than gcc, from first glance.  I can't find the
> code (outside ports) to build llvm, do you have any idea where it is?  If it's
> in a p4 archive, you have a URL for it?

Check this page: http://wiki.freebsd.org/BuildingFreeBSDWithClang

--
Stanislav Sedov
ST4096-RIPE

[Chuck Robey-5]

Guillaume Ballet wrote:

>> Doesn't xdev build the 4.2.1 version of gcc, like what's in the tree now?
>> That's unacceptable to me, gcc didn't bring in support for the Cortex-A8
>> processor until 4.3.0.  I was able to build a cross-gcc easily using a target of
>> "arm-linux-gnueabi", but I'm not sure if that sort of gcc will do for building
>> FreeBSD.  I'll worry about getting that gcc into the build, but will it work for
>> me on a binary basis?
>>
>
> I used arm-none-eabi to compile my loader for the BeagleBoard so as to
> get rid of the linux-specific stuff by default. But maybe you should
> define something like arm-freebsd-eabi in gcc's build configuration?

Always a thing of extremes for me.  I know Makefiles pretty darned well, both
the BSD and teh GNU sort, but as well as I know them, that's how BADLY I
misunderstand anything dealing with those configure scripts.  I can't even begin
to pick apart the code for those things.  Irritates me, because if I find a
problem in a makefile, I pop out an answer with the greatest of ease, but if
it's well coded so that configure reruns itself immediately if there's any
change in the makefile, then it has to run configure, and I'm basically utterly
screwed.  I like our BSD build system, not a configure script in sight!

However, now that I understand that I can use arm-none-eabi, I am pretty sure I
can do things, and the configure scripts in gcc aren't so well engineered to
force me to deal with them like that.  If I can deal with a configure script as
a shell script, I can do that, it's dealing with it as m4 macros that leaves me
cold.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Mark Tinguely]

You should talk to the tools team about the port. A person can get a
basic gcc4.5 cross compiler (gmake all-gcc / install-gcc) without the
libraries but the kernel sources expects a FreeBSD extended kernel
(a missing __FreeBSD_cc_version will pop up right away). There are
files in svn/gnu/usr.bin/cc/cc_tools that are new and svn/contrib/gcc/config
that differ from the gcc4.5 sources.

I tip my hat to the tools team to get the gnu software to natively and
cross compile and install in a normal location.

--Mark.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Mark Tinguely]

In case any of the Cortex/v7 projects or anyone else is interested, I have
gcc-4.5 cross compiling the current GUMSTIX kernel on a i386 FreeBSD 6.4
computer (QEMU runs better under FreeBSD 6.4) - I have not tried the libs
yet to a "build world".

The kernel sources need some FreeBSD (format and at least one built-in define)
extensions to compile that are not in the standard gcc. Besides the extensions
that I copied over the code to put the binaries in the standard, reasonable
places /usr/cross/libexec/cc1, for example).

Gcc 4.5 -O option found a few inline and structure warnings, that required
either the removal of the -O option or -Werror option for these files.
I chose to remove the -Werror. The warnings are:

wanted to add parenthesis around the &:
ddb/db_ps.c

-O detects inline optimizations in the files:
devfs_vnops.c pseudofs_vnops.c  kern_descrip.c kern_jail.c sys_pipe.c
tty.c uipc_mbuf.c vfs_default.c vfs_lookup.c vfs_mount.c vfs_syscalls.c
ffs_snapshot.c trap.c pmap.c

variably modified in the definition of a structure (and some inline opt):
ufs_dirhash.c ufs_inode.c ufs_lookup.c  ufs_vfsops.c ufs_vnops.c

I made changes to the gcc-4.5-20090528 directory and the build directory.
I will look at the libraries too.

--Mark Tinguely.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Vassilis Laganakos]

> In case any of the Cortex/v7 projects or anyone else is interested, I have
> gcc-4.5 cross compiling the current GUMSTIX kernel on a i386 FreeBSD 6.4
> computer (QEMU runs better under FreeBSD 6.4) - I have not tried the libs
> yet to a "build world".
>
That's nice Mark, good job :o)

> The kernel sources need some FreeBSD (format and at least one built-in define)
> extensions to compile that are not in the standard gcc. Besides the extensions
> that I copied over the code to put the binaries in the standard, reasonable
> places /usr/cross/libexec/cc1, for example).
>
> Gcc 4.5 -O option found a few inline and structure warnings, that required
> either the removal of the -O option or -Werror option for these files.
> I chose to remove the -Werror. The warnings are:
>
> wanted to add parenthesis around the &:
> ddb/db_ps.c
>
> -O detects inline optimizations in the files:
> devfs_vnops.c pseudofs_vnops.c  kern_descrip.c kern_jail.c sys_pipe.c
> tty.c uipc_mbuf.c vfs_default.c vfs_lookup.c vfs_mount.c vfs_syscalls.c
> ffs_snapshot.c trap.c pmap.c
>
> variably modified in the definition of a structure (and some inline opt):
> ufs_dirhash.c ufs_inode.c ufs_lookup.c  ufs_vfsops.c ufs_vnops.c
>

I don't know what are the changes from previous versions of GCC with the trunk.
Maybe the release notes have more info on this....

> I made changes to the gcc-4.5-20090528 directory and the build directory.
> I will look at the libraries too.
>
Cool!

Kind regards,
Vassilis L.



     

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Mark Tinguely]

>  I don't know what are the changes from previous versions of GCC with the trunk.
>  Maybe the release notes have more info on this....

FreeBSD compiler has a variable defined into it that the kernel sources
expect to find, it has extended format commands, and it modifies
gcc/gcc.c to look for the support programs in normal places.

>  > I made changes to the gcc-4.5-20090528 directory and the build directory.
>  > I will look at the libraries too.
>  >
>  Cool!

I am still using modified GNU make file. Static libraries can cross
compile an application to ARM but I gave up on configure/gmake on
libmudflap. My library compile process became a hacking in the configure
files. I was just walking around the problems as they popped up. Had
I read and understood all the configure options, maybe it would have
gone smoother. The "-Werror" complaints and "xgcc -E" as a pre-processor
command are the two biggest problem in the library compilation process.

Once we have a cross compiler that can make a kernel, it seems a waste
of time to keep going with the configure/gmake route. Your idea of
moving the sources over to the head/contrib/gcc and editing the BSD
make files in head/gnu/usr.bin/cc is the way to go because making
the compiler from sources is part of the cross build world.

I diff-ed the sources from the GNU original (4.2.1 if memory serves me
right) sources and filled in the missing pieces into the GCC 4.5 files.
Some things have already been put into GCC 4.5, some areas seemed re-written.
I was mostly interested in getting the FreeBSD extensions in. I can give you
diff of my sources against GCC 4.5 original code or tar up both the source
and build directory.  The changes would be simular for GCC 4.4.

There is nothing special about GCC 4.5, I just took the most recent source
that is available. Also, I just blindly copied the freebsd* header files
from head source into GCC 4.5. The real way of doing this is to edit up
the existing GCC 4.5 header files and add the new items. I did that with
a couple that are used in the ARM build.

The sources in the gcc support library files are not changed; it would
just take some BSD make file editing to get them to compile under the
head directory.

--Mark.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"

[Vassilis Laganakos]

Hi Mark,

Sorry for the delayed reply, I was in transitional period, moving things around.


> >  I don't know what are the changes from previous versions of GCC with the  trunk.
> >  Maybe the release notes have more info on this....
>
> FreeBSD compiler has a variable defined into it that the kernel sources
> expect to find, it has extended format commands, and it modifies
> gcc/gcc.c to look for the support programs in normal places.
>
Oh ok,  I assume the info is in the handbook (or in the sources :) )

> >  > I made changes to the gcc-4.5-20090528 directory and the build directory.
> >  > I will look at the libraries too.
> >  >
> >  Cool!
>
> I am still using modified GNU make file. Static libraries can cross
> compile an application to ARM but I gave up on configure/gmake on
> libmudflap. My library compile process became a hacking in the configure
> files. I was just walking around the problems as they popped up. Had
> I read and understood all the configure options, maybe it would have
> gone smoother. The "-Werror" complaints and "xgcc -E" as a pre-processor
> command are the two biggest problem in the library compilation process.
>

libmudflap gave me trouble too. Went through quite a few web pages to
get my head around, still I'm not sure what to do to config things the way I want...
I guess the -Werror would be kind of expected in such transitions.

> Once we have a cross compiler that can make a kernel, it seems a waste
> of time to keep going with the configure/gmake route. Your idea of
> moving the sources over to the head/contrib/gcc and editing the BSD
> make files in head/gnu/usr.bin/cc is the way to go because making
> the compiler from sources is part of the cross build world.
>
Thanks, let's hope it works, and it is not crazy difficult to do...

> I diff-ed the sources from the GNU original (4.2.1 if memory serves me
> right) sources and filled in the missing pieces into the GCC 4.5 files.
> Some things have already been put into GCC 4.5, some areas seemed re-written.
> I was mostly interested in getting the FreeBSD extensions in. I can give you
> diff of my sources against GCC 4.5 original code or tar up both the source
> and build directory.  The changes would be simular for GCC 4.4.
>
That would be very helpful! Is the number of missing pieces huge?

> There is nothing special about GCC 4.5, I just took the most recent source
> that is available. Also, I just blindly copied the freebsd* header files
> from head source into GCC 4.5. The real way of doing this is to edit up
> the existing GCC 4.5 header files and add the new items. I did that with
> a couple that are used in the ARM build.
>
True, I think we have to merge the current header files with the new header
files to have the new items in. Also, some things in the 4.4 header arm files
seem to be doing some things in a way different than the linux-gnueabi way
that I'm more familiar with. Trying to understand :)  (once I have my stuff working
again I will *finally* put the info in a wiki...)

> The sources in the gcc support library files are not changed; it would
> just take some BSD make file editing to get them to compile under the
> head directory.
>
Ok.

> --Mark.

Once I get my hands back on this, I'll post here the progress and keep you informed.

Many thanks,
Vassilis L.



     

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"