[U-Boot-Users] maybe just one more bug left in building the examples directory in 1.1.2
Hello I am getting closer to getting the examples code to build. I have added a bunch of object files and library files to the link command in the examples Makefile. However, I have gotten to the last bug and I don't know how to solve it. Below, it complains about __got2_entries. I found this defined in our board directories linker script. The current command line and results: make[1]: Entering directory `/home/davis/cvs/mcp4/uboot/mine/u-boot-1.1.2 /examples' ppc-linux-ld -g -Ttext 0x40000 \ -o hello_world -e hello_world hello_world.o libstubs.a \ /home/davis/cvs/mcp4/uboot/mine/u-boot-1.1.2/cpu/ppc4xx/start.o \ /home/davis/cvs/mcp4/uboot/mine/u-boot-1.1.2/board/fsp1/fsp1_pra.o \ /home/davis/cvs/mcp4/uboot/mine/u-boot-1.1.2/board/fsp1/eddr2.o \ -L/home/davis/cvs/mcp4/uboot/mine/u-boot-1.1.2/common -lcommon \ -L/home/davis/cvs/mcp4/uboot/mine/u-boot-1.1.2/lib_generic -lgeneric \ -L/home/davis/cvs/mcp4/uboot/mine/u-boot-1.1.2/net -lnet \ -L/home/davis/cvs/mcp4/uboot/mine/u-boot-1.1.2/rtc -lrtc \ -L/home/davis/cvs/mcp4/uboot/mine/u-boot-1.1.2/board/fsp1 -lfsp1 \ -L/home/davis/cvs/mcp4/uboot/mine/u-boot-1.1.2/cpu/ppc4xx -lppc4xx \ -L/home/davis/cvs/mcp4/uboot/mine/u-boot-1.1.2/lib_ppc -lppc \ -L/opt/fld_fakeroot/opt/mcp/ppc/bin/../lib/gcc-lib/ppc-linux/3.3.3 -lgcc /home/davis/cvs/mcp4/uboot/mine/u-boot-1.1.2 /cpu/ppc4xx/start.o(.text+0x25ae):/home/davis/cvs/mcp4/uboot/mine/u- boot-1.1.2/cpu/ppc4xx/start.S:1374: undefined reference to `__got2_entries' ppc-linux-ld: BFD 2.15.90.0.1.1 20040303 (SuSE Linux) assertion fail ../../bfd/elf32-ppc.c:5645 make[1]: *** [hello_world] Segmentation fault make[1]: *** Deleting file `hello_world' make[1]: Leaving directory `/home/davis/cvs/mcp4/uboot/mine/u-boot-1.1.2 /examples' make: *** [examples] Error 2 [davis@dyn-9-152-249-44 u-boot-1.1.2]$ The relevant portion of the linker script which defines the __got2_entries variable. board/fsp1/u-boot.lds: ... stuff snipped __got2_entries = (_FIXUP_TABLE_ - _GOT2_TABLE_) >>2; ... stuff snipped Any advice on how to apply this to my makefile is appreciated. JD
Dear John,
in message 6a7ac2300511150252w60601196qea018696ae5d1813@mail.gmail.com you wrote:
I am getting closer to getting the examples code to build. I have added a bunch of object files and library files to the link command in the examples Makefile. However,
I really, really don't understand what you are actually doing. If you put your code in the examples directory, then just adding the binary name to the "BIN" definition in the "examples/Makefile" is *all* you have to do to get it build correctly.
If you prefer to keep the code in your own board directory (which is a much better approach, especially if you intend to submit it as a patch) then just have a look at the trab_fkt* targets in the "board/trab/Makefile".
Nothing more needs to be done. Really.
If this does not work for you, then your toolchain is broken and should be replaced.
I have gotten to the last bug and I don't know how to solve it. Below, it
"the last bug" ??? Famous last words.
complains about __got2_entries. I found this defined in our board
....
ppc-linux-ld: BFD 2.15.90.0.1.1 20040303 (SuSE Linux) assertion fail ../../bfd/elf32-ppc.c:5645 make[1]: *** [hello_world] Segmentation fault
Your tool crashes with a segmentation fault. That's a tolchain problem. Get yourself working tools and forget about all this trouble.
Best regards,
Wolfgang Denk
Hello Wolfgang, Ok. Thank you for the reality check. Could you please tell me where i can get a reliable toolchain so I can end my frustration? FWIW, I am not currently adding new code, I am just trying to get the existing examples directory to build. I talked to my more knowledgeble co-worker and he told me that my approach was not what I wanted anyway. By statically linking to the libraries as I have done, I am not created a loadable applet which is my main goal. Many thanks in advance, JD
On 11/15/05, Wolfgang Denk wd@denx.de wrote:
Dear John,
in message 6a7ac2300511150252w60601196qea018696ae5d1813@mail.gmail.com you wrote:
I am getting closer to getting the examples code to build. I have added
a
bunch of object files and library files to the link command in the
examples
Makefile. However,
I really, really don't understand what you are actually doing. If you put your code in the examples directory, then just adding the binary name to the "BIN" definition in the "examples/Makefile" is *all* you have to do to get it build correctly.
If you prefer to keep the code in your own board directory (which is a much better approach, especially if you intend to submit it as a patch) then just have a look at the trab_fkt* targets in the "board/trab/Makefile".
Nothing more needs to be done. Really.
If this does not work for you, then your toolchain is broken and should be replaced.
I have gotten to the last bug and I don't know how to solve it. Below,
it
"the last bug" ??? Famous last words.
complains about __got2_entries. I found this defined in our board
....
ppc-linux-ld: BFD 2.15.90.0.1.1 20040303 (SuSE Linux) assertion fail ../../bfd/elf32-ppc.c:5645 make[1]: *** [hello_world] Segmentation fault
Your tool crashes with a segmentation fault. That's a tolchain problem. Get yourself working tools and forget about all this trouble.
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Compassion -- that's the one things no machine ever had. Maybe it's the one thing that keeps men ahead of them. -- McCoy, "The Ultimate Computer", stardate 4731.3
Andrew Wozniak | Mercury Computer Systems 978.967.1895 | System SW, ICS Group
John Davis wrote:
Hello Wolfgang,
Ok. Thank you for the reality check. Could you please tell me where i can get a reliable toolchain so I can end my frustration?
FWIW, I am not currently adding new code, I am just trying to get the existing examples directory to build. I talked to my more knowledgeble co-worker and he told me that my approach was not what I wanted anyway. By statically linking to the libraries as I have done, I am not created a loadable applet which is my main goal.
Your co-worker is correct. The U-Boot examples are loadable applets which use the U-Boot application binary interface (ABI) to access U-Boot library functions. The #include <exports.h> entry within hello_world.c defines which library functions are provided by U-Boot.
Since the ABI is used by the examples, you SHOULD NOT attempt to link in generic or other libraries! The example code and makefiles have worked for quite some time now - forget about trying to fix something that is not broken. Instead, focus on your toolchain as suggested Wolfgang.
Many thanks in advance,
JD
On 11/15/05, *Wolfgang Denk* <wd@denx.de mailto:wd@denx.de> wrote:
Dear John, in message < 6a7ac2300511150252w60601196qea018696ae5d1813@mail.gmail.com <mailto:6a7ac2300511150252w60601196qea018696ae5d1813@mail.gmail.com>> you wrote: > > I am getting closer to getting the examples code to build. I have added a > bunch of object files and library files to the link command in the examples > Makefile. However, I really, really don't understand what you are actually doing. If you put your code in the examples directory, then just adding the binary name to the "BIN" definition in the "examples/Makefile" is *all* you have to do to get it build correctly. If you prefer to keep the code in your own board directory (which is a much better approach, especially if you intend to submit it as a patch) then just have a look at the trab_fkt* targets in the "board/trab/Makefile". Nothing more needs to be done. Really. If this does not work for you, then your toolchain is broken and should be replaced. > I have gotten to the last bug and I don't know how to solve it. Below, it "the last bug" ??? Famous last words. > complains about __got2_entries. I found this defined in our board .... > ppc-linux-ld: BFD 2.15.90.0.1.1 20040303 (SuSE Linux) assertion fail > ../../bfd/elf32-ppc.c:5645 > make[1]: *** [hello_world] Segmentation fault Your tool crashes with a segmentation fault. That's a tolchain problem. Get yourself working tools and forget about all this trouble. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de <mailto:wd@denx.de> Compassion -- that's the one things no machine ever had. Maybe it's the one thing that keeps men ahead of them. -- McCoy, "The Ultimate Computer", stardate 4731.3
In message 6a7ac2300511150504x6bbb8bd8pa998bcf2ddaa19f4@mail.gmail.com you wrote:
Ok. Thank you for the reality check. Could you please tell me where i can get a reliable toolchain so I can end my frustration?
ELDK? See http://www.denx.de/wiki/view/DULG/ELDKAvailability
Best regards,
Wolfgang Denk
Hello Wolfgang, Man you are modest. I didn't realize until now that you have your own toolchain as well as working on u-boot. Geez, I feel like a noob. I'll try it out now. Many thanks, JD
On 11/15/05, Wolfgang Denk wd@denx.de wrote:
In message 6a7ac2300511150504x6bbb8bd8pa998bcf2ddaa19f4@mail.gmail.com you wrote:
Ok. Thank you for the reality check. Could you please tell me where i
can
get a reliable toolchain so I can end my frustration?
ELDK? See http://www.denx.de/wiki/view/DULG/ELDKAvailability
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Brontosaurus Principle: Organizations can grow faster than their brains can manage them in relation to their environment and to their own physiology: when this occurs, they are an endangered species.
- Thomas K. Connellan
On Tue, 15 November 2005 12:38:50 +0100, Wolfgang Denk wrote:
in message 6a7ac2300511150252w60601196qea018696ae5d1813@mail.gmail.com you wrote:
"the last bug" ??? Famous last words.
There's always one "last bug" left. ;)
complains about __got2_entries. I found this defined in our board
....
ppc-linux-ld: BFD 2.15.90.0.1.1 20040303 (SuSE Linux) assertion fail ../../bfd/elf32-ppc.c:5645 make[1]: *** [hello_world] Segmentation fault
Your tool crashes with a segmentation fault. That's a tolchain problem. Get yourself working tools and forget about all this trouble.
Not entirely a toolchain problem. Here is a patch that fixes the problem, if the toolchain happens to include the SuSE gcc 3.3.3 "Hammer" compiler. Patch is against git tree on kernel.org.
--- uboot_hammer/examples/stubs.c~hammer 2006-03-08 12:10:07.000000000 +0100 +++ uboot_hammer/examples/stubs.c 2006-03-08 12:17:06.000000000 +0100 @@ -136,7 +136,7 @@ gd_t *global_data; * implementation. On the other hand, asm() statements with * arguments can be used only inside the functions (gcc limitation) */ -#if GCC_VERSION < 3004 +#if GCC_VERSION < 3003 static #endif /* GCC_VERSION */ void __attribute__((unused)) dummy(void)
This patch is clearly unacceptable, as it breaks real gcc 3.3 compilers. But it would still be nice to have some sort of workaround for the SuSE-created problem.
Jörn
In message 20060308112603.GA1116@wohnheim.fh-wedel.de you wrote:
make[1]: *** [hello_world] Segmentation fault
Your tool crashes with a segmentation fault. That's a tolchain problem. Get yourself working tools and forget about all this trouble.
Not entirely a toolchain problem. Here is a patch that fixes the
It is entirely a toolchain problem. No matter what input you feed into it, the linker (like any other program) must NEVER crash with a segmentation fault. There is no excuse for such a bug.
Best regards,
Wolfgang Denk
On Wed, 8 March 2006 12:44:03 +0100, Wolfgang Denk wrote:
In message 20060308112603.GA1116@wohnheim.fh-wedel.de you wrote:
make[1]: *** [hello_world] Segmentation fault
Your tool crashes with a segmentation fault. That's a tolchain problem. Get yourself working tools and forget about all this trouble.
Not entirely a toolchain problem. Here is a patch that fixes the
It is entirely a toolchain problem. No matter what input you feed into it, the linker (like any other program) must NEVER crash with a segmentation fault. There is no excuse for such a bug.
Yes, sure. The "Hammer" compiler has its issues, it has bitten me before and will likely bite me again. The sad fact remains that I'm forced to work with it, after all.
The world is not perfect and we have to deal with it. And I'd claim that compilers aren't perfect and programs have to deal with it as well, within reason. Would it be unreasonable to have a workaround for this problem in U-Boot?
Jörn
In message 20060308121502.GB1116@wohnheim.fh-wedel.de you wrote:
well, within reason. Would it be unreasonable to have a workaround for this problem in U-Boot?
No, of course not, but the workaround must not interfere with any other configuration, and I can't see how to do this. Using the GCC version id is obviously not sufficient here.
Best regards,
Wolfgang Denk
On Wed, 8 March 2006 14:16:54 +0100, Wolfgang Denk wrote:
In message 20060308121502.GB1116@wohnheim.fh-wedel.de you wrote:
well, within reason. Would it be unreasonable to have a workaround for this problem in U-Boot?
No, of course not, but the workaround must not interfere with any other configuration, and I can't see how to do this. Using the GCC version id is obviously not sufficient here.
Correct. So far, the only clue GCC is giving me is this:
$ ppc-linux-gcc --version ppc-linux-gcc (GCC) 3.3.3 (SuSE Linux) ^^^^^^^^^^
So some Makefile magic with a grep, adding a #define and using it in the conditional compile statement would be possible. But maybe there's a nicer solution as well.
Jörn
participants (4)
-
Andrew Wozniak -
John Davis -
Jörn Engel -
Wolfgang Denk