powerpc/sparc problems

powerpc/sparc problems

[Felix Zielcke]

David are you still there?
And also anyone who has access to a powerpc machine (and experience)?

In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
can't be found in the grub-ieee1275 build on powerpc and also sparc.

Jordi already noticed this with the 1.96+20090721-4 IIRC and now other
people noticed this with 1.97~beta3
AFAICS there wasn't anything relevant changed on our side, so seems to
be a gcc issue.

`__ashldi3' is listed in include/grub/powerpc/libgcc.h and `__bswapsi2'
in the sparc64 header.
But something has now changed that this isn't enough anymore, at least
in Debian.

We used gcc 4.3.3 at the time Jordi noticed this and now switched to
gcc-4.4.1.

And David we still have this sparc bug open, which I forwared to
grub-devel:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030


-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: powerpc/sparc problems

[David Miller]

From: Felix Zielcke <fzielcke@z-51.de>
Date: Mon, 12 Oct 2009 10:55:46 +0200

> And David we still have this sparc bug open, which I forwared to
> grub-devel:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030

I'm about to head to Tokyo for the Linux Kernel summit and
the Japan Linux Symposium so I'll be out of commission for
a few weeks again.

Right when I'm about to get back to even trying out the latest
GRUB I hit another conference or major trip.

So please do not make me the critical link in the chain for Sparc
things until later this year.  If these things are to be fixed sooner
than that, someone else will need to look into them.

Re: powerpc/sparc problems

[Felix Zielcke]

Am Montag, den 12.10.2009, 02:05 -0700 schrieb David Miller:
> From: Felix Zielcke <fzielcke@z-51.de>
> Date: Mon, 12 Oct 2009 10:55:46 +0200
> 
> > And David we still have this sparc bug open, which I forwared to
> > grub-devel:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
> 
> I'm about to head to Tokyo for the Linux Kernel summit and
> the Japan Linux Symposium so I'll be out of commission for
> a few weeks again.
> 
> Right when I'm about to get back to even trying out the latest
> GRUB I hit another conference or major trip.
> 
> So please do not make me the critical link in the chain for Sparc
> things until later this year.  If these things are to be fixed sooner
> than that, someone else will need to look into them.

Thanks for looking into this, even if it's not now :)
Unfortunately AFAIR you're the only sparc guy on the list here or am I
wrong?

For me this isn't that important. For the 1.97 release I wouldn't anyway
declare sparc as a fully stable port.
And in Debian powerpc and sparc isn't that much used.


-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

David Miller wrote:
> From: Felix Zielcke <fzielcke@z-51.de>
> Date: Mon, 12 Oct 2009 10:55:46 +0200
>
>   
>> And David we still have this sparc bug open, which I forwared to
>> grub-devel:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
>>     
>
> I'm about to head to Tokyo for the Linux Kernel summit and
> the Japan Linux Symposium so I'll be out of commission for
> a few weeks again.
>
> Right when I'm about to get back to even trying out the latest
> GRUB I hit another conference or major trip.
>
> So please do not make me the critical link in the chain for Sparc
> things until later this year.  If these things are to be fixed sooner
> than that, someone else will need to look into them.
>
>   
How accurate is qemu-system-sparc64? We could have an automated
regression testing for it - this should keep grub-sparc reasonably
working and permit minor (and perhaps even major) developpement
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: powerpc/sparc problems

[David Miller]

From: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
Date: Mon, 12 Oct 2009 11:56:23 +0200

> How accurate is qemu-system-sparc64? We could have an automated
> regression testing for it - this should keep grub-sparc reasonably
> working and permit minor (and perhaps even major) developpement

Personally, I don't know as I've never used it.

Re: powerpc/sparc problems

[Felix Zielcke]

Am Montag, den 12.10.2009, 11:56 +0200 schrieb Vladimir 'phcoder'
Serbinenko:
> How accurate is qemu-system-sparc64?

The qemu status page says `Dev only' in red.
Both Debian lenny and testing sparc isos don't boot. It hangs at
`Welcome to OpenBIOS'
With qemu-system-sparc the cd boots but then complains that only 64bit
sparc systems are now supported.

The OpenSolaris sparc CD directly goes to an OpenFirmware prompt with
-sparc64
With -sparc it prints some stuff and then `Unsupported image format'

-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

Felix Zielcke wrote:
> David are you still there?
> And also anyone who has access to a powerpc machine (and experience)?
>
> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
> can't be found in the grub-ieee1275 build on powerpc and also sparc.
>
>   
I've come across the same problem when porting grub2 to MIPS. The
solution is the attached patch. I'll test it today on my imac g3
> Jordi already noticed this with the 1.96+20090721-4 IIRC and now other
> people noticed this with 1.97~beta3
> AFAICS there wasn't anything relevant changed on our side, so seems to
> be a gcc issue.
>
> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and `__bswapsi2'
> in the sparc64 header.
> But something has now changed that this isn't enough anymore, at least
> in Debian.
>
> We used gcc 4.3.3 at the time Jordi noticed this and now switched to
> gcc-4.4.1.
>
> And David we still have this sparc bug open, which I forwared to
> grub-devel:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
>
>
>   


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 


