headers
Paul Mundt | 1 Jun 2008 07:30
Gravatar

Re: sh64 build error - sh, kbuild or binutils problem?

On Sat, May 31, 2008 at 11:22:39PM +0300, Adrian Bunk wrote:
> Minimal example demonstrating the problem:
> 
> $ sh64-linux-ar rcs tmp.o
> $ sh64-linux-ld -EL -r -o tmp2.o tmp.o
> $ sh64-linux-ld -EL -r -o out.o tmp2.o 
> sh64-linux-ld: sh3 architecture of input file `tmp2.o' is incompatible with sh5 output
> $ 
> 
Yes, it's a binutils bug. I've hit this on SH-2A zImage builds too, and
hacked together a patch for it. I'll see about fixing it up fo sh64 too
and then posting it to the list.
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Adrian Bunk | 1 Jun 2008 21:53

Re: sh64 build error - sh, kbuild or binutils problem?

On Sun, Jun 01, 2008 at 02:30:47PM +0900, Paul Mundt wrote:
> On Sat, May 31, 2008 at 11:22:39PM +0300, Adrian Bunk wrote:
> > Minimal example demonstrating the problem:
> > 
> > $ sh64-linux-ar rcs tmp.o
> > $ sh64-linux-ld -EL -r -o tmp2.o tmp.o
> > $ sh64-linux-ld -EL -r -o out.o tmp2.o 
> > sh64-linux-ld: sh3 architecture of input file `tmp2.o' is incompatible with sh5 output
> > $ 
> > 
> Yes, it's a binutils bug. I've hit this on SH-2A zImage builds too, and
> hacked together a patch for it. I'll see about fixing it up fo sh64 too
> and then posting it to the list.

Thanks  :-)
Adrian

--

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Ravnborg | 3 Jun 2008 23:07
Gravatar

[RFC PATCH] drop support for KALLSYMS_EXTRA_PASS

We have not seen any reports on inconsistent kallsysms data recently
as in the last one or two years. At least I do not recall these
and google had no hits in my searching.

So I suggest removing this as to simplify the final linking.
When doing "make allyesconfig" build this extra linking
takes considerably time (and I usually forgoet to turn it off).

In addition this patch removes the debug target: debug_kallsyms

	Sam

Suggested patch:

diff --git a/Makefile b/Makefile
index 8db70fe..911cb90 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -702,7 +702,6  <at>  <at>  define rule_vmlinux__
 		rm -f $ <at> ;                                                    \
 		/bin/false;                                                  \
 	fi;
-	$(verify_kallsyms)
 endef

 
 <at>  <at>  -719,28 +718,8  <at>  <at>  ifdef CONFIG_KALLSYMS
 # o The correct .tmp_kallsyms2.o is linked into the final vmlinux.
 # o Verify that the System.map from vmlinux matches the map from
 #   .tmp_vmlinux2, just in case we did not generate kallsyms correctly.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Paulo Marques | 4 Jun 2008 16:01

Re: [RFC PATCH] drop support for KALLSYMS_EXTRA_PASS

Sam Ravnborg wrote:
> We have not seen any reports on inconsistent kallsysms data recently
> as in the last one or two years. At least I do not recall these
> and google had no hits in my searching.
> 
> So I suggest removing this as to simplify the final linking.
> When doing "make allyesconfig" build this extra linking
> takes considerably time (and I usually forgoet to turn it off).

I don't remember any recent (read: in the last few years) problems 
either, so I guess this is ok.

> In addition this patch removes the debug target: debug_kallsyms

This might be useful if changes in some binutils version creates new 
problems for kallsyms, but it doesn't seem like a lot of work to just 
send a reporter a patch to add this back if needed. Since there haven't 
been any reports in a few years, I have no problems with this.

Acked-by: Paulo Marques <pmarques <at> grupopie.com>

--

-- 
Paulo Marques - www.grupopie.com

"'thinking outside the box' works better if I know what's inside the box."
Permalink | Reply | 0 comments |
headers
Sam Ravnborg | 4 Jun 2008 23:45
Gravatar

Simplify vmlinux link

