Here is the patch with the ld option check as well.
I had to make a few changes to Ron's original patch. One of the problems was that CFLAGS was being set as a := in the Makefile and was overwriting the += that was in Makefile.settings. So I added DISTRO_CFLAGS and DISTRO_LFLAGS for the two additonal flags. The reason for two was that the build-id option is only used during linking and generated warnings if used on a compile line and was not being pulled in for the linker lines. These defines were added to the appropriate places in the Makefile via the Config.lb file.
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
ron minnich wrote:
On Jan 3, 2008 10:33 AM, Marc Karasek Marc.Karasek@sun.com wrote:
I could add the check to this patch (using awk to check ld) to add the -Wl option to the EXTRA_CFLAGS.
cool! I'll take it and add it.
ron
Think this got lost in the noise..
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Marc Karasek wrote:
Here is the patch with the ld option check as well.
I had to make a few changes to Ron's original patch. One of the problems was that CFLAGS was being set as a := in the Makefile and was overwriting the += that was in Makefile.settings. So I added DISTRO_CFLAGS and DISTRO_LFLAGS for the two additonal flags. The reason for two was that the build-id option is only used during linking and generated warnings if used on a compile line and was not being pulled in for the linker lines. These defines were added to the appropriate places in the Makefile via the Config.lb file.
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
ron minnich wrote:
On Jan 3, 2008 10:33 AM, Marc Karasek Marc.Karasek@sun.com wrote:
I could add the check to this patch (using awk to check ld) to add the -Wl option to the EXTRA_CFLAGS.
cool! I'll take it and add it.
ron
I like it. You've tested it I assume.
I like separating out the DISTRO flags the way you have done. It makes it very clear what flag is related to what function.
I realized this fix took a while, but I think the slow nature of the process got us to the ideal result. We're really using the buildtarget script in the way we originally intended it to used. I really appreciate your patience while we figured this problem out.
Thanks
Acked-by: Ronald G. Minnch rminnich@gmail.com
ron p.s. do you need me to do the commit or can you?
I have tested it on my fedora 8 machine. It would be nice to have it testd on a different disto that has a older ld version. Just as a sanity check.
I think I can do the commit from here. I have not used svn before but it seems to be pretty easy. Basically, I should do a fresh checkout from tip, then apply the patch and do a commit from there, right?
No problem on the wait. I always say i it is worth doing it is worth doing right the first time!
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
ron minnich wrote:
I like it. You've tested it I assume.
I like separating out the DISTRO flags the way you have done. It makes it very clear what flag is related to what function.
I realized this fix took a while, but I think the slow nature of the process got us to the ideal result. We're really using the buildtarget script in the way we originally intended it to used. I really appreciate your patience while we figured this problem out.
Thanks
Acked-by: Ronald G. Minnch rminnich@gmail.com
ron p.s. do you need me to do the commit or can you?
On 1/3/08, Marc Karasek Marc.Karasek@sun.com wrote:
Here is the patch with the ld option check as well.
I had to make a few changes to Ron's original patch. One of the problems was that CFLAGS was being set as a := in the Makefile and was overwriting the += that was in Makefile.settings. So I added DISTRO_CFLAGS and DISTRO_LFLAGS for the two additonal flags. The reason for two was that the build-id option is only used during linking and generated warnings if used on a compile line and was not being pulled in for the linker lines. These defines were added to the appropriate places in the Makefile via the Config.lb file.
Are you sure the buildtarget change is right? It seems to be doing just the opposite of what we want, adding --build-id=none only if build-id is _not_ found in ld --help.
Also it would be very helpful if you could submit patches in a form that patch or quilt can grok; they both choked on the one you sent.
--Ed
Ed sorry for the duplicate, but I only originally replied to you.
I will take a look at it. When I ran it it did add the option on my system. The only question I had was for an older ld version would it behave properly.
I did the patch using svn diff from the tree. Is there another way to generate it?
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Ed Swierk wrote:
On 1/3/08, Marc Karasek Marc.Karasek@sun.com wrote:
Here is the patch with the ld option check as well.
I had to make a few changes to Ron's original patch. One of the problems was that CFLAGS was being set as a := in the Makefile and was overwriting the += that was in Makefile.settings. So I added DISTRO_CFLAGS and DISTRO_LFLAGS for the two additonal flags. The reason for two was that the build-id option is only used during linking and generated warnings if used on a compile line and was not being pulled in for the linker lines. These defines were added to the appropriate places in the Makefile via the Config.lb file.
Are you sure the buildtarget change is right? It seems to be doing just the opposite of what we want, adding --build-id=none only if build-id is _not_ found in ld --help.
Also it would be very helpful if you could submit patches in a form that patch or quilt can grok; they both choked on the one you sent.
--Ed
I did the patch using svn diff from the tree. Is there another way to generate it?
If you have just the changes you want to include in the tree, you can go one level up and do
svn diff LinuxBIOSv2
This makes it easier for me. Then I use the -p1 option to patch and it finds the files correctly.
It looks like you did
svn diff file1 >diff1 svn diff file2 >diff2 svn diff file3 >diff3
And then put the resulting files together. Because a line got deleted from the end of the src/config/Config.lb diff, it complains about a malformed patch and doesn't do the next two.
Then again, maybe that line disappeared another way.
Myles
On 1/4/08, Marc Karasek Marc.Karasek@sun.com wrote:
Ed sorry for the duplicate, but I only originally replied to you.
I will take a look at it. When I ran it it did add the option on my system. The only question I had was for an older ld version would it behave properly.
Try running this snippet from buildtarget in a shell and you'll see what I mean:
ld --help | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END {exit n}'; build_id=$?; echo -n 'ld supports --build-id? '; if [ $build_id \ ]; then echo 'yes'; else echo 'no'; fi
I did the patch using svn diff from the tree. Is there another way to generate it?
Not sure...
--Ed
Sorry about the patch, I had to edit it out for some other changes that got pulled into the file and accidentally deleted a line that should have been there. This patch should be better.
And I also did a svn diff one level up in the tree (flags.patch)
I made a test script and ran it and it sets build_id = 1 properly. I have also included this script.
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Ed Swierk wrote:
On 1/4/08, Marc Karasek Marc.Karasek@sun.com wrote:
Ed sorry for the duplicate, but I only originally replied to you.
I will take a look at it. When I ran it it did add the option on my system. The only question I had was for an older ld version would it behave properly.
Try running this snippet from buildtarget in a shell and you'll see what I mean:
ld --help | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END {exit n}'; build_id=$?; echo -n 'ld supports --build-id? '; if [ $build_id \ ]; then echo 'yes'; else echo 'no'; fi
I did the patch using svn diff from the tree. Is there another way to generate it?
Not sure...
--Ed
It doesn't work for me. It says build-id is supported, and it's not.
The script I attached works for me, though.
Myles
On Jan 4, 2008 3:48 PM, Marc Karasek Marc.Karasek@sun.com wrote:
Sorry about the patch, I had to edit it out for some other changes that got pulled into the file and accidentally deleted a line that should have been there. This patch should be better.
And I also did a svn diff one level up in the tree (flags.patch)
I made a test script and ran it and it sets build_id = 1 properly. I have also included this script.
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Ed Swierk wrote:
On 1/4/08, Marc Karasek Marc.Karasek@sun.com wrote:
Ed sorry for the duplicate, but I only originally replied to you.
I will take a look at it. When I ran it it did add the option on my system. The only question I had was for an older ld version would it behave properly.
Try running this snippet from buildtarget in a shell and you'll see what I mean:
ld --help | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END {exit n}'; build_id=$?; echo -n 'ld supports --build-id? '; if [ $build_id \ ]; then echo 'yes'; else echo 'no'; fi
I did the patch using svn diff from the tree. Is there another way to generate it?
Not sure...
--Ed
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
On 1/4/08, Marc Karasek Marc.Karasek@sun.com wrote:
I made a test script and ran it and it sets build_id = 1 properly. I have also included this script.
The problem is that on Planet Bourne, zero means true and nonzero means false.
--Ed
After looking at the script Myles sent, I immediately saw the problem. I forgot that if [ $build_id ] will always be true because it checks to see if it is defined not the value of build_id. My bad, sorry.
I have made the changes and added an == 1 to the if statement. Attached is the new and I hope final patch file for this.
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Ed Swierk wrote:
On 1/4/08, Marc Karasek Marc.Karasek@sun.com wrote:
I made a test script and ran it and it sets build_id = 1 properly. I have also included this script.
The problem is that on Planet Bourne, zero means true and nonzero means false.
--Ed
On Jan 7, 2008 8:15 AM, Marc Karasek Marc.Karasek@sun.com wrote:
After looking at the script Myles sent, I immediately saw the problem. I forgot that if [ $build_id ] will always be true because it checks to see if it is defined not the value of build_id. My bad, sorry.
I have made the changes and added an == 1 to the if statement. Attached is the new and I hope final patch file for this.
It works for me (it doesn't add the load option.)
Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson myles@pel.cs.byu.edu
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Ed Swierk wrote:
On 1/4/08, Marc Karasek Marc.Karasek@sun.com wrote:
I made a test script and ran it and it sets build_id = 1 properly. I have also included this script.
The problem is that on Planet Bourne, zero means true and nonzero means false.
--Ed
On 1/7/08, Myles Watson myles@pel.cs.byu.edu wrote:
Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
Using grep instead of awk would address this issue, and is a bit simpler (see attached).
Also, is it appropriate to commit the change to src/arch/i386/lib/id.lds as a "temporary fix" with a magic value for _ROMTEMP if no one really understands why the commented-out code doesn't work?
--Ed
On Jan 7, 2008 8:59 AM, Ed Swierk eswierk@arastra.com wrote:
On 1/7/08, Myles Watson myles@pel.cs.byu.edu wrote:
Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
Using grep instead of awk would address this issue, and is a bit simpler (see attached).
This patch is not ready, let's give it one or two more iterations. Marc, can you try Ed's change?
Also, is it appropriate to commit the change to src/arch/i386/lib/id.lds as a "temporary fix" with a magic value for _ROMTEMP if no one really understands why the commented-out code doesn't work?
No.
Thanks
ron
So what is the general consensus ==1 or >0?
Also, I think I know how to commit back to the tree, but do I need a user account for this?
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Myles Watson wrote:
On Jan 7, 2008 8:15 AM, Marc Karasek Marc.Karasek@sun.com wrote:
After looking at the script Myles sent, I immediately saw the problem. I forgot that if [ $build_id ] will always be true because it checks to see if it is defined not the value of build_id. My bad, sorry.
I have made the changes and added an == 1 to the if statement. Attached is the new and I hope final patch file for this.
It works for me (it doesn't add the load option.)
Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson myles@pel.cs.byu.edu
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Ed Swierk wrote:
On 1/4/08, Marc Karasek Marc.Karasek@sun.com wrote:
I made a test script and ran it and it sets build_id = 1 properly. I have also included this script.
The problem is that on Planet Bourne, zero means true and nonzero means false.
--Ed
On Jan 8, 2008 2:41 PM, Marc Karasek Marc.Karasek@sun.com wrote:
So what is the general consensus ==1 or >0?
I prefer > 0
Also, I think I know how to commit back to the tree, but do I need a user account for this?
yes, but get us the patch and we'll deal with the commit issue seperately.
ron
On Jan 8, 2008 3:41 PM, Marc Karasek Marc.Karasek@sun.com wrote:
So what is the general consensus ==1 or >0?
I like the idea of using grep. It seems much cleaner, and avoids that issue.
The other sticking point for the patch the changes in src/arch/i386/lib/id.lds (See Ed's last message.)
Myles
Also, I think I know how to commit back to the tree, but do I need a user account for this?
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Myles Watson wrote:
On Jan 7, 2008 8:15 AM, Marc Karasek Marc.Karasek@sun.com wrote:
After looking at the script Myles sent, I immediately saw the problem. I forgot that if [ $build_id ] will always be true because it checks to see if it is defined not the value of build_id. My bad, sorry.
I have made the changes and added an == 1 to the if statement. Attached is the new and I hope final patch file for this.
It works for me (it doesn't add the load option.)
Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson myles@pel.cs.byu.edu
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Ed Swierk wrote:
On 1/4/08, Marc Karasek Marc.Karasek@sun.com wrote:
I made a test script and ran it and it sets build_id = 1 properly. I have also included this script.
The problem is that on Planet Bourne, zero means true and nonzero means false.
--Ed
Attached is the latest.
It uses -ge instead of == or >. This will take care of any time that there are more than 1 build-id in the ld -help output.
To address Myles concerns about the id.lds changes. This was due to a bug I could not track down. I left the original code in and comments were added as to the why for this change. I could not find a better work around, or find the root cause for this problem.
I will try to debug this further and provide some output to the group.
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Myles Watson wrote:
On Jan 8, 2008 3:41 PM, Marc Karasek Marc.Karasek@sun.com wrote:
So what is the general consensus ==1 or >0?
I like the idea of using grep. It seems much cleaner, and avoids that issue.
The other sticking point for the patch the changes in src/arch/i386/lib/id.lds (See Ed's last message.)
Myles
Also, I think I know how to commit back to the tree, but do I need a user account for this?
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Myles Watson wrote:
On Jan 7, 2008 8:15 AM, Marc Karasek Marc.Karasek@sun.com wrote:
After looking at the script Myles sent, I immediately saw the problem. I forgot that if [ $build_id ] will always be true because it checks to see if it is defined not the value of build_id. My bad, sorry.
I have made the changes and added an == 1 to the if statement. Attached is the new and I hope final patch file for this.
It works for me (it doesn't add the load option.)
Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson myles@pel.cs.byu.edu
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Ed Swierk wrote:
On 1/4/08, Marc Karasek Marc.Karasek@sun.com wrote:
I made a test script and ran it and it sets build_id = 1 properly. I have also included this script.
The problem is that on Planet Bourne, zero means true and nonzero means false.
--Ed
Hi!
To bring this issue to an end, I resolved all conflicts the patch had against the current tree and regenerated it without the controversial id.lds section.
On 09.01.2008 16:13, Marc Karasek wrote:
Attached is the latest.
It uses -ge instead of == or >. This will take care of any time that there are more than 1 build-id in the ld -help output.
Myles Watson wrote:
I like the idea of using grep. It seems much cleaner, and avoids that issue.
Myles Watson wrote:
On Jan 7, 2008 8:15 AM, Marc Karasek Marc.Karasek@sun.com wrote: Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson myles@pel.cs.byu.edu
If we used grep, the buildtarget snippet could probably be made a bit smaller: ld --help | grep -q build-id && EXTRA_LFLAGS+=" -Wl,--build-id=none"
Next try (does not (yet?) use grep):
Marc, I could not find your Signed-off-by: in the thread. If that patch is OK for you, please sign off on it.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: LinuxBIOSv2-ldissue/src/config/Config.lb =================================================================== --- LinuxBIOSv2-ldissue/src/config/Config.lb (Revision 3062) +++ LinuxBIOSv2-ldissue/src/config/Config.lb (Arbeitskopie) @@ -8,7 +8,7 @@ makedefine GCC_INC_DIR := $(shell LC_ALL=C $(CC) -print-search-dirs | sed -ne "s/install: (.*)/\1include/gp")
makedefine CPPFLAGS := -I$(TOP)/src/include -I$(TOP)/src/arch/$(ARCH)/include -I$(GCC_INC_DIR) $(CPUFLAGS) -makedefine CFLAGS := $(CPU_OPT) $(CPPFLAGS) -Os -nostdinc -nostdlib -fno-builtin -Wall +makedefine CFLAGS := $(CPU_OPT) $(DISTRO_CFLAGS) $(CPPFLAGS) -Os -nostdinc -nostdlib -fno-builtin -Wall
makedefine HOSTCFLAGS:= -Os -Wall
@@ -38,14 +38,15 @@ action "ar cr coreboot.a $(OBJECTS)" end
+ makerule coreboot_ram.o depends "$(DRIVER) coreboot.a $(LIBGCC_FILE_NAME)" - action "$(CC) -nostdlib -r -o $@ c_start.o $(DRIVER) coreboot.a $(LIBGCC_FILE_NAME)" + action "$(CC) $(DISTRO_LFLAGS) -nostdlib -r -o $@ c_start.o $(DRIVER) coreboot.a $(LIBGCC_FILE_NAME)" end
makerule coreboot_ram depends "coreboot_ram.o $(TOP)/src/config/coreboot_ram.ld ldoptions" - action "$(CC) -nostdlib -nostartfiles -static -o $@ -T $(TOP)/src/config/coreboot_ram.ld coreboot_ram.o" + action "$(CC) $(DISTRO_LFLAGS) -nostdlib -nostartfiles -static -o $@ -T $(TOP)/src/config/coreboot_ram.ld coreboot_ram.o" action "$(CROSS_COMPILE)nm -n coreboot_ram | sort > coreboot_ram.map" end
@@ -83,12 +84,12 @@
makerule coreboot_apc.o depends "coreboot_apc.a c_start.o $(LIBGCC_FILE_NAME)" - action "$(CC) -nostdlib -r -o $@ c_start.o coreboot_apc.a $(LIBGCC_FILE_NAME)" + action "$(CC) $(DISTRO_LFLAGS) -nostdlib -r -o $@ c_start.o coreboot_apc.a $(LIBGCC_FILE_NAME)" end
makerule coreboot_apc depends "coreboot_apc.o $(TOP)/src/config/coreboot_apc.ld ldoptions" - action "$(CC) -nostdlib -nostartfiles -static -o $@ -T $(TOP)/src/config/coreboot_apc.ld coreboot_apc.o" + action "$(CC) $(DISTRO_LFLAGS) -nostdlib -nostartfiles -static -o $@ -T $(TOP)/src/config/coreboot_apc.ld coreboot_apc.o" action "$(CROSS_COMPILE)nm -n coreboot_apc | sort > coreboot_apc.map" end
@@ -121,7 +122,7 @@
makerule coreboot depends "crt0.o $(INIT-OBJECTS) $(COREBOOT_APC) $(COREBOOT_RAM_ROM) ldscript.ld" - action "$(CC) -nostdlib -nostartfiles -static -o $@ -T ldscript.ld crt0.o $(INIT-OBJECTS)" + action "$(CC) $(DISTRO_LFLAGS) -nostdlib -nostartfiles -static -o $@ -T ldscript.ld crt0.o $(INIT-OBJECTS)" action "$(CROSS_COMPILE)nm -n coreboot | sort > coreboot.map" end
Index: LinuxBIOSv2-ldissue/targets/buildtarget =================================================================== --- LinuxBIOSv2-ldissue/targets/buildtarget (Revision 3062) +++ LinuxBIOSv2-ldissue/targets/buildtarget (Arbeitskopie) @@ -69,9 +69,16 @@
rm -rf .$$.tmp
+ld --help | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END {exit n}' +build_id=$? +if [ $build_id -ge 1 ] ; then + EXTRA_LFLAGS+=" -Wl,--build-id=none" +fi + for i in $build_dir/Makefile.settings $build_dir/*/Makefile.settings do - echo CFLAGS+=$EXTRA_CFLAGS >>$i + echo DISTRO_CFLAGS+=$EXTRA_CFLAGS >>$i + echo DISTRO_LFLAGS+=$EXTRA_LFLAGS >>$i done
exit $?
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
Hi!
To bring this issue to an end, I resolved all conflicts the patch had against the current tree and regenerated it without the controversial id.lds section.
On 09.01.2008 16:13, Marc Karasek wrote:
Attached is the latest.
It uses -ge instead of == or >. This will take care of any time that there are more than 1 build-id in the ld -help output.
Myles Watson wrote:
I like the idea of using grep. It seems much cleaner, and avoids that issue.
Myles Watson wrote:
On Jan 7, 2008 8:15 AM, Marc Karasek Marc.Karasek@sun.com wrote: Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson myles@pel.cs.byu.edu
If we used grep, the buildtarget snippet could probably be made a bit smaller: ld --help | grep -q build-id && EXTRA_LFLAGS+=" -Wl,--build-id=none"
Next try (does not (yet?) use grep):
Marc, I could not find your Signed-off-by: in the thread. If that patch is OK for you, please sign off on it.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Works fine for me.
Acked-by: Joseph Smith joe@smittys.pointclark.net
Thanks - Joe
Hi Marc!
To commit your patch, I need a signoff from you because you created the patch. Please see http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure for details.
Thanks!
On 19.01.2008 23:15, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
To bring this issue to an end, I resolved all conflicts the patch had against the current tree and regenerated it without the controversial id.lds section.
On 09.01.2008 16:13, Marc Karasek wrote:
Attached is the latest.
It uses -ge instead of == or >. This will take care of any time that there are more than 1 build-id in the ld -help output.
Myles Watson wrote:
I like the idea of using grep. It seems much cleaner, and avoids that issue.
Myles Watson wrote:
On Jan 7, 2008 8:15 AM, Marc Karasek Marc.Karasek@sun.com wrote: Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson myles@pel.cs.byu.edu
If we used grep, the buildtarget snippet could probably be made a bit smaller: ld --help | grep -q build-id && EXTRA_LFLAGS+=" -Wl,--build-id=none"
Next try (does not (yet?) use grep):
Marc, I could not find your Signed-off-by: in the thread. If that patch is OK for you, please sign off on it.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Works fine for me.
Acked-by: Joseph Smith joe@smittys.pointclark.net
Thanks for testing, Joe!
Regards, Carl-Daniel
Been away for the weekend. Sun was closed on Monday.
Signed of by Marc Karasek marc.karasek@sun.com
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Carl-Daniel Hailfinger wrote:
Hi!
To bring this issue to an end, I resolved all conflicts the patch had against the current tree and regenerated it without the controversial id.lds section.
On 09.01.2008 16:13, Marc Karasek wrote:
Attached is the latest.
It uses -ge instead of == or >. This will take care of any time that there are more than 1 build-id in the ld -help output.
Myles Watson wrote:
I like the idea of using grep. It seems much cleaner, and avoids that issue.
Myles Watson wrote:
On Jan 7, 2008 8:15 AM, Marc Karasek Marc.Karasek@sun.com wrote: Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson myles@pel.cs.byu.edu
If we used grep, the buildtarget snippet could probably be made a bit smaller: ld --help | grep -q build-id && EXTRA_LFLAGS+=" -Wl,--build-id=none"
Next try (does not (yet?) use grep):
Marc, I could not find your Signed-off-by: in the thread. If that patch is OK for you, please sign off on it.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Index: LinuxBIOSv2-ldissue/src/config/Config.lb
--- LinuxBIOSv2-ldissue/src/config/Config.lb (Revision 3062) +++ LinuxBIOSv2-ldissue/src/config/Config.lb (Arbeitskopie) @@ -8,7 +8,7 @@ makedefine GCC_INC_DIR := $(shell LC_ALL=C $(CC) -print-search-dirs | sed -ne "s/install: (.*)/\1include/gp")
makedefine CPPFLAGS := -I$(TOP)/src/include -I$(TOP)/src/arch/$(ARCH)/include -I$(GCC_INC_DIR) $(CPUFLAGS) -makedefine CFLAGS := $(CPU_OPT) $(CPPFLAGS) -Os -nostdinc -nostdlib -fno-builtin -Wall +makedefine CFLAGS := $(CPU_OPT) $(DISTRO_CFLAGS) $(CPPFLAGS) -Os -nostdinc -nostdlib -fno-builtin -Wall
makedefine HOSTCFLAGS:= -Os -Wall
@@ -38,14 +38,15 @@ action "ar cr coreboot.a $(OBJECTS)" end
makerule coreboot_ram.o depends "$(DRIVER) coreboot.a $(LIBGCC_FILE_NAME)"
- action "$(CC) -nostdlib -r -o $@ c_start.o $(DRIVER) coreboot.a $(LIBGCC_FILE_NAME)"
- action "$(CC) $(DISTRO_LFLAGS) -nostdlib -r -o $@ c_start.o $(DRIVER) coreboot.a $(LIBGCC_FILE_NAME)"
end
makerule coreboot_ram depends "coreboot_ram.o $(TOP)/src/config/coreboot_ram.ld ldoptions"
- action "$(CC) -nostdlib -nostartfiles -static -o $@ -T $(TOP)/src/config/coreboot_ram.ld coreboot_ram.o"
- action "$(CC) $(DISTRO_LFLAGS) -nostdlib -nostartfiles -static -o $@ -T $(TOP)/src/config/coreboot_ram.ld coreboot_ram.o" action "$(CROSS_COMPILE)nm -n coreboot_ram | sort > coreboot_ram.map"
end
@@ -83,12 +84,12 @@
makerule coreboot_apc.o depends "coreboot_apc.a c_start.o $(LIBGCC_FILE_NAME)"
action "$(CC) -nostdlib -r -o $@ c_start.o coreboot_apc.a $(LIBGCC_FILE_NAME)"
action "$(CC) $(DISTRO_LFLAGS) -nostdlib -r -o $@ c_start.o coreboot_apc.a $(LIBGCC_FILE_NAME)"end
makerule coreboot_apc depends "coreboot_apc.o $(TOP)/src/config/coreboot_apc.ld ldoptions"
action "$(CC) -nostdlib -nostartfiles -static -o $@ -T $(TOP)/src/config/coreboot_apc.ld coreboot_apc.o"
action "$(CC) $(DISTRO_LFLAGS) -nostdlib -nostartfiles -static -o $@ -T $(TOP)/src/config/coreboot_apc.ld coreboot_apc.o"@@ -121,7 +122,7 @@
makerule coreboot depends "crt0.o $(INIT-OBJECTS) $(COREBOOT_APC) $(COREBOOT_RAM_ROM) ldscript.ld"
- action "$(CC) -nostdlib -nostartfiles -static -o $@ -T ldscript.ld crt0.o $(INIT-OBJECTS)"
- action "$(CC) $(DISTRO_LFLAGS) -nostdlib -nostartfiles -static -o $@ -T ldscript.ld crt0.o $(INIT-OBJECTS)" action "$(CROSS_COMPILE)nm -n coreboot | sort > coreboot.map"
end
Index: LinuxBIOSv2-ldissue/targets/buildtarget
--- LinuxBIOSv2-ldissue/targets/buildtarget (Revision 3062) +++ LinuxBIOSv2-ldissue/targets/buildtarget (Arbeitskopie) @@ -69,9 +69,16 @@
rm -rf .$$.tmp
+ld --help | awk '{for (i=1;i<=NF;i++) if ($i ~ /build-id/){n++} }; END {exit n}' +build_id=$? +if [ $build_id -ge 1 ] ; then
- EXTRA_LFLAGS+=" -Wl,--build-id=none"
+fi
for i in $build_dir/Makefile.settings $build_dir/*/Makefile.settings do
- echo CFLAGS+=$EXTRA_CFLAGS >>$i
- echo DISTRO_CFLAGS+=$EXTRA_CFLAGS >>$i
- echo DISTRO_LFLAGS+=$EXTRA_LFLAGS >>$i
done
exit $?
On 22.01.2008 16:47, Marc Karasek wrote:
Been away for the weekend. Sun was closed on Monday.
Signed of by Marc Karasek marc.karasek@sun.com
Carl-Daniel Hailfinger wrote:
On 09.01.2008 16:13, Marc Karasek wrote:
Attached is the latest.
It uses -ge instead of == or >. This will take care of any time that there are more than 1 build-id in the ld -help output.
Myles Watson wrote:
I like the idea of using grep. It seems much cleaner, and avoids that issue.
Myles Watson wrote:
Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson myles@pel.cs.byu.edu
If we used grep, the buildtarget snippet could probably be made a bit smaller: ld --help | grep -q build-id && EXTRA_LFLAGS+=" -Wl,--build-id=none"
Next try (does not (yet?) use grep):
Marc, I could not find your Signed-off-by: in the thread. If that patch is OK for you, please sign off on it.
Signed-off-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Thanks, r3073.
Regards, Carl-Daniel
Arugh!!! When I tested the patch eveerything worked ok but now with the new svn version, when I try abuild it get this: ------------------------ Creating builddir...ok Compiling image ..FAILED after 13s! Log excerpt: gcc -m32 -nostdlib -nostartfiles -static -o coreboot_ram -T /home/joe/coreboot-v2/src/config/coreboot_ram.ld coreboot_ram.o collect2: ld terminated with signal 11 [Segmentation fault] make[1]: *** [coreboot_ram] Error 1 make[1]: Leaving directory `/home/joe/coreboot-v2/util/abuild/coreboot-builds/via_epia/normal' make: *** [normal/coreboot.rom] Error 1 ------------------------
Here is my version info: $ ld -v GNU ld version 2.17.50.0.18-1 20070731 $ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
What gives???
Thanks - Joe
here's a positive note, it works fine for me on fc8.
[rminnich@xcpu ga_2761gxdk]$ ld -v -v GNU ld version 2.17.50.0.12-4 20070128 GNU ld version 2.17.50.0.12-4 20070128 [rminnich@xcpu ga_2761gxdk]$ gcc -v -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)
Will try tonight on ubuntu
ron
On 23.01.2008 01:41, joe@smittys.pointclark.net wrote:
Arugh!!! When I tested the patch eveerything worked ok but now with the new svn version, when I try abuild it get this:
Creating builddir...ok Compiling image ..FAILED after 13s! Log excerpt: gcc -m32 -nostdlib -nostartfiles -static -o coreboot_ram -T /home/joe/coreboot-v2/src/config/coreboot_ram.ld coreboot_ram.o collect2: ld terminated with signal 11 [Segmentation fault] make[1]: *** [coreboot_ram] Error 1 make[1]: Leaving directory `/home/joe/coreboot-v2/util/abuild/coreboot-builds/via_epia/normal' make: *** [normal/coreboot.rom] Error 1
Here is my version info: $ ld -v GNU ld version 2.17.50.0.18-1 20070731 $ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
What gives???
That's the ld bug Marc hit as well. I think it is specific to one Fedora version. Maybe it helps to open a bug in the Fedora bugzilla. One of Marc's patches had a workaround for that segfault as well.
Regards, Carl-Daniel
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 23.01.2008 01:41, joe@smittys.pointclark.net wrote:
Arugh!!! When I tested the patch eveerything worked ok but now with the new svn version, when I try abuild it get this:
Creating builddir...ok Compiling image ..FAILED after 13s! Log excerpt: gcc -m32 -nostdlib -nostartfiles -static -o coreboot_ram -T /home/joe/coreboot-v2/src/config/coreboot_ram.ld coreboot_ram.o collect2: ld terminated with signal 11 [Segmentation fault] make[1]: *** [coreboot_ram] Error 1 make[1]: Leaving directory `/home/joe/coreboot-v2/util/abuild/coreboot-builds/via_epia/normal' make: *** [normal/coreboot.rom] Error 1
Here is my version info: $ ld -v GNU ld version 2.17.50.0.18-1 20070731 $ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
What gives???
That's the ld bug Marc hit as well. I think it is specific to one Fedora version. Maybe it helps to open a bug in the Fedora bugzilla. One of Marc's patches had a workaround for that segfault as well.
Regards, Carl-Daniel
It wouldn't be x86_64 related would it?
Thanks - Joe
On 23.01.2008 02:24, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 23.01.2008 01:41, joe@smittys.pointclark.net wrote:
Arugh!!! When I tested the patch eveerything worked ok but now with the new svn version, when I try abuild it get this:
Creating builddir...ok Compiling image ..FAILED after 13s! Log excerpt: gcc -m32 -nostdlib -nostartfiles -static -o coreboot_ram -T /home/joe/coreboot-v2/src/config/coreboot_ram.ld coreboot_ram.o collect2: ld terminated with signal 11 [Segmentation fault] make[1]: *** [coreboot_ram] Error 1 make[1]: Leaving directory `/home/joe/coreboot-v2/util/abuild/coreboot-builds/via_epia/normal' make: *** [normal/coreboot.rom] Error 1
Here is my version info: $ ld -v GNU ld version 2.17.50.0.18-1 20070731 $ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
What gives???
That's the ld bug Marc hit as well. I think it is specific to one Fedora version. Maybe it helps to open a bug in the Fedora bugzilla. One of Marc's patches had a workaround for that segfault as well.
Regards, Carl-Daniel
It wouldn't be x86_64 related would it?
No idea.
Marc?
Regards, Carl-Daniel
It fails on ubuntu. I just did an svn up and:
nput/output = 130304/53382 = 2.441 cp coreboot_ram.nrv2b coreboot_ram.rom echo '/*ldoptions*/' > ldscript.ld; cat ldoptions >> ldscript.ld ; for file in /home/rminnich/src/bios/coreboot-v2/src/arch/i386/init/ldscript.lb /home/rminnich/src/bios/coreboot-v2/src//cpu/x86/32bit/reset32.lds /home/rminnich/src/bios/coreboot-v2/src//southbridge/sis/sis966/id.lds ; do echo /* $file */ >> ldscript.ld; cat $file >> ldscript.ld ; done gcc -m32 -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld crt0.o crt0.o: In function `number': cache_as_ram_auto.c:(.rom.text+0x4f3): undefined reference to `__stack_chk_fail' crt0.o: In function `train_DqsRcvrEn': cache_as_ram_auto.c:(.rom.text+0x2741): undefined reference to `__stack_chk_fail' crt0.o: In function `sdram_set_spd_registers': cache_as_ram_auto.c:(.rom.text+0x5156): undefined reference to `__stack_chk_fail' crt0.o: In function `sdram_initialize': cache_as_ram_auto.c:(.rom.text+0x6565): undefined reference to `__stack_chk_fail' collect2: ld returned 1 exit status make[1]: *** [coreboot] Error 1 make[1]: Leaving directory `/home/rminnich/src/bios/coreboot-v2/targets/gigabyte/ga_2761gxdk/ga_2761gxdk/normal'
This is rev. 3073.
But note: grep stack *settings */*settings Makefile.settings:DISTRO_CFLAGS+=-fno-stack-protector failover/Makefile.settings:DISTRO_CFLAGS+=-fno-stack-protector fallback/Makefile.settings:DISTRO_CFLAGS+=-fno-stack-protector normal/Makefile.settings:DISTRO_CFLAGS+=-fno-stack-protector <oot-v2/targets/gigabyte/ga_2761gxdk/ga_2761gxdk$
So I will have to dig further.
ron
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 23.01.2008 02:24, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 23.01.2008 01:41, joe@smittys.pointclark.net wrote:
Arugh!!! When I tested the patch eveerything worked ok but now with the new svn version, when I try abuild it get this:
Creating builddir...ok Compiling image ..FAILED after 13s! Log excerpt: gcc -m32 -nostdlib -nostartfiles -static -o coreboot_ram -T /home/joe/coreboot-v2/src/config/coreboot_ram.ld coreboot_ram.o collect2: ld terminated with signal 11 [Segmentation fault] make[1]: *** [coreboot_ram] Error 1 make[1]: Leaving directory `/home/joe/coreboot-v2/util/abuild/coreboot-builds/via_epia/normal' make: *** [normal/coreboot.rom] Error 1
Here is my version info: $ ld -v GNU ld version 2.17.50.0.18-1 20070731 $ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
What gives???
That's the ld bug Marc hit as well. I think it is specific to one Fedora version. Maybe it helps to open a bug in the Fedora bugzilla. One of Marc's patches had a workaround for that segfault as well.
Regards, Carl-Daniel
It wouldn't be x86_64 related would it?
No idea.
Marc?
Hmm, after some reading and investigation, I think this maybe a bug in binutils. Looks like other people have had the same problem, I found a few bugs in their bugzilla. Still searching for a cure, Marc?
Thanks - Joe
I hate compiler/tools issues... :-(
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 23.01.2008 02:24, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 23.01.2008 01:41, joe@smittys.pointclark.net wrote:
Arugh!!! When I tested the patch eveerything worked ok but now with the new svn version, when I try abuild it get this:
Creating builddir...ok Compiling image ..FAILED after 13s! Log excerpt: gcc -m32 -nostdlib -nostartfiles -static -o coreboot_ram -T /home/joe/coreboot-v2/src/config/coreboot_ram.ld coreboot_ram.o collect2: ld terminated with signal 11 [Segmentation fault] make[1]: *** [coreboot_ram] Error 1 make[1]: Leaving directory `/home/joe/coreboot-v2/util/abuild/coreboot-builds/via_epia/normal' make: *** [normal/coreboot.rom] Error 1
Here is my version info: $ ld -v GNU ld version 2.17.50.0.18-1 20070731 $ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
What gives???
That's the ld bug Marc hit as well. I think it is specific to one Fedora version. Maybe it helps to open a bug in the Fedora bugzilla. One of Marc's patches had a workaround for that segfault as well.
Regards, Carl-Daniel
It wouldn't be x86_64 related would it?
No idea.
Marc?
Hmm, after some reading and investigation, I think this maybe a bug in binutils. Looks like other people have had the same problem, I found a few bugs in their bugzilla. Still searching for a cure, Marc?
Thanks - Joe
It was not specifically x86_64 related. It was however fedora 8 related. I think in my research that it has to do with the version of binutils. I had sent out a mail to the reflector with a link to another discussion group regarding binutils and a bug that looked like it was this. According to the thread, a patch had been submitted to the binutils tree to fix this issue.
The version of binutils I have that shows this problem is 2.17.50.0.18-1 2007073. I am looking to upgrade to 2.18 as soon as it is avail (rpm) to see if this is fixed.
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Carl-Daniel Hailfinger wrote:
On 23.01.2008 02:24, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 23.01.2008 01:41, joe@smittys.pointclark.net wrote:
Arugh!!! When I tested the patch eveerything worked ok but now with the new svn version, when I try abuild it get this:
Creating builddir...ok Compiling image ..FAILED after 13s! Log excerpt: gcc -m32 -nostdlib -nostartfiles -static -o coreboot_ram -T /home/joe/coreboot-v2/src/config/coreboot_ram.ld coreboot_ram.o collect2: ld terminated with signal 11 [Segmentation fault] make[1]: *** [coreboot_ram] Error 1 make[1]: Leaving directory `/home/joe/coreboot-v2/util/abuild/coreboot-builds/via_epia/normal' make: *** [normal/coreboot.rom] Error 1
Here is my version info: $ ld -v GNU ld version 2.17.50.0.18-1 20070731 $ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
What gives???
That's the ld bug Marc hit as well. I think it is specific to one Fedora version. Maybe it helps to open a bug in the Fedora bugzilla. One of Marc's patches had a workaround for that segfault as well.
Regards, Carl-Daniel
It wouldn't be x86_64 related would it?
No idea.
Marc?
Regards, Carl-Daniel
Quoting Marc Karasek Marc.Karasek@Sun.COM:
It was not specifically x86_64 related. It was however fedora 8 related. I think in my research that it has to do with the version of binutils. I had sent out a mail to the reflector with a link to another discussion group regarding binutils and a bug that looked like it was this. According to the thread, a patch had been submitted to the binutils tree to fix this issue. The version of binutils I have that shows this problem is 2.17.50.0.18-1 2007073. I am looking to upgrade to 2.18 as soon as it is avail (rpm) to see if this is fixed.
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Carl-Daniel Hailfinger wrote:
On 23.01.2008 02:24, joe@smittys.pointclark.net wrote:
Quoting Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net:
On 23.01.2008 01:41, joe@smittys.pointclark.net wrote:
Arugh!!! When I tested the patch eveerything worked ok but now with the new svn version, when I try abuild it get this:
Creating builddir...ok Compiling image ..FAILED after 13s! Log excerpt: gcc -m32 -nostdlib -nostartfiles -static -o coreboot_ram -T /home/joe/coreboot-v2/src/config/coreboot_ram.ld coreboot_ram.o collect2: ld terminated with signal 11 [Segmentation fault] make[1]: *** [coreboot_ram] Error 1 make[1]: Leaving directory `/home/joe/coreboot-v2/util/abuild/coreboot-builds/via_epia/normal' make: *** [normal/coreboot.rom] Error 1
Here is my version info: $ ld -v GNU ld version 2.17.50.0.18-1 20070731 $ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
What gives???
That's the ld bug Marc hit as well. I think it is specific to one Fedora version. Maybe it helps to open a bug in the Fedora bugzilla. One of Marc's patches had a workaround for that segfault as well.
Regards, Carl-Daniel
I found someone that built binutils-2.18.50.0.3-1 rpms here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=27856
I will try it out and report back
Thanks - Joe
Quoting joe@smittys.pointclark.net:
Quoting Marc Karasek Marc.Karasek@Sun.COM:
It was not specifically x86_64 related. It was however fedora 8 related. I think in my research that it has to do with the version of binutils. I had sent out a mail to the reflector with a link to another discussion group regarding binutils and a bug that looked like it was this. According to the thread, a patch had been submitted to the binutils tree to fix this issue. The version of binutils I have that shows this problem is 2.17.50.0.18-1 2007073. I am looking to upgrade to 2.18 as soon as it is avail (rpm) to see if this is fixed.
I found someone that built binutils-2.18.50.0.3-1 rpms here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=27856
I will try it out and report back
SWEET:-) I rpm -Uvh 'd the three packages from the above link (binutils, binutils-devel, binutils-debuginfo) and everything is working great now, coreboot builds with no problems. Back in business again.
Thanks - Joe
Good. now if only ubuntu worked. :-)
ron
So with the -gt change is this patch ok to go?
I will have some more time (maybe) next week to track down further the id.lds problem.
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Myles Watson wrote:
On Jan 8, 2008 3:41 PM, Marc Karasek Marc.Karasek@sun.com wrote:
So what is the general consensus ==1 or >0?
I like the idea of using grep. It seems much cleaner, and avoids that issue.
The other sticking point for the patch the changes in src/arch/i386/lib/id.lds (See Ed's last message.)
Myles
Also, I think I know how to commit back to the tree, but do I need a user account for this?
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Myles Watson wrote:
On Jan 7, 2008 8:15 AM, Marc Karasek Marc.Karasek@sun.com wrote:
After looking at the script Myles sent, I immediately saw the problem. I forgot that if [ $build_id ] will always be true because it checks to see if it is defined not the value of build_id. My bad, sorry.
I have made the changes and added an == 1 to the if statement. Attached is the new and I hope final patch file for this.
It works for me (it doesn't add the load option.)
Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson myles@pel.cs.byu.edu
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Ed Swierk wrote:
On 1/4/08, Marc Karasek Marc.Karasek@sun.com wrote:
I made a test script and ran it and it sets build_id = 1 properly. I have also included this script.
The problem is that on Planet Bourne, zero means true and nonzero means false.
--Ed
On 1/10/08, Marc Karasek Marc.Karasek@sun.com wrote:
So with the -gt change is this patch ok to go?
I will have some more time (maybe) next week to track down further the id.lds problem.
I would prefer to see id.lds left as is, with the workaround code perhaps included in a comment or #if 0, until a better-understood solution is found.
--Ed
Is this patch good to go as is? Or should I pull out the id.lds section for now?
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Myles Watson wrote:
On Jan 8, 2008 3:41 PM, Marc Karasek Marc.Karasek@sun.com wrote:
So what is the general consensus ==1 or >0?
I like the idea of using grep. It seems much cleaner, and avoids that issue.
The other sticking point for the patch the changes in src/arch/i386/lib/id.lds (See Ed's last message.)
Myles
Also, I think I know how to commit back to the tree, but do I need a user account for this?
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Myles Watson wrote:
On Jan 7, 2008 8:15 AM, Marc Karasek Marc.Karasek@sun.com wrote:
After looking at the script Myles sent, I immediately saw the problem. I forgot that if [ $build_id ] will always be true because it checks to see if it is defined not the value of build_id. My bad, sorry.
I have made the changes and added an == 1 to the if statement. Attached is the new and I hope final patch file for this.
It works for me (it doesn't add the load option.)
Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson myles@pel.cs.byu.edu
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Ed Swierk wrote:
On 1/4/08, Marc Karasek Marc.Karasek@sun.com wrote:
I made a test script and ran it and it sets build_id = 1 properly. I have also included this script.
The problem is that on Planet Bourne, zero means true and nonzero means false.
--Ed
After some more investigating I think I have found the core problem with the id.lds file.
I think this is a bug in binutils. if you look at the link below you will see an explanation. I have checked and I am using 2.17.50 on my system. this could explain the problem I am seeing with linking. It seems a check within ld is not working properly for sections that are at the top of an image/memory. (base+size = 0). Looks like a fix has been put into binutils already.
My question is do we leave the patch in place or just make a note somewhere that if you see this problem : 1) Upgrade binutils (if possible) or 2) Make changes to id.lds
http://www.nabble.com/binutils-2.18-and-U-Boot-td14266866.html
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Myles Watson wrote:
On Jan 8, 2008 3:41 PM, Marc Karasek Marc.Karasek@sun.com wrote:
So what is the general consensus ==1 or >0?
I like the idea of using grep. It seems much cleaner, and avoids that issue.
The other sticking point for the patch the changes in src/arch/i386/lib/id.lds (See Ed's last message.)
Myles
Also, I think I know how to commit back to the tree, but do I need a user account for this?
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Myles Watson wrote:
On Jan 7, 2008 8:15 AM, Marc Karasek Marc.Karasek@sun.com wrote:
After looking at the script Myles sent, I immediately saw the problem. I forgot that if [ $build_id ] will always be true because it checks to see if it is defined not the value of build_id. My bad, sorry.
I have made the changes and added an == 1 to the if statement. Attached is the new and I hope final patch file for this.
It works for me (it doesn't add the load option.)
Sorry to be picky, but it seems like this breaks if they mention build-id more than once in the help in the future. I think >0 would be better than ==1.
With that fixed, or if no one thinks that will ever happen: Acked-by: Myles Watson myles@pel.cs.byu.edu
/********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************/
Ed Swierk wrote:
On 1/4/08, Marc Karasek Marc.Karasek@sun.com wrote:
I made a test script and ran it and it sets build_id = 1 properly. I have also included this script.
The problem is that on Planet Bourne, zero means true and nonzero means false.
--Ed
-
Carl-Daniel Hailfinger -
Ed Swierk -
joe＠smittys.pointclark.net -
Marc Karasek -
Myles Watson -
ron minnich