[-- Attachment #2: ppcfix.diff --]
[-- Type: text/x-patch, Size: 1425 bytes --]

diff --git a/include/grub/powerpc/libgcc.h b/include/grub/powerpc/libgcc.h
index ea4b073..0ff8964 100644
--- a/include/grub/powerpc/libgcc.h
+++ b/include/grub/powerpc/libgcc.h
@@ -16,9 +16,9 @@
  *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
  */
 
-void EXPORT_FUNC (memset) (void) __attribute__ ((weak));
-void EXPORT_FUNC (__ashldi3) (void) __attribute__ ((weak));
-void EXPORT_FUNC (__ashrdi3) (void) __attribute__ ((weak));
-void EXPORT_FUNC (__lshrdi3) (void) __attribute__ ((weak));
-void EXPORT_FUNC (__trampoline_setup) (void) __attribute__ ((weak));
-void EXPORT_FUNC (__ucmpdi2) (void) __attribute__ ((weak));
+void EXPORT_FUNC (memset) (void);
+void EXPORT_FUNC (__ashldi3) (void);
+void EXPORT_FUNC (__ashrdi3) (void);
+void EXPORT_FUNC (__lshrdi3) (void);
+void EXPORT_FUNC (__trampoline_setup) (void);
+void EXPORT_FUNC (__ucmpdi2) (void);
diff --git a/include/grub/sparc64/libgcc.h b/include/grub/sparc64/libgcc.h
index 5d18c5c..6a3d804 100644
--- a/include/grub/sparc64/libgcc.h
+++ b/include/grub/sparc64/libgcc.h
@@ -21,7 +21,7 @@
 void EXPORT_FUNC (memset) (void);
 
 typedef int SItype __attribute__ ((mode (SI)));
-SItype EXPORT_FUNC (__bswapsi2) (SItype) __attribute__ ((weak));
+SItype EXPORT_FUNC (__bswapsi2) (SItype);
 
 typedef int DItype __attribute__ ((mode (DI)));
-DItype EXPORT_FUNC (__bswapdi2) (DItype) __attribute__ ((weak));
+DItype EXPORT_FUNC (__bswapdi2) (DItype);

Re: powerpc/sparc problems

[Felix Zielcke]

Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke:

> And also anyone who has access to a powerpc machine (and experience)?

Oh and I forgot to mention, that the powerpc version doestn't even build
now with 1.97~beta4:

_restgpr_31_x in boot is not defined

Full build log is here:
https://buildd.debian.org/fetch.cgi?&pkg=grub2&ver=1.97~beta4-1&arch=powerpc&stamp=1254771207&file=log


-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: powerpc/sparc problems

[rubisher]

Felix Zielcke wrote:
> Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke:
> 
>> And also anyone who has access to a powerpc machine (and experience)?
> 
> Oh and I forgot to mention, that the powerpc version doestn't even build
> now with 1.97~beta4:
> 
> _restgpr_31_x in boot is not defined
> 
> Full build log is here:
> https://buildd.debian.org/fetch.cgi?&pkg=grub2&ver=1.97~beta4-1&arch=powerpc&stamp=1254771207&file=log
> 
> 
Hello Felix,

I now reach to install grub for my debian unstable installation on my ibm p5 lpar (the unstable 1.97~beta3-1) but 
unfortunately failed to boot because failed to find a symbol (sorry I forget to take note of it).
I so jump to svn (release 2641 and today 2642); no luck always this same error:

_restgpr_31_x in boot is not defined

I so re-try to build the deb pkg 1.97~beta3-1; too bad again this same error???

Could it be so a gcc issue (debian build of 1.97~beta3-1 was with gcc-4.4 4.4.1-3; here I rebuild with gcc-4.4 4.4.1-6 and 
even most recent 4.4.2-1?)

I so try to come back to gcc 4.3 and this time it build fine (not yet tested if this one boot, sorry).

Any idea?

Tia,
	j.

ps: I also tried to test bean123 git branch (grab this Oct 19) but this failed to build early to compile normal/main.c (gcc 
didn't find some references to some grub_... struct and fnct)

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

rubisher wrote:
> Felix Zielcke wrote:
>> Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke:
>>
>>> And also anyone who has access to a powerpc machine (and experience)?
>>
>> Oh and I forgot to mention, that the powerpc version doestn't even build
>> now with 1.97~beta4:
>>
>> _restgpr_31_x in boot is not defined
>>
>> Full build log is here:
>> https://buildd.debian.org/fetch.cgi?&pkg=grub2&ver=1.97~beta4-1&arch=powerpc&stamp=1254771207&file=log
>>
>>
>>
> Hello Felix,
>
> I now reach to install grub for my debian unstable installation on my
> ibm p5 lpar (the unstable 1.97~beta3-1) but unfortunately failed to
> boot because failed to find a symbol (sorry I forget to take note of it).
> I so jump to svn (release 2641 and today 2642); no luck always this
> same error:
>
> _restgpr_31_x in boot is not defined
From the name and what we discussed with Felix on IRC I guess this
symbol is a counterpart of MIPS' __gnu_local_gp which is used in
handling GOT relocations which allow usage of a single instruction to
load 32-bit address instead of usual 2 but require linker to generate
additional table. You can look into kern/mips/dl.c of my mips branch for
details. Similar approach can be used for powerpc. I suppose it would be
a good idea to put this code to kern/got.c instead of kern/<arch>. But
such a change just before release is too big.
Since it correspond to a recent change in gcc behaviour perhaps an old
behaviour can be restored with an option.
>
> I so re-try to build the deb pkg 1.97~beta3-1; too bad again this same
> error???
>
> Could it be so a gcc issue (debian build of 1.97~beta3-1 was with
> gcc-4.4 4.4.1-3; here I rebuild with gcc-4.4 4.4.1-6 and even most
> recent 4.4.2-1?)
>
> I so try to come back to gcc 4.3 and this time it build fine (not yet
> tested if this one boot, sorry).
>
> Any idea?
>
> Tia,
>     j.
>
> ps: I also tried to test bean123 git branch (grab this Oct 19) but
> this failed to build early to compile normal/main.c (gcc didn't find
> some references to some grub_... struct and fnct)
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: powerpc/sparc problems

[rubisher]

Hello Vladimir,

Vladimir 'phcoder' Serbinenko wrote:
> rubisher wrote:
>> Felix Zielcke wrote:
>>> Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke:
>>>
>>>> And also anyone who has access to a powerpc machine (and experience)?
>>> Oh and I forgot to mention, that the powerpc version doestn't even build
>>> now with 1.97~beta4:
>>>
>>> _restgpr_31_x in boot is not defined
>>>
>>> Full build log is here:
>>> https://buildd.debian.org/fetch.cgi?&pkg=grub2&ver=1.97~beta4-1&arch=powerpc&stamp=1254771207&file=log
>>>
>>>
>>>
>> Hello Felix,
>>
>> I now reach to install grub for my debian unstable installation on my
>> ibm p5 lpar (the unstable 1.97~beta3-1) but unfortunately failed to
>> boot because failed to find a symbol (sorry I forget to take note of it).
>> I so jump to svn (release 2641 and today 2642); no luck always this
>> same error:
>>
>> _restgpr_31_x in boot is not defined
>>From the name and what we discussed with Felix on IRC I guess this
> symbol is a counterpart of MIPS' __gnu_local_gp which is used in
> handling GOT relocations which allow usage of a single instruction to
> load 32-bit address instead of usual 2 but require linker to generate
> additional table. You can look into kern/mips/dl.c of my mips branch for
> details. Similar approach can be used for powerpc. I suppose it would be
> a good idea to put this code to kern/got.c instead of kern/<arch>. But
> such a change just before release is too big.
> Since it correspond to a recent change in gcc behaviour perhaps an old
> behaviour can be restored with an option.

I well reach to grab your mips git tree, but I don't have deep knowledge in programming, so I will need a bit of time to 
analyse ;<)

Tx a lot,
	J.

>> I so re-try to build the deb pkg 1.97~beta3-1; too bad again this same
>> error???
>>
>> Could it be so a gcc issue (debian build of 1.97~beta3-1 was with
>> gcc-4.4 4.4.1-3; here I rebuild with gcc-4.4 4.4.1-6 and even most
>> recent 4.4.2-1?)
>>
>> I so try to come back to gcc 4.3 and this time it build fine (not yet
>> tested if this one boot, sorry).
>>
>> Any idea?
>>
>> Tia,
>>     j.
>>
>> ps: I also tried to test bean123 git branch (grab this Oct 19) but
>> this failed to build early to compile normal/main.c (gcc didn't find
>> some references to some grub_... struct and fnct)
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
> 
> 

Re: powerpc/sparc problems

[Bean]

On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke <fzielcke@z-51.de> wrote:
> David are you still there?
> And also anyone who has access to a powerpc machine (and experience)?
>
> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
> can't be found in the grub-ieee1275 build on powerpc and also sparc.
>
> Jordi already noticed this with the 1.96+20090721-4 IIRC and now other
> people noticed this with 1.97~beta3
> AFAICS there wasn't anything relevant changed on our side, so seems to
> be a gcc issue.
>
> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and `__bswapsi2'
> in the sparc64 header.
> But something has now changed that this isn't enough anymore, at least
> in Debian.
>
> We used gcc 4.3.3 at the time Jordi noticed this and now switched to
> gcc-4.4.1.
>
> And David we still have this sparc bug open, which I forwared to
> grub-devel:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030

Hi,

Try my branch, it includes the libgcc functions in grub instead of
rely on external library. It builds and run properly for
powerpc-ieee1275 last time I check.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: powerpc/sparc problems

[David Miller]

From: Bean <bean123ch@gmail.com>
Date: Mon, 12 Oct 2009 17:58:42 +0800

> Try my branch, it includes the libgcc functions in grub instead of
> rely on external library. It builds and run properly for
> powerpc-ieee1275 last time I check.

Good luck when the compiler changes the interface and/or semantics of
these routines in a future version.  Will you enumerate your in-tree
copies by gcc version with ifdefs or similar?

That's why gcc and it's libgcc are distributed together, and gcc
configures itself to link with a specific libgcc and only that libgcc.

This whole things perfectly fine in GRUB when I implemented the
necessary machinery to find if these routines exist in libgcc at
configure time and to reference them properly in the build.

They've merely been broken meanwhile and someone just needs to rectify
that regression.

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

David Miller wrote:
> From: Bean <bean123ch@gmail.com>
> Date: Mon, 12 Oct 2009 17:58:42 +0800
>
>   
>> Try my branch, it includes the libgcc functions in grub instead of
>> rely on external library. It builds and run properly for
>> powerpc-ieee1275 last time I check.
>>     
>
> Good luck when the compiler changes the interface and/or semantics of
> these routines in a future version.  Will you enumerate your in-tree
> copies by gcc version with ifdefs or similar?
>
> That's why gcc and it's libgcc are distributed together, and gcc
> configures itself to link with a specific libgcc and only that libgcc.
>
> This whole things perfectly fine in GRUB when I implemented the
> necessary machinery to find if these routines exist in libgcc at
> configure time and to reference them properly in the build.
>
> They've merely been broken meanwhile and someone just needs to rectify
> that regression.
>
>
>   
It was removed as a part of following commit
2009-06-10  Pavel Roskin  <proski@gnu.org>

        * configure.ac: Use -nostdlib when probing for the target.  It
        should not be required to have libc for the target.

        * configure.ac: Remove checks for __bswapsi2 and __bswapdi2,
        they fail without libc headers for the target.
        * include/grub/powerpc/libgcc.h: Use weak attribute for all
        exports.
        * include/grub/sparc64/libgcc.h: Likewise.  Don't use
        preprocessor conditionals.

Do you think we should just revert it?
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: powerpc/sparc problems

[David Miller]

From: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
Date: Mon, 12 Oct 2009 12:26:04 +0200

> It was removed as a part of following commit
> 2009-06-10  Pavel Roskin  <proski@gnu.org>
> 
>         * configure.ac: Use -nostdlib when probing for the target.  It
>         should not be required to have libc for the target.
> 
>         * configure.ac: Remove checks for __bswapsi2 and __bswapdi2,
>         they fail without libc headers for the target.
>         * include/grub/powerpc/libgcc.h: Use weak attribute for all
>         exports.
>         * include/grub/sparc64/libgcc.h: Likewise.  Don't use
>         preprocessor conditionals.
> 
> Do you think we should just revert it?

Probably.

Re: powerpc/sparc problems

[Pavel Roskin]

On Mon, 2009-10-12 at 03:28 -0700, David Miller wrote:
> > Do you think we should just revert it?
> 
> Probably.

The purpose of the patch was to remove the requirement that the target
libc development package is present.  That's a common situation for
x86_64 systems that may have a 32-bit capable compiler, and maybe the
32-bit libc installed as a dependency of a 32-bit package (e.g. wine),
but no the files necessary to link against the 32-bit libc.

I don't know why the checks need to be reinstated, but if it's really
needed to be done, we could use the trick described in the gcc manual:

`-print-libgcc-file-name'
     Same as `-print-file-name=libgcc.a'.

     This is useful when you use `-nostdlib' or `-nodefaultlibs' but
     you do want to link with `libgcc.a'.  You can do

          gcc -nostdlib FILES... `gcc -print-libgcc-file-name`

This way, it should be possible to check if the functions are in libgcc
without requiring libc.

-- 
Regards,
Pavel Roskin

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

Pavel Roskin wrote:
> On Mon, 2009-10-12 at 03:28 -0700, David Miller wrote:
>   
>>> Do you think we should just revert it?
>>>       
>> Probably.
>>     
>
> The purpose of the patch was to remove the requirement that the target
> libc development package is present.  That's a common situation for
> x86_64 systems that may have a 32-bit capable compiler, and maybe the
> 32-bit libc installed as a dependency of a 32-bit package (e.g. wine),
> but no the files necessary to link against the 32-bit libc.
>
> I don't know why the checks need to be reinstated, but if it's really
> needed to be done, we could use the trick described in the gcc manual:
>
> `-print-libgcc-file-name'
>      Same as `-print-file-name=libgcc.a'.
>
>      This is useful when you use `-nostdlib' or `-nodefaultlibs' but
>      you do want to link with `libgcc.a'.  You can do
>
>           gcc -nostdlib FILES... `gcc -print-libgcc-file-name`
>
> This way, it should be possible to check if the functions are in libgcc
> without requiring libc.
>   
On sparc64, ppc and mips we compile using -nostdlib -lgcc
-static-libgcc. I would prefer to use the same method in check and
actual compile.

Another idea: we could use nm to generate list of functions in libgcc.
This way we acquire robustness against new functions in gcc but it may
increase the kernel size. PPC and sparc are less used and hence more
prone to problems and size on them doesn't matter so much as it does on
i386-pc. So I would prefer to buy robustness at cost of size
I haven't made up my mind for mips(el) yet since the target is to be
burned in flash where space is limited.
Another solution would be to enumerate symbols in all modules and
compare them to libgcc symbols and include only needed ones but it has a
major drawback of potentially breaking external and separately compiled
modules which is especially problematic if core is burned in flash.

-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: powerpc/sparc problems

[Pavel Roskin]

On Mon, 2009-10-12 at 17:45 +0200, Vladimir 'phcoder' Serbinenko wrote:
> On sparc64, ppc and mips we compile using -nostdlib -lgcc
> -static-libgcc. I would prefer to use the same method in check and
> actual compile.

Ideally, we should use those flags on all architectures.

-- 
Regards,
Pavel Roskin

Re: powerpc/sparc problems

[David Miller]

From: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
Date: Mon, 12 Oct 2009 17:45:33 +0200

> Another idea: we could use nm to generate list of functions in libgcc.

Yes, 'nm' would work too.

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

David Miller wrote:
> From: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
> Date: Mon, 12 Oct 2009 12:26:04 +0200
>
>   
>> It was removed as a part of following commit
>> 2009-06-10  Pavel Roskin  <proski@gnu.org>
>>
>>         * configure.ac: Use -nostdlib when probing for the target.  It
>>         should not be required to have libc for the target.
>>
>>         * configure.ac: Remove checks for __bswapsi2 and __bswapdi2,
>>         they fail without libc headers for the target.
>>         * include/grub/powerpc/libgcc.h: Use weak attribute for all
>>         exports.
>>         * include/grub/sparc64/libgcc.h: Likewise.  Don't use
>>         preprocessor conditionals.
>>
>> Do you think we should just revert it?
>>     
>
> Probably.
>
>   
The methods discussed in this thread are good but aren't for release. So
I just reverted Pavel's commit


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: powerpc/sparc problems

[Pavel Roskin]

On Thu, 2009-10-15 at 13:58 +0200, Vladimir 'phcoder' Serbinenko wrote:

> The methods discussed in this thread are good but aren't for release. So
> I just reverted Pavel's commit

My cross-build for sparc64 fails now:

__bswapsi2 in fat is not defined

This can be traced to the following part of config.log:

configure:7314: checking for __bswapsi2
configure:7370: sparc64-linux-uclibc-gcc -o conftest -Wall -W -Wshadow
-Wpointer-arith -Wmissing-prototypes                  -Wundef
-Wstrict-prototypes -g -Os -m64 -fno-stack-protector -Werror -nostdlib
-Wl,--defsym,___main=0x8100   -m64 conftest.c  >&5
In file included
from /opt/sparc/usr/lib/gcc/sparc64-linux-uclibc/4.3.3/include-fixed/syslimits.h:7,

from /opt/sparc/usr/lib/gcc/sparc64-linux-uclibc/4.3.3/include-fixed/limits.h:11,
                 from conftest.c:38:
/opt/sparc/usr/lib/gcc/sparc64-linux-uclibc/4.3.3/include-fixed/limits.h:122:61: error: no include path in which to search for limits.h
cc1: warnings being treated as errors
conftest.c:51: error: function declaration isn't a prototype
configure:7377: $? = 1

The reason limits.h is missing is because I failed to compile uClibc for
sparc64 using buildroot.

But even if I create an empty /opt/sparc/usr/include/limits.h, the test
fails:

configure:7314: checking for __bswapsi2
configure:7370: gcc -o conftest -Wall -W -Wshadow -Wpointer-arith
-Wmissing-prototypes                  -Wundef -Wstrict-prototypes -g -Os
-fno-dwarf2-cfi-asm -m64 -fno-stack-protector -mno-stack-arg-probe
-Werror -nostdlib -Wl,--defsym,___main=0x8100   -m64 conftest.c  >&5
cc1: warnings being treated as errors
conftest.c:51: error: function declaration isn't a prototype
configure:7377: $? = 1

I'm afraid it's a real bug that would affect native compilation.  We
should move adding -Werror to TARGET_CFLAGS after all checks.

Even after I do that, I still get:

configure:7305: checking for __bswapsi2
configure:7361: gcc -o conftest -Wall -W -Wshadow -Wpointer-arith
-Wmissing-prototypes                  -Wundef -Wstrict-prototypes -g -Os
-fno-dwarf2-cfi-asm -m64 -fno-stack-protector -mno-stack-arg-probe
-nostdlib -Wl,--defsym,___main=0x8100   -m64 conftest.c  >&5
conftest.c:51: warning: function declaration isn't a prototype
/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to
0000000000400144
/tmp/ccoCvQMe.o: In function `main':
/home/proski/src/grub2.git/build-ieee1275-sparc64-linux-uclibc/conftest.c:62: undefined reference to `__bswapsi2'
collect2: ld returned 1 exit status
configure:7368: $? = 1

That may or may not be due to the lack of the libc.  I tried checking
for __ashldi3, which is exported unconditionally on PowerPC, and the
check fails, even though I have libc for PowerPC.  That's also a
cross-compiler, but I can test it on a PowerMac if necessary.

This makes me think that checks for __bswapsi2 and  __bswapdi2 will fail
on Sparc64, even if those functions are present and even if
--disable-werror is used.

-- 
Regards,
Pavel Roskin

Re: powerpc/sparc problems

[David Miller]

From: Pavel Roskin <proski@gnu.org>
Date: Thu, 15 Oct 2009 18:41:41 -0400

> This makes me think that checks for __bswapsi2 and  __bswapdi2 will fail
> on Sparc64, even if those functions are present and even if
> --disable-werror is used.

They worked perfectly fine for me on a real system with
a real compiler and glibc.

If you're going to use cross compilation to test, use
a full cross toolset and glibc build not some hacked
up uclibc thing.

I also believe that even if it still fails for you,
native building is more important to work than cross
building situations.

Re: powerpc/sparc problems

[Pavel Roskin]

Quoting David Miller <davem@davemloft.net>:

> From: Pavel Roskin <proski@gnu.org>
> Date: Thu, 15 Oct 2009 18:41:41 -0400
>
>> This makes me think that checks for __bswapsi2 and  __bswapdi2 will fail
>> on Sparc64, even if those functions are present and even if
>> --disable-werror is used.
>
> They worked perfectly fine for me on a real system with
> a real compiler and glibc.

I don't think we can rely on testing done months ago.  Now that we use  
-Werror by default, the checks would fail even natively.  It they  
don't, I'd like to see the relevant excerpt from your config.log.

I'm going to test the native PowerPC build later today.

-- 
Regards,
Pavel Roskin

Re: powerpc/sparc problems

[Pavel Roskin]

On Fri, 2009-10-16 at 05:44 -0700, David Miller wrote:
> From: Pavel Roskin <proski@gnu.org>
> Date: Thu, 15 Oct 2009 18:41:41 -0400
> 
> > This makes me think that checks for __bswapsi2 and  __bswapdi2 will fail
> > on Sparc64, even if those functions are present and even if
> > --disable-werror is used.
> 
> They worked perfectly fine for me on a real system with
> a real compiler and glibc.
> 
> If you're going to use cross compilation to test, use
> a full cross toolset and glibc build not some hacked
> up uclibc thing.

I have tested the current GRUB on PowerPC.  It's Fedora 11 with a real
glibc.  I added __ashldi3 to the arguments of AC_CHECK_FUNCS.  The check
fails.  Yet __ashldi3 is present in libgcc and is exported
unconditionally.

The reason is that -nostdlib is added to CFLAGS immediately above 
AC_CHECK_FUNCS.  -nostdlib disables linking against libgcc.

I believe the checks for __bswapsi2 __bswapdi2 would fail on sparc64 for
the same reason.

Also, I believe the effect of -Werror on the test will be seen on
sparc64.  Adding -Werror should be after all tests and there should be a
big warning in configure.ac telling not to add tests after that point.

> I also believe that even if it still fails for you,
> native building is more important to work than cross
> building situations.

It is a native build and the current code.

The whole reason I removed the checks is because they stopped working
correctly when the target libc requirement was eliminated.  Restoring
the checks without removing -nostdlib not going to help.

I'm surprised that my code is being reverted immediately before the
release and the result is not tested.  It's one thing to revert the code
that has just been committed, and it's entirely different when the code
has been in the repository for months.

-- 
Regards,
Pavel Roskin

Re: powerpc/sparc problems

[Vladimir 'phcoder' Serbinenko]

Pavel Roskin wrote:
> On Fri, 2009-10-16 at 05:44 -0700, David Miller wrote:
>   
>> From: Pavel Roskin <proski@gnu.org>
>> Date: Thu, 15 Oct 2009 18:41:41 -0400
>>
>>     
>>> This makes me think that checks for __bswapsi2 and  __bswapdi2 will fail
>>> on Sparc64, even if those functions are present and even if
>>> --disable-werror is used.
>>>       
>> They worked perfectly fine for me on a real system with
>> a real compiler and glibc.
>>
>> If you're going to use cross compilation to test, use
>> a full cross toolset and glibc build not some hacked
>> up uclibc thing.
>>     
>
> I have tested the current GRUB on PowerPC.  It's Fedora 11 with a real
> glibc.  I added __ashldi3 to the arguments of AC_CHECK_FUNCS.  The check
> fails.  Yet __ashldi3 is present in libgcc and is exported
> unconditionally.
>
> The reason is that -nostdlib is added to CFLAGS immediately above 
> AC_CHECK_FUNCS.  -nostdlib disables linking against libgcc.
>
> I believe the checks for __bswapsi2 __bswapdi2 would fail on sparc64 for
> the same reason.
>
> Also, I believe the effect of -Werror on the test will be seen on
> sparc64.  Adding -Werror should be after all tests and there should be a
> big warning in configure.ac telling not to add tests after that point.
>
>   
>> I also believe that even if it still fails for you,
>> native building is more important to work than cross
>> building situations.
>>     
>
> It is a native build and the current code.
>
> The whole reason I removed the checks is because they stopped working
> correctly when the target libc requirement was eliminated.  Restoring
> the checks without removing -nostdlib not going to help.
>
> I'm surprised that my code is being reverted immediately before the
> release and the result is not tested.  It's one thing to revert the code
> that has just been committed, and it's entirely different when the code
> has been in the repository for months.
>
>   
I've tested only the code as it was for powerpc. I'm sorry that I
haven't checked sparc64 part but I haven't yet installed sparc64
cross-compile (it's unavailable from emdebian and compiling it oneself
is painful)


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: powerpc/sparc problems

[Robert Millan]

On Fri, Oct 16, 2009 at 09:21:36PM -0400, Pavel Roskin wrote:
> On Fri, 2009-10-16 at 05:44 -0700, David Miller wrote:
> > 
> > They worked perfectly fine for me on a real system with
> > a real compiler and glibc.
> > 
> > If you're going to use cross compilation to test, use
> > a full cross toolset and glibc build not some hacked
> > up uclibc thing.

But we're testing a feature of libgcc, not glibc.

> I have tested the current GRUB on PowerPC.  It's Fedora 11 with a real
> glibc.  I added __ashldi3 to the arguments of AC_CHECK_FUNCS.  The check
> fails.  Yet __ashldi3 is present in libgcc and is exported
> unconditionally.
> 
> The reason is that -nostdlib is added to CFLAGS immediately above 
> AC_CHECK_FUNCS.  -nostdlib disables linking against libgcc.
> 
> I believe the checks for __bswapsi2 __bswapdi2 would fail on sparc64 for
> the same reason.

Then why not just add -lgcc after -nostdlib?

> I'm surprised that my code is being reverted immediately before the
> release and the result is not tested.

I was under the impression that there was consensus that it should be
reverted.  Excuse me for not having tracked this more closely.

Looking at 2631:2632, it seems to me that:

  - Using configure checks is the right way, we just need to make them
    work (I think -lgcc should do it).

  - The ifdef wraps that have been added to sparc64/libgcc.h should also be
    in powerpc/libgcc.h.

>  It's one thing to revert the code
> that has just been committed, and it's entirely different when the code
> has been in the repository for months.

Yes.  There's been a long freeze period during which it'd have been more
appropiate to discuss this kind of things...

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

[PATCH] auto-generate libgcc.h

[Robert Millan]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]


This should be a much cleaner option than maintaining libgcc.h by hand.  Only
tested on sparc, but it should also cast out the build problems on powerpc.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

[-- Attachment #2: libgcc.diff --]
[-- Type: text/x-diff, Size: 8566 bytes --]

2009-10-20  Robert Millan  <rmh.grub@aybabtu.com>

	* genlibgcc_h.sh.in: New file.

	* conf/powerpc-ieee1275.rmk (MOSTLYCLEANFILES): Add `libgcc.h'.
	(libgcc.h): New rule.
	(kernel_syms.lst): Add `libgcc.h' to header list.
	* conf/sparc64-ieee1275.rmk: Likewise.

	* include/grub/sparc64/libgcc.h: Remove.  Update all users.
	* include/grub/powerpc/libgcc.h: Likewise.

	* configure.ac: Stop checking for libgcc symbols.
	* include/grub/misc.h [!GRUB_UTIL] (memset, memcmp): New prototypes
	(provided by libc.so or kernel.img, NOT libgcc).

Index: conf/powerpc-ieee1275.rmk
===================================================================
--- conf/powerpc-ieee1275.rmk	(revision 2641)
+++ conf/powerpc-ieee1275.rmk	(working copy)
@@ -10,19 +10,22 @@ script/sh/lexer.c_DEPENDENCIES = grub_script.tab.h
 
 # Images.
 
-MOSTLYCLEANFILES += symlist.c kernel_syms.lst
+MOSTLYCLEANFILES += symlist.c kernel_syms.lst libgcc.h
 DEFSYMFILES += kernel_syms.lst
 
 kernel_img_HEADERS = boot.h cache.h device.h disk.h dl.h elf.h elfload.h \
 	env.h err.h file.h fs.h kernel.h misc.h mm.h net.h parser.h reader.h \
-	symbol.h term.h time.h types.h powerpc/libgcc.h loader.h partition.h \
+	symbol.h term.h time.h types.h loader.h partition.h \
 	msdos_partition.h ieee1275/ieee1275.h machine/kernel.h handler.h list.h \
 	command.h
 
+libgcc.h: genlibgcc_h.sh
+	/bin/sh $< > $@ || (rm -f $@; exit 1)
+
 symlist.c: $(addprefix include/grub/,$(kernel_img_HEADERS)) config.h gensymlist.sh
 	/bin/sh gensymlist.sh $(filter %.h,$^) > $@ || (rm -f $@; exit 1)
 
-kernel_syms.lst: $(addprefix include/grub/,$(kernel_img_HEADERS)) config.h genkernsyms.sh
+kernel_syms.lst: $(addprefix include/grub/,$(kernel_img_HEADERS)) libgcc.h config.h genkernsyms.sh
 	/bin/sh genkernsyms.sh $(filter %.h,$^) > $@ || (rm -f $@; exit 1)
 
 # Programs
Index: conf/sparc64-ieee1275.rmk
===================================================================
--- conf/sparc64-ieee1275.rmk	(revision 2641)
+++ conf/sparc64-ieee1275.rmk	(working copy)
@@ -23,14 +23,14 @@ diskboot_img_ASFLAGS = $(COMMON_ASFLAGS)
 diskboot_img_LDFLAGS = $(COMMON_LDFLAGS) -Wl,-N,-Ttext,0x4200
 diskboot_img_FORMAT = binary
 
-MOSTLYCLEANFILES += symlist.c kernel_syms.lst
+MOSTLYCLEANFILES += symlist.c kernel_syms.lst libgcc.h
 DEFSYMFILES += kernel_syms.lst
 
 kernel_img_HEADERS = boot.h cache.h device.h disk.h dl.h elf.h elfload.h \
 	env.h err.h file.h fs.h kernel.h loader.h misc.h mm.h net.h parser.h \
 	partition.h msdos_partition.h reader.h symbol.h term.h time.h types.h \
 	list.h handler.h command.h \
-	sparc64/libgcc.h ieee1275/ieee1275.h machine/kernel.h \
+	ieee1275/ieee1275.h machine/kernel.h \
 	sparc64/ieee1275/ieee1275.h
 kernel_img_SOURCES = kern/sparc64/ieee1275/crt0.S kern/ieee1275/cmain.c	\
 	kern/ieee1275/ieee1275.c kern/main.c kern/device.c		\
@@ -54,7 +54,10 @@ kernel_img_FORMAT = binary
 symlist.c: $(addprefix include/grub/,$(kernel_img_HEADERS)) config.h gensymlist.sh
 	/bin/sh gensymlist.sh $(filter %.h,$^) > $@ || (rm -f $@; exit 1)
 
-kernel_syms.lst: $(addprefix include/grub/,$(kernel_img_HEADERS)) config.h genkernsyms.sh
+libgcc.h: genlibgcc_h.sh
+	/bin/sh $< > $@ || (rm -f $@; exit 1)
+
+kernel_syms.lst: $(addprefix include/grub/,$(kernel_img_HEADERS)) libgcc.h config.h genkernsyms.sh
 	/bin/sh genkernsyms.sh $(filter %.h,$^) > $@ || (rm -f $@; exit 1)
 
 # Utilities.
Index: configure.ac
===================================================================
--- configure.ac	(revision 2642)
+++ configure.ac	(working copy)
@@ -411,9 +411,6 @@ AC_SUBST(TARGET_ASFLAGS)
 AC_SUBST(TARGET_CPPFLAGS)
 AC_SUBST(TARGET_LDFLAGS)
 
-# Check for libgcc symbols (must be performed before we add -nostdlib to LDFLAGS)
-AC_CHECK_FUNCS(__bswapsi2 __bswapdi2)
-
 # Set them to their new values for the tests below.
 CC="$TARGET_CC"
 if test "x$TARGET_APPLE_CC" = x1 ; then
@@ -615,7 +612,7 @@ else
   rm -rf include/grub/machine
   cp -rp $srcdir/include/grub/$target_cpu/$platform include/grub/machine 2>/dev/null
 fi
-AC_CONFIG_FILES([Makefile gensymlist.sh genkernsyms.sh])
+AC_CONFIG_FILES([Makefile gensymlist.sh genkernsyms.sh genlibgcc_h.sh])
 AC_CONFIG_FILES([stamp-h], [echo timestamp > stamp-h])
 AC_OUTPUT
 [
Index: include/grub/misc.h
===================================================================
--- include/grub/misc.h	(revision 2641)
+++ include/grub/misc.h	(working copy)
@@ -78,6 +78,8 @@ grub_strncat (char *dest, const char *src, int c)
 #if !defined (GRUB_UTIL) || !defined (APPLE_CC)
 void *EXPORT_FUNC(memmove) (void *dest, const void *src, grub_size_t n);
 void *EXPORT_FUNC(memcpy) (void *dest, const void *src, grub_size_t n);
+void *EXPORT_FUNC(memset) (void *s, int c, grub_size_t n);
+int EXPORT_FUNC(memcmp) (const void *s1, const void *s2, grub_size_t n);
 #endif
 
 int EXPORT_FUNC(grub_memcmp) (const void *s1, const void *s2, grub_size_t n);
Index: include/grub/sparc64/libgcc.h
===================================================================
--- include/grub/sparc64/libgcc.h	(revision 2641)
+++ include/grub/sparc64/libgcc.h	(working copy)
@@ -1,31 +0,0 @@
-/*
- *  GRUB  --  GRand Unified Bootloader
- *  Copyright (C) 2004,2007  Free Software Foundation, Inc.
- *
- *  GRUB is free software: you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation, either version 3 of the License, or
- *  (at your option) any later version.
- *
- *  GRUB is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include <config.h>
-
-void EXPORT_FUNC (memset) (void);
-
-#ifdef HAVE___BSWAPSI2
-typedef int SItype __attribute__ ((mode (SI)));
-SItype EXPORT_FUNC (__bswapsi2) (SItype);
-#endif
-
-#ifdef HAVE___BSWAPDI2
-typedef int DItype __attribute__ ((mode (DI)));
-DItype EXPORT_FUNC (__bswapdi2) (DItype);
-#endif
Index: include/grub/powerpc/libgcc.h
===================================================================
--- include/grub/powerpc/libgcc.h	(revision 2641)
+++ include/grub/powerpc/libgcc.h	(working copy)
@@ -1,24 +0,0 @@
-/*
- *  GRUB  --  GRand Unified Bootloader
- *  Copyright (C) 2004,2007  Free Software Foundation, Inc.
- *
- *  GRUB is free software: you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation, either version 3 of the License, or
- *  (at your option) any later version.
- *
- *  GRUB is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
- */
-
-void EXPORT_FUNC (memset) (void);
-void EXPORT_FUNC (__ashldi3) (void);
-void EXPORT_FUNC (__ashrdi3) (void);
-void EXPORT_FUNC (__lshrdi3) (void);
-void EXPORT_FUNC (__trampoline_setup) (void);
-void EXPORT_FUNC (__ucmpdi2) (void);
Index: genlibgcc_h.sh.in
===================================================================
--- genlibgcc_h.sh.in	(revision 0)
+++ genlibgcc_h.sh.in	(revision 0)
@@ -0,0 +1,31 @@
+#! /bin/sh
+#
+# Copyright (C) 2006,2009  Free Software Foundation, Inc.
+#
+# GRUB is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# GRUB is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
+
+### The configure script will replace these variables.
+
+: ${srcdir=@srcdir@}
+: ${CC=@CC@}
+
+
+cat <<EOF
+/* This file is automatically generated by $0. DO NOT EDIT! */
+
+EOF
+
+nm --defined-only `$CC -print-libgcc-file-name` \
+  | sed -ne "s/^[0-9]* T //p" \
+  | sed -e "s/\(.*\)/void EXPORT_FUNC (\1) (void);/"

Re: [PATCH] auto-generate libgcc.h

[Vladimir 'phcoder' Serbinenko]

Robert Millan wrote:
> This should be a much cleaner option than maintaining libgcc.h by hand.  Only
> tested on sparc, but it should also cast out the build problems on powerpc.
>
>   
1) Doesn't work in cross-compiler environment. You confused CC and TARGET_CC
2) Symbols don't get included into symlist.c so it's unlikely to work.
I'll test on imac g3 today
3) Even if it works it would result in a largely bloated kernel.img due
to unused libgcc routines


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: [PATCH] auto-generate libgcc.h

[rubisher]

Vladimir 'phcoder' Serbinenko wrote:
> Robert Millan wrote:
>> This should be a much cleaner option than maintaining libgcc.h by hand.  Only
>> tested on sparc, but it should also cast out the build problems on powerpc.
>>
>>   
> 1) Doesn't work in cross-compiler environment. You confused CC and TARGET_CC

Tbh, when I look in the libgcc.h, excepted the header, it was empty. It seems that the forked sh doesn't known anything 
about CC, so I tried:
+	CC=$(TARGET_CC) /bin/sh $< > $@ || (rm -f $@; exit 1)

> 2) Symbols don't get included into symlist.c so it's unlikely to work.
Well, finaly it doesn't help a lot, the dpkg-build... still failed at the same place:

_restgpr_29_x in boot is not defined

Just note that it's not any more _restgpr_31_x(), I presume just because nm list it first?

> I'll test on imac g3 today
> 3) Even if it works it would result in a largely bloated kernel.img due
> to unused libgcc routines
> 
> 
Well, whatever src tree (svn 2641, 2642, dpkg 1.9-beta3, 1.9-beta4) which I reach to all build with gcc-4.3, it always 
failed to boot:

Welcome to GRUB!

the symbol `__lshrdi3' not found
Aborted. Press any key to exit.

As I am newbe to grub2 (and have few programming knowledge), can you advise me if it's a well known issue?

Thanks for all effort,
	J.

Re: [PATCH] auto-generate libgcc.h

[Vladimir 'phcoder' Serbinenko]

rubisher wrote:
> Vladimir 'phcoder' Serbinenko wrote:
>> Robert Millan wrote:
>>> This should be a much cleaner option than maintaining libgcc.h by
>>> hand.  Only
>>> tested on sparc, but it should also cast out the build problems on
>>> powerpc.
>>>
>>>   
>> 1) Doesn't work in cross-compiler environment. You confused CC and
>> TARGET_CC
>
> Tbh, when I look in the libgcc.h, excepted the header, it was empty.
> It seems that the forked sh doesn't known anything about CC, so I tried:
> +    CC=$(TARGET_CC) /bin/sh $< > $@ || (rm -f $@; exit 1)
>
>> 2) Symbols don't get included into symlist.c so it's unlikely to work.
> Well, finaly it doesn't help a lot, the dpkg-build... still failed at
> the same place:
>
> _restgpr_29_x in boot is not defined
>
> Just note that it's not any more _restgpr_31_x(), I presume just
> because nm list it first?
>
If _restgpr_31_x is really GOT table and building system pulls it from
some library it will create bugs (all kind of bugs you can imagine
caused by bad linking)
>> I'll test on imac g3 today
>> 3) Even if it works it would result in a largely bloated kernel.img due
>> to unused libgcc routines
>>
>>
> Well, whatever src tree (svn 2641, 2642, dpkg 1.9-beta3, 1.9-beta4)
> which I reach to all build with gcc-4.3, it always failed to boot:
>
> Welcome to GRUB!
>
> the symbol `__lshrdi3' not found
> Aborted. Press any key to exit.
>
> As I am newbe to grub2 (and have few programming knowledge), can you
> advise me if it's a well known issue?
>
> Thanks for all effort,
>     J.
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git 

Re: [PATCH] auto-generate libgcc.h

[rubisher]

Hello Vladimir,

Vladimir 'phcoder' Serbinenko wrote:
> rubisher wrote:
>> Vladimir 'phcoder' Serbinenko wrote:
>>> Robert Millan wrote:
>>>> This should be a much cleaner option than maintaining libgcc.h by
>>>> hand.  Only
>>>> tested on sparc, but it should also cast out the build problems on
>>>> powerpc.
>>>>
>>>>   
>>> 1) Doesn't work in cross-compiler environment. You confused CC and
>>> TARGET_CC
>> Tbh, when I look in the libgcc.h, excepted the header, it was empty.
>> It seems that the forked sh doesn't known anything about CC, so I tried:
>> +    CC=$(TARGET_CC) /bin/sh $< > $@ || (rm -f $@; exit 1)
>>
>>> 2) Symbols don't get included into symlist.c so it's unlikely to work.
>> Well, finaly it doesn't help a lot, the dpkg-build... still failed at
>> the same place:
>>
>> _restgpr_29_x in boot is not defined
>>
>> Just note that it's not any more _restgpr_31_x(), I presume just
>> because nm list it first?
>>
> If _restgpr_31_x is really GOT table and building system pulls it from
> some library it will create bugs (all kind of bugs you can imagine
> caused by bad linking)

Well I just figure out that all pb I met was due to the fact of -Os optimization.
I also discover that it's quiet easy thanks to 'TARGET_CFLAGS=-O0 CLFAGS=-O0 ../configure' to rebuild all the project with 
those other optimization and I was quiet happy to see the grub kernel image booting anyway.
Unfortunately the basic image dpkg build only contains fat & part_msdos,
(# /usr/bin/grub-mkelfimage --directory=/usr/lib/grub/powerpc-ieee1275 --output=/boot/grub/grub fat part_msdos); and so 
failed to boot my linux kernel (it first fall back in rescue mode and when I reach the grub prompt it didn't find any disk).

I also presume that's because it lacks of modules to find those scsi disk?
And I also read <http://grub.enbug.org/TestingOnPowerPC> and rebuild an grub image with all modules which make sadely panic 
the ofs:
/usr/bin/grub-mkelfimage -nv --directory=/usr/lib/grub/powerpc-ieee1275 -o /boot/grub/grubof.modules *.mod
(note the -n option also recommended for pseries)

DEFAULT CATCH!, exception-handler=fff00300
at   %SRR0: 0000000000c3c25c   %SRR1: 800000000000b002
Call History
------------
@  - c3c1f0
close-package  - c58060
(poplocals)  - c3a758
(init-program)  - c7e298
boot  - c7ec7c
evaluate  - c4a638
invalid pointer - d83655
invalid pointer - f
invalid pointer - f
catch  - c38fe8
bt-task-boot-on-this  - d140d8
(poplocals)  - c3a758
catch  - c38fe8
execute-device-method  - c58bcc
(poplocals)  - c3a758
(select-boot-seq)  - c59ba4

Client's Fix Pt Regs:
  00 00100000000001f4 ffffffffffffffff 00000000deadbeef fffffffffffffffc
  04 0000000000000000 0000000000000000 0000000000000000 0000000000000001
  08 0000000000001000 0000030002001000 0000000000000003 0000000000007000
  0c 0000000022800000 0000000000c17100 0000000000c18000 000000000009c4b0
  10 0000000000db8c20 0000000000db8939 0000000000c57d80 0000000000c58060
  14 0000000000000000 ffffffffffffffff 0000000000000000 0000000000000000
  18 0000000000c13000 0000000000c38000 0000000000c14d40 0000000000c16ec0
  1c 0000000000c20000 0000000000c3fdf0 0000000000c11ea0 0000000000c10fa8
Special Regs:
     %IV: 00000300     %CR: 84800000    %XER: 20000008  %DSISR: 08000000
   %SRR0: 0000000000c3c25c   %SRR1: 800000000000b002
     %LR: 0000000000c3c1f0    %CTR: 0000000000000000
    %DAR: ffffffffffffffff
Virtual PID = 0
  ofdbg

As I just started with grub2 2 weeks ago, I would still need your advise:
is this last problem came because modules should be compiled with -Os or much more because some module are not compatible 
with the ofs I have?

Thanks again for all,
     J.

>>> I'll test on imac g3 today
>>> 3) Even if it works it would result in a largely bloated kernel.img due
>>> to unused libgcc routines
>>>
>>>
>> Well, whatever src tree (svn 2641, 2642, dpkg 1.9-beta3, 1.9-beta4)
>> which I reach to all build with gcc-4.3, it always failed to boot:
>>
>> Welcome to GRUB!
>>
>> the symbol `__lshrdi3' not found
>> Aborted. Press any key to exit.
>>
>> As I am newbe to grub2 (and have few programming knowledge), can you
>> advise me if it's a well known issue?
>>
>> Thanks for all effort,
>>     J.
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
> 
> 