Following two patches simplifies the foo used to link
vmlinux to a level where it is maintainable again.

The patches remove the KALLSYMS_EXTRA_PASS stuff and
move the vmlinux link stuff to a small shell script.

This need some testing as I have not even been able
to boot test this as my dev box is down.
So help and feedback is really appreciated.

Full patch below - I will post sepearate patches as follow-up.

Patches will be pushed out to kbuild-next only when I get
some positive reponse that it boots.

	Sam

 Makefile                |  200 +++-------------------------------------------
 init/Kconfig            |   12 ---
 scripts/link-vmlinux.sh |  144 ++++++++++++++++++++++++++++++++++
 scripts/mksysmap        |   45 -----------
 5 files changed, 160 insertions(+), 258 deletions(-)

diff --git a/Makefile b/Makefile
index 8db70fe..a958d34 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -626,206 +626,32  <at>  <at>  libs-y1		:= $(patsubst %/, %/lib.a, $(libs-y))
 libs-y2		:= $(patsubst %/, %/built-in.o, $(libs-y))
 libs-y		:= $(libs-y1) $(libs-y2)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Sam Ravnborg | 4 Jun 2008 23:46
Gravatar

[PATCH 1/2] kbuild: drop support for KALLSYMS_EXTRA_PASS

From 636b71590757772f8a0af2155ae1e6fa0c1f0856 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <sam <at> ravnborg.org>
Date: Wed, 4 Jun 2008 22:16:47 +0200
Subject: [PATCH] kbuild: drop support for KALLSYMS_EXTRA_PASS

We have not seen any reports on inconsistent kallsysms data recently
as in the last one or two years. At least I do not recall these
and google had no hits in my searching.

Removing this to simplify the final linking.
When doing "make allyesconfig" build this extra linking
takes considerably time (and I usually forget to turn it off).

In addition this patch removes the debug target: debug_kallsyms

Signed-off-by: Sam Ravnborg <sam <at> ravnborg.org>
Acked-by: Paulo Marques <pmarques <at> grupopie.com>
Cc: Keith Owens <kaos <at> ocs.com.au>
---
 Makefile     |   38 ++------------------------------------
 init/Kconfig |   12 ------------
 2 files changed, 2 insertions(+), 48 deletions(-)

diff --git a/Makefile b/Makefile
index 8db70fe..911cb90 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -702,7 +702,6  <at>  <at>  define rule_vmlinux__
 		rm -f $ <at> ;                                                    \
 		/bin/false;                                                  \
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Ravnborg | 4 Jun 2008 23:47
Gravatar

[PATCH 2/2] kbuild: simplify vmlinux link stage

From 68e9b79c8dad5245f28ab4f3527481b730dbdb61 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <sam <at> ravnborg.org>
Date: Wed, 4 Jun 2008 23:38:15 +0200
Subject: [PATCH] kbuild: simplify vmlinux link stage

Move link of vmlinux from Makefile to a script
This makes the link process much more readable/maintainable.

The process was entirely serialized before so there is not
drawback doing so.

With this move take advantage of the prelinked vmlinux.o
file so we do not link all .o files more than once.

Signed-off-by: Sam Ravnborg <sam <at> ravnborg.org>
---
 Makefile                |  168 ++++-------------------------------------------
 arch/um/Makefile        |   17 +----
 scripts/link-vmlinux.sh |  144 ++++++++++++++++++++++++++++++++++++++++
 scripts/mksysmap        |   45 -------------
 4 files changed, 161 insertions(+), 213 deletions(-)
 create mode 100644 scripts/link-vmlinux.sh
 delete mode 100644 scripts/mksysmap

diff --git a/Makefile b/Makefile
index 911cb90..a958d34 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -626,172 +626,32  <at>  <at>  libs-y1		:= $(patsubst %/, %/lib.a, $(libs-y))
 libs-y2		:= $(patsubst %/, %/built-in.o, $(libs-y))
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Ravnborg | 4 Jun 2008 23:50
Gravatar

Re: Simplify vmlinux link

