[RFC]possible improvements to --with-sysroot
The following suggestion is based on my understanding of --with-sysroot, if there were any error, please correct me. To my understanding, currently if cross-compile tool chain (including gcc) is configured with --with-sysroot when installing them, then when cross compiling, ld will look for libraries in $SYSROOT/usr/lib and $SYSROOT/usr/local/lib. Wouldn't it be great that we go one step further that we let ld look for libraries in the dir listed in $SYSROOT/etc/ld.so.conf, if this file ever exits? Of course for each entry in $SYSROOT/etc/ld.so.conf, we prefix $SYSROOT to it. Comments are welcomed. Thanks! -- Zhang Le, Robert http://zhllg.blogspot.com http://zh.gentoo-wiki.com http://savannah.nongnu.org/projects/pgubook http://groups.google.com/group/gentoo-china http://groups.google.com/group/szlug
Re: [RFC]possible improvements to --with-sysroot
First of all, my apology. It seems that I should have posted this
email to binutils's ML.
On 3/5/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Sat, Mar 03, 2007 at 09:47:41PM +0800, Zhang Le wrote:
> Wouldn't it be great that we go one step further that we let ld look
> for libraries in the dir listed in $SYSROOT/etc/ld.so.conf, if this
> file ever exits? Of course for each entry in $SYSROOT/etc/ld.so.conf,
> we prefix $SYSROOT to it.
Did you try it? This should already happen if you configured binutils
with a sysroot.
Yes, I have tried.
My distribution is Gentoo, I used the crossdev utility to build the
cross toolchain.
The related code is:
is_cross && myconf="${myconf} --with-sysroot=/usr/${CTARGET}"
I was cross compiling KDE. However, it's failed because linker can't
find -lqt-mt.
I have used "strace -f" to check where linker looked for -lqt-mt. From
what I have observed, it seems that ld didn't use
$SYSROOT/etc/ld.so.conf.
--
Zhang Le, Robert
Linux Engineer/Trainer
http://zhllg.blogspot.com
http://zh.gentoo-wiki.com
http://savannah.nongnu.org/projects/pgubook
http://groups.google.com/group/gentoo-china
http://groups.google.com/group/szlug
Re: [RFC]possible improvements to --with-sysroot
On 3/6/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: On Tue, Mar 06, 2007 at 02:05:06AM +0800, Zhang Le wrote: > I have used "strace -f" to check where linker looked for -lqt-mt. From > what I have observed, it seems that ld didn't use > $SYSROOT/etc/ld.so.conf. Well, it's supposed to, so I suggest you check what's happened in ld. Thanks, will do -- Zhang Le, Robert Linux Engineer/Trainer http://zhllg.blogspot.com http://zh.gentoo-wiki.com http://savannah.nongnu.org/projects/pgubook http://groups.google.com/group/gentoo-china http://groups.google.com/group/szlug
Re: [RFC]possible improvements to --with-sysroot
On 3/6/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: On Tue, Mar 06, 2007 at 02:05:06AM +0800, Zhang Le wrote: > I have used "strace -f" to check where linker looked for -lqt-mt. From > what I have observed, it seems that ld didn't use > $SYSROOT/etc/ld.so.conf. Well, it's supposed to, so I suggest you check what's happened in ld. I found a clue which may lead to a neat solution to this problem. And this has something to do with gcc, so I still posted it here. First of all, $SYSROOT/etc/ld.so.conf solution maybe an overkill, so I think we can ignore it for now. The finding is if ld is invoked with --sysroot option and if the dir specified by -L has a leading "=", for example: --sysroot=/usr/mipsel-unknown-linux-gnu -L=/usr/qt/3/lib -L/usr/lib -lqt-mt Then when ld will looking for libqt-mt.so in /usr/mipsel-unknown-linux-gnu/usr/qt/3/lib, instead of /usr/qt/3/lib. Thus problem solved. So I think if there is a way to detect whether gcc is doing cross compile. If so, when cross compiling is detected, collect2 search for -L option in COLLECT_GCC_OPTIONS, and insert a "=" between -L and the actual path. I think this way is better than the $SYSROOT/etc/ld.so.conf way. -- Zhang Le, Robert Linux Engineer/Trainer http://zhllg.blogspot.com http://zh.gentoo-wiki.com http://savannah.nongnu.org/projects/pgubook http://groups.google.com/group/gentoo-china http://groups.google.com/group/szlug
Re: cpp found limits.h in FIXED_INCLUDE_DIR, but not in STANDARD_INCLUDE_DIR
Hi, all, I think I've found the reason. It all comes from this gentoo patch: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-devel/gcc/files/4.1.0/gcc-4.1.0-cross-compile.patch?rev=1.1&view=markup Specifically: -elif test "x$TARGET_SYSTEM_ROOT" != x; then +elif test "x$TARGET_SYSTEM_ROOT" != x -o $build != $host; then SYSTEM_HEADER_DIR=$build_system_header_dir fi BTW, I haven't got time to learn more about that debate, but I will do it. Since my build != host, so SYSTEM_HEADER_DIR=$build_system_header_dir, which is in turn CROSS_SYSTEM_HEADER_DIR. So this test will fail LIMITS_H_TEST = [ -f $(SYSTEM_HEADER_DIR)/limits.h ] And then: if $(LIMITS_H_TEST) ; then \ cat $(srcdir)/limitx.h $(srcdir)/glimits.h $(srcdir)/limity.h > tmp-xlimits.h; \ else \ cat $(srcdir)/glimits.h > tmp-xlimits.h; \ fi; \ And the solution is easy, just turn on 'vanilla' USE flag in Gentoo. Sorry for the noise. Zhang Le
install path in libgcc Makefile.in
Hi, Another problem when cross building the native mips compiler. I.e. build=x86, host=target=mipsel I have done some search, but haven't found any related discussion. The install path of libgcc contains gcc version. Currently in libgcc/Makefile.in, gcc version is get like this: version := $(shell $(CC) -dumpversion) This will lead to a problem that I have only experienced when cross building the native compiler. The problem is that crtbegin.o/crtend.o/etc. will be installed into old gcc's path, overwrite existing ones. New gcc will have no crtbegin.o... There is no problem when natively building native compiler. I don't understand why the problem only happens when cross building native compiler. I know I need to study how gcc is built. Just want make you aware of this problem. And I have a suggestion to this problem. I have observed that in other components, the version is get like this: version := $(shell cat $(srcdir)/../gcc/BASE-VER) So what about we do the same in libgcc/Makefile.in? Because this can ensure that the install dir will be new gcc's path. If this is ok, I will post a little patch. Zhang Le
Re: install path in libgcc Makefile.in
On 00:06 Sat 11 Oct , Daniel Jacobowitz wrote: > > If this is ok, I will post a little patch. > > That sounds fine, but the whole process is trouble. Would you explain why it is trouble? Thanks! The patch is included. Zhang Le diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog index 5fc628b..a9ff11f 100644 --- a/libgcc/ChangeLog +++ b/libgcc/ChangeLog @@ -1,3 +1,7 @@ +2008-10-12 Zhang Le <[EMAIL PROTECTED]> + + * Makefile.in: get version from gcc/BASE-VER + 2008-09-03 Hari Sandanagobalane <[EMAIL PROTECTED]> Add picoChip port. diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in index 5718a50..eec5496 100644 --- a/libgcc/Makefile.in +++ b/libgcc/Makefile.in @@ -184,7 +184,7 @@ export RANLIB_FOR_TARGET export libsubdir export slibdir -version := $(shell $(CC) -dumpversion) +version := $(shell cat $(srcdir)/../gcc/BASE-VER) ifeq ($(decimal_float),yes) ifeq ($(enable_decimal_float),bid)
Re: install path in libgcc Makefile.in
On 17:36 Sat 11 Oct , Daniel Jacobowitz wrote: > > The patch is included. > > If you've tested it, send it to gcc-patches. I will test in 3 cases: build = host = target build = host != target build != host = target Now the first two are finished. I am using the compiler get in step to run case 3. I will send the patch to gcc-patches after testing. Zhang Le
Re: install path in libgcc Makefile.in
On 04:19 Mon 13 Oct , Eus wrote: > Hi Ho! > > On Saturday, October 11, 2008, "Zhang Le" <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > Another problem when cross building the native mips compiler. > > I.e. build=x86, host=target=mipsel > > I have done some search, but haven't found any related discussion. > > Please have a look at: > http://gcc.gnu.org/ml/gcc/2008-09/msg00376.html > > Also, I think Jay has done a research to solve that particular problem: > http://gcc.gnu.org/ml/gcc-help/2008-08/msg00315.html > http://gcc.gnu.org/ml/gcc/2008-09/msg9.html Thanks! But I don't think that problem is exactly the same as mine. Plus my patch already solved my problem. ;) My patch seems to work well, I will post to gcc-patch soon. BTW, fontconfig 2.6.0 failed to build using 20081010 snapshot native compiler on Loongson 2F box. But I believe this is irrelevant to my patch. Because I found the .s files generate by 4.3 and 4.4 are different. Using .o file produced by gcc 4.3, both gcc 4.3 and 4.4 could produce a working executable. Using .o file produced by gcc 4.4, none of them could produce a working executable. I will try to find the reason. Regards, Zhang, Le
A happy problem caused by loongson2f's div.g instruction
Hi, all,
First of all, a little background on loongson2e/2f integer insn.
This new set of insns has 3 operands. Like:
div.g d,s,t
This is a real machine insn, not a macro.
And it delivers the result very fast.
This is the user guide if you are interested in more details:
http://www.gentoo-cn.org/~zhangle/Loongson2FUserGuide.pdf
I have recently tested this patch which added support for these insns:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00273.html
For your convenience, you can get it here directly:
http://www.gentoo-cn.org/~zhangle/gcc-4.4.0-loongson-new_i_insn_and_prefetch.patch
And I found a problem. Take a look at the following c code:
int main() {
int a = 0;
int b = 8;
return a/b;
}
save it as div.c, compile it with:
gcc -march=loongson2f div.c -S
and the asm code produced is:
sw $0,12($fp)
li $2,8# 0x8
sw $2,8($fp)
lw $3,12($fp)
lw $2,8($fp)
div.g $2,$3,$2
teq $2,$0,7
and the code will cause FPE. That means immediate after div.g, $2's value
becomes 0.
I really can't find a second reasonably explanation.
So I think one of the possible solution would be to reverse the div.g and teq
insn.
And I think this is not hard to do, just modify mips_output_division() function.
Also I think this is a better solution, since we can save a register.
The other would be make sure the destination register is different from source
registers.
I have read some docs, but still not sure how to do it.
http://gcc.gnu.org/onlinedocs/gccint/Modifiers.html#Modifiers
If there is anything wrong, do tell me.
Also if you have any suggestions, I am all ears.
Thanks in advance!
Zhang, Le
Re: A happy problem caused by loongson2f's div.g instruction
On 18:31 Sun 09 Nov , Andrew Haley wrote: > Zhang Le wrote: > > > > > The other would be make sure the destination register is different from > > source registers. > > I have read some docs, but still not sure how to do it. > > That's just an earlyclobber. Search for that. Thank you, Andrew! I have read about it, but maybe not fully understand it. I will read again. Zhang, Le
Re: A happy problem caused by loongson2f's div.g instruction
On 19:18 Mon 10 Nov , Zhang Le wrote: > However, now I think adding a earlyclobber constraint may be the way to go. > Since it is a less intrusive and more elegant (comparing with my patch above) > change. This solution is as easy as adding two bytes (two &s's) to the original patch: @@ -11,7 +11,7 @@ Index: trunk/gcc/config/mips/loongson.md +;;new integer instructions + +(define_insn "div3" -+ [(set (match_operand:GPR 0 "register_operand" "=d") ++ [(set (match_operand:GPR 0 "register_operand" "=&d") + (any_div:GPR + (match_operand:GPR 1 "register_operand" "d") + (match_operand:GPR 2 "register_operand" "d")))] @@ -22,7 +22,7 @@ Index: trunk/gcc/config/mips/loongson.md +) + +(define_insn "mod3" -+ [(set (match_operand:GPR 0 "register_operand" "=d") ++ [(set (match_operand:GPR 0 "register_operand" "=&d") + (any_mod:GPR + (match_operand:GPR 1 "register_operand" "d") + (match_operand:GPR 2 "register_operand" "d")))] Zhang, Le
Re: A happy problem caused by loongson2f's div.g instruction
On 09:18 Mon 10 Nov , Eric Fisher wrote:
> > So I think one of the possible solution would be to reverse the div.g and
> > teq insn.
> > And I think this is not hard to do, just modify mips_output_division()
> > function.
> > Also I think this is a better solution, since we can save a register.
>
> Do you mean the modification like this?
>
> +
> +
> +/* Used to output (d)div(u).g or (d)mod(u).g instruction of loongson,
> + + which takes three operands, and put the result in the rd register.
> + + Hence emit the divide-by-zeor check before the DIVISION, in case
> + + that the rd and rt are the same one. */
> +const char *
> +mips_output_division_g (const char *division, rtx *operands)
> +{
> + if (TARGET_CHECK_ZERO_DIV)
> +{
> + output_asm_insn ("bne\t%2,%.,1f%#\n\tbreak\t7\n1:", operands);
> +}
> + return division;
> +}
> +
>
> +;; For loongson
> +
> +(define_insn "divsi3"
> + [(set (match_operand:SI 0 "register_operand" "=d")
> + (div:SI (match_operand:SI 1 "register_operand" "d")
> + (match_operand:SI 2 "register_operand" "d")))]
> + "TARGET_LOONGSON2E || TARGET_LOONGSON2F"
> + { return mips_output_division_g ("div.g\t%0,%1,%2", operands); }
> + [(set_attr "type""divg")
> + (set_attr "mode""SI")
> + (set (attr "length")
> +(if_then_else (ne (symbol_ref "TARGET_CHECK_ZERO_DIV") (const_int 0))
> + (const_int 16)
> + (const_int 4)))])
> +
> +(define_insn "udivsi3"
> + [(set (match_operand:SI 0 "register_operand" "=d")
> + (udiv:SI (match_operand:SI 1 "register_operand" "d")
> + (match_operand:SI 2 "register_operand" "d")))]
> + "TARGET_LOONGSON2E || TARGET_LOONGSON2F"
> + { return mips_output_division_g ("divu.g\t%0,%1,%2", operands); }
> + [(set_attr "type""divg")
> + (set_attr "mode""SI")
> + (set (attr "length")
> +(if_then_else (ne (symbol_ref "TARGET_CHECK_ZERO_DIV") (const_int 0))
> + (const_int 16)
> + (const_int 4)))])
Hi, Eric. This is my version:
--- trunk/gcc/config/mips/mips.c.orig 2008-11-10 02:23:33.0 +0800
+++ trunk/gcc/config/mips/mips.c2008-11-10 02:24:56.0 +0800
@@ -10359,8 +10359,15 @@
}
else if (GENERATE_DIVIDE_TRAPS)
{
- output_asm_insn (s, operands);
- s = "teq\t%2,%.,7";
+ if (TARGET_LOONGSON_2EF)
+ {
+ output_asm_insn ("teq\t%2,%.,7", operands);
+ }
+ else
+ {
+ output_asm_insn (s, operands);
+ s = "teq\t%2,%.,7";
+ }
}
else
{
I have tried it. It seems to be working.
However, now I think adding a earlyclobber constraint may be the way to go.
Since it is a less intrusive and more elegant (comparing with my patch above)
change.
Zhang, Le
MIPS -mplt option in N32 abi system
Hi there,
I have just tried gcc 4.4 svn trunk on a MIPS N32 system.
But I found -mplt is practically not usable, because -mno-shared is not used
when generating non-PIC code.
I dug into the code and found the cause is in gcc/config/mips/linux64.h.
Unlike linux.h under the same directory, DRIVER_SELF_SPECS in linux64.h has no
LINUX_DRIVER_SELF_SPECS.
Is it left out intentionally?
However it seems to me that -mplt works on N32 system.
So what about the patch attached? ok to apply?
Zhang, Le
--- gcc/config/mips/linux64.h.orig 2008-12-01 13:55:43.0 +
+++ gcc/config/mips/linux64.h 2008-12-01 13:54:48.0 +
@@ -23,6 +23,7 @@
#undef DRIVER_SELF_SPECS
#define DRIVER_SELF_SPECS \
BASE_DRIVER_SELF_SPECS \
+LINUX_DRIVER_SELF_SPECS \
" %{!EB:%{!EL:%(endian_spec)}}" \
" %{!mabi=*: -mabi=n32}"
Re: MIPS -mplt option in N32 abi system
On 10:33 Mon 01 Dec , David Daney wrote:
> Zhang Le wrote:
>> BASE_DRIVER_SELF_SPECS \
>> +LINUX_DRIVER_SELF_SPECS \
>> " %{!EB:%{!EL:%(endian_spec)}}" \
>> " %{!mabi=*: -mabi=n32}"
>
> You are missing a comma there between BASE_DRIVER_SELF_SPECS and
> LINUX_DRIVER_SELF_SPECS. Without the comma, I am told that
> gcc.target/mips/pr35802.c FAILs. Other than that (and some formatting)
> this patch is equivalent to:
>
> http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00033.html
Thanks!
I will pay much closer attention to gcc-patches list in the future.
Zhang, Le
Re: MIPS -mplt option in N32 abi system
On 11:02 Mon 01 Dec , David Daney wrote:
> Zhang Le wrote:
>> On 10:33 Mon 01 Dec , David Daney wrote:
>>> Zhang Le wrote:
>>>> BASE_DRIVER_SELF_SPECS \
>>>> +LINUX_DRIVER_SELF_SPECS \
>>>> " %{!EB:%{!EL:%(endian_spec)}}" \
>>>> " %{!mabi=*: -mabi=n32}"
>>> You are missing a comma there between BASE_DRIVER_SELF_SPECS and
>>> LINUX_DRIVER_SELF_SPECS. Without the comma, I am told that
>>> gcc.target/mips/pr35802.c FAILs. Other than that (and some formatting)
>>> this patch is equivalent to:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00033.html
>> Thanks!
>> I will pay much closer attention to gcc-patches list in the future.
>
> In this case, it may not have helped much. I only beat you be about an
> hour.
Yes, but at least this can save you an email to remind me that a similar patch
is already sent, ;)
Actually, I made this patch at least 4 hours ago.
When I sent this, I was just about to go to bed and figured that I'd better
send it before I went to bed.
OK, really need to go to bed now, already 3 a.m. Good night.
Zhang, Le