Re: powerpc/sparc problems

[Bean]

On Mon, Oct 12, 2009 at 6:14 PM, David Miller <davem@davemloft.net> wrote:
> From: Bean <bean123ch@gmail.com>
> Date: Mon, 12 Oct 2009 17:58:42 +0800
>
>> Try my branch, it includes the libgcc functions in grub instead of
>> rely on external library. It builds and run properly for
>> powerpc-ieee1275 last time I check.
>
> Good luck when the compiler changes the interface and/or semantics of
> these routines in a future version.  Will you enumerate your in-tree
> copies by gcc version with ifdefs or similar?
>
> That's why gcc and it's libgcc are distributed together, and gcc
> configures itself to link with a specific libgcc and only that libgcc.
>
> This whole things perfectly fine in GRUB when I implemented the
> necessary machinery to find if these routines exist in libgcc at
> configure time and to reference them properly in the build.
>
> They've merely been broken meanwhile and someone just needs to rectify
> that regression.
>

Hi,

To use the libgcc, we need to link the object file, this doesn't work
in system that use non ELF format like mach-o. And actually, the int
function rarely changed, and some project like openbios also include
the libgcc function directly.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: powerpc/sparc problems

[David Miller]

From: Bean <bean123ch@gmail.com>
Date: Mon, 12 Oct 2009 18:31:12 +0800