On Wed, Jun 04, 2008 at 11:45:14PM +0200, Sam Ravnborg wrote:
> Following two patches simplifies the foo used to link
> vmlinux to a level where it is maintainable again.
> 
> The patches remove the KALLSYMS_EXTRA_PASS stuff and
> move the vmlinux link stuff to a small shell script.
> 
> This need some testing as I have not even been able
> to boot test this as my dev box is down.
> So help and feedback is really appreciated.
> 
> Full patch below - I will post sepearate patches as follow-up.
> 
> Patches will be pushed out to kbuild-next only when I get
> some positive reponse that it boots.

This breaks um build btw.
The 2/2 patch contains an attempt to fix it but I could not
manage to tech ld how to find -lunit - despite that it worked with gcc.

	Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Keith Owens | 5 Jun 2008 11:19
Picon

Re: [RFC PATCH] drop support for KALLSYMS_EXTRA_PASS

Sam Ravnborg (on Tue, 3 Jun 2008 23:07:32 +0200) wrote:
>We have not seen any reports on inconsistent kallsysms data recently
>as in the last one or two years. At least I do not recall these
>and google had no hits in my searching.
>
>So I suggest removing this as to simplify the final linking.
>When doing "make allyesconfig" build this extra linking
>takes considerably time (and I usually forgoet to turn it off).
>
>In addition this patch removes the debug target: debug_kallsyms
>
>diff --git a/Makefile b/Makefile
>-define verify_kallsyms
>-	$(Q)$(if $($(quiet)cmd_sysmap),                                      \
>-	  echo '  $($(quiet)cmd_sysmap)  .tmp_System.map' &&)                \
>-	  $(cmd_sysmap) .tmp_vmlinux$(last_kallsyms) .tmp_System.map
>-	$(Q)cmp -s System.map .tmp_System.map ||                             \
>-		(echo Inconsistent kallsyms data;                            \
>-		 echo Try setting CONFIG_KALLSYMS_EXTRA_PASS;                \
>-		 rm .tmp_kallsyms* ; /bin/false )
>-endef

I am not happy about removing the check for inconsistent kallsyms data.
Changes to the tool chain could cause this problem to recur and we
would not pick up on it.  If we do keep the check for inconsistent data
then we still need some way for the user to continue while the problem
is investigated.

Since your real complaint seems to be the extra time taken in make
allyesconfig then the solution is easy.  Change CONFIG_KALLSYMS_EXTRA_PASS
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sam Ravnborg | 7 Jun 2008 12:51
Gravatar

Re: [RFC PATCH] drop support for KALLSYMS_EXTRA_PASS

On Thu, Jun 05, 2008 at 07:19:24PM +1000, Keith Owens wrote:
> Sam Ravnborg (on Tue, 3 Jun 2008 23:07:32 +0200) wrote:
> >We have not seen any reports on inconsistent kallsysms data recently
> >as in the last one or two years. At least I do not recall these
> >and google had no hits in my searching.
> >
> >So I suggest removing this as to simplify the final linking.
> >When doing "make allyesconfig" build this extra linking
> >takes considerably time (and I usually forgoet to turn it off).
> >
> >In addition this patch removes the debug target: debug_kallsyms
> >
> >diff --git a/Makefile b/Makefile
> >-define verify_kallsyms
> >-	$(Q)$(if $($(quiet)cmd_sysmap),                                      \
> >-	  echo '  $($(quiet)cmd_sysmap)  .tmp_System.map' &&)                \
> >-	  $(cmd_sysmap) .tmp_vmlinux$(last_kallsyms) .tmp_System.map
> >-	$(Q)cmp -s System.map .tmp_System.map ||                             \
> >-		(echo Inconsistent kallsyms data;                            \
> >-		 echo Try setting CONFIG_KALLSYMS_EXTRA_PASS;                \
> >-		 rm .tmp_kallsyms* ; /bin/false )
> >-endef
> 
> I am not happy about removing the check for inconsistent kallsyms data.
> Changes to the tool chain could cause this problem to recur and we
> would not pick up on it.  If we do keep the check for inconsistent data
> then we still need some way for the user to continue while the problem
> is investigated.
> 
> Since your real complaint seems to be the extra time taken in make
(Continue reading)

Permalink | Reply | 0 comments |

Gmane