> To use the libgcc, we need to link the object file, this doesn't work
> in system that use non ELF format like mach-o.

How can one even build programs in the mach-o format if linking
object files is not allowed? :-)

If this is just for embedded cross compile situations, just forget it.

We just require that you have a fully functioning cross build
environment and that means you need to have a C library around.

Re: powerpc/sparc problems

[Bean]

On Mon, Oct 12, 2009 at 7:07 PM, David Miller <davem@davemloft.net> wrote:
> From: Bean <bean123ch@gmail.com>
> Date: Mon, 12 Oct 2009 18:31:12 +0800
>
>> To use the libgcc, we need to link the object file, this doesn't work
>> in system that use non ELF format like mach-o.
>
> How can one even build programs in the mach-o format if linking
> object files is not allowed? :-)
>
> If this is just for embedded cross compile situations, just forget it.
>
> We just require that you have a fully functioning cross build
> environment and that means you need to have a C library around.

Hi,

One of the main platform of powerpc-ieee1275 is apple's ppc machine,
which installs OSX by default. But OSX uses mach-o object and
executable file, not ELF. The mach-o image generated by gcc of OSX
isn't recognized by the ieee1275 firmware.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: powerpc/sparc problems

[Robert Millan]

On Mon, Oct 12, 2009 at 06:31:12PM +0800, Bean wrote:
> On Mon, Oct 12, 2009 at 6:14 PM, David Miller <davem@davemloft.net> wrote:
> >
> > Good luck when the compiler changes the interface and/or semantics of
> > these routines in a future version.  Will you enumerate your in-tree
> > copies by gcc version with ifdefs or similar?
> >
> > That's why gcc and it's libgcc are distributed together, and gcc
> > configures itself to link with a specific libgcc and only that libgcc.
> >
> > This whole things perfectly fine in GRUB when I implemented the
> > necessary machinery to find if these routines exist in libgcc at
> > configure time and to reference them properly in the build.
> >
> > They've merely been broken meanwhile and someone just needs to rectify
> > that regression.
> >
> 
> Hi,
> 
> To use the libgcc, we need to link the object file, this doesn't work
> in system that use non ELF format like mach-o. And actually, the int
> function rarely changed, and some project like openbios also include
> the libgcc function directly.

David is right.  We shouldn't embed a copy of libgcc code if we can avoid it.

If an OS uses mach-o, it just means when compiling native programs they need
to be in that format, but this is unrelated with the format used by GRUB.  GRUB
can be built on top of any OS, provided that its dependencies (including an
ELF-capable toolchain) were installed.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: powerpc/sparc problems

[rubisher]

Bean wrote:
> On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke <fzielcke@z-51.de> wrote:
>> David are you still there?
>> And also anyone who has access to a powerpc machine (and experience)?
>>
>> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
>> can't be found in the grub-ieee1275 build on powerpc and also sparc.
>>
>> Jordi already noticed this with the 1.96+20090721-4 IIRC and now other
>> people noticed this with 1.97~beta3
>> AFAICS there wasn't anything relevant changed on our side, so seems to
>> be a gcc issue.
>>
>> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and `__bswapsi2'
>> in the sparc64 header.
>> But something has now changed that this isn't enough anymore, at least
>> in Debian.
>>
>> We used gcc 4.3.3 at the time Jordi noticed this and now switched to
>> gcc-4.4.1.
>>
>> And David we still have this sparc bug open, which I forwared to
>> grub-devel:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
> 
> Hi,
> 
> Try my branch, it includes the libgcc functions in grub instead of
> rely on external library. It builds and run properly for
> powerpc-ieee1275 last time I check.
> 
Hello Mr bean ;<)

I reach to grab your git tree but even a fresh pull still failed to build from src as follow:
grub_emu-normal_main.o: In function `uitree_append':
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined reference to `grub_uitree_root'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined reference to `grub_uitree_root'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined reference to `grub_uitree_find'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:179: undefined reference to `grub_uitree_create_node'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:184: undefined reference to `grub_uitree_set_prop'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:185: undefined reference to `grub_uitree_set_prop'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:186: undefined reference to `grub_tree_add_child'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:172: undefined reference to `grub_uitree_create_node'
/Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:175: undefined reference to `grub_tree_add_child'
collect2: ld returned 1 exit status
make[1]: *** [grub-emu] Error 1
make[1]: Leaving directory `/Sources/jso/Grub2.deb/grub2-git091021/build/grub-common'
make: *** [build/grub-common] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Any idea/advise?

Tia,
	J.

Re: powerpc/sparc problems

[Bean]

On Thu, Oct 22, 2009 at 12:03 AM, rubisher <rubisher@scarlet.be> wrote:
> Bean wrote:
>>
>> On Mon, Oct 12, 2009 at 4:55 PM, Felix Zielcke <fzielcke@z-51.de> wrote:
>>>
>>> David are you still there?
>>> And also anyone who has access to a powerpc machine (and experience)?
>>>
>>> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
>>> can't be found in the grub-ieee1275 build on powerpc and also sparc.
>>>
>>> Jordi already noticed this with the 1.96+20090721-4 IIRC and now other
>>> people noticed this with 1.97~beta3
>>> AFAICS there wasn't anything relevant changed on our side, so seems to
>>> be a gcc issue.
>>>
>>> `__ashldi3' is listed in include/grub/powerpc/libgcc.h and `__bswapsi2'
>>> in the sparc64 header.
>>> But something has now changed that this isn't enough anymore, at least
>>> in Debian.
>>>
>>> We used gcc 4.3.3 at the time Jordi noticed this and now switched to
>>> gcc-4.4.1.
>>>
>>> And David we still have this sparc bug open, which I forwared to
>>> grub-devel:
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538030
>>
>> Hi,
>>
>> Try my branch, it includes the libgcc functions in grub instead of
>> rely on external library. It builds and run properly for
>> powerpc-ieee1275 last time I check.
>>
> Hello Mr bean ;<)
>
> I reach to grab your git tree but even a fresh pull still failed to build
> from src as follow:
> grub_emu-normal_main.o: In function `uitree_append':
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
> reference to `grub_uitree_root'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
> reference to `grub_uitree_root'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:169: undefined
> reference to `grub_uitree_find'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:179: undefined
> reference to `grub_uitree_create_node'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:184: undefined
> reference to `grub_uitree_set_prop'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:185: undefined
> reference to `grub_uitree_set_prop'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:186: undefined
> reference to `grub_tree_add_child'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:172: undefined
> reference to `grub_uitree_create_node'
> /Sources/jso/Grub2.deb/grub2-git091021/normal/main.c:175: undefined
> reference to `grub_tree_add_child'
> collect2: ld returned 1 exit status
> make[1]: *** [grub-emu] Error 1
> make[1]: Leaving directory
> `/Sources/jso/Grub2.deb/grub2-git091021/build/grub-common'
> make: *** [build/grub-common] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
> Any idea/advise?

Hi,

I forget to add some file for grub-emu previously, but it's fixed
already, pull the latest code.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: powerpc/sparc problems

[Felix Zielcke]

Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke:
> David are you still there?
> And also anyone who has access to a powerpc machine (and experience)?
> 
> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
> can't be found in the grub-ieee1275 build on powerpc and also sparc.

Ok the internal gcc symbols for sparc have been fixed now.
But now there's another problem on sparc:

  ok boot
  Boot device: disk  File and args:                                     
  GRUB Illegal Instruction
  ok 

-- 
Felix Zielcke
Proud Debian Maintainer and GNU GRUB developer

Re: powerpc/sparc problems

[David Miller]

From: Felix Zielcke <fzielcke@z-51.de>
Date: Wed, 28 Oct 2009 11:24:58 +0100

> Am Montag, den 12.10.2009, 10:55 +0200 schrieb Felix Zielcke:
>> David are you still there?
>> And also anyone who has access to a powerpc machine (and experience)?
>> 
>> In Debian we the problem that the `__ashldi3' and `__bswapsi2' symbols
>> can't be found in the grub-ieee1275 build on powerpc and also sparc.
> 
> Ok the internal gcc symbols for sparc have been fixed now.
> But now there's another problem on sparc:
> 
>   ok boot
>   Boot device: disk  File and args:                                     
>   GRUB Illegal Instruction
>   ok 

Like I said, I won't be able to look into these kinds of things
for at least a month or so and I doubt anyone else here has the
sparc knowledge necessary to help you diagnose this.

Sorry.