Re: [ECOS] possible ecosconfig bug

[Eric Donnat <e dot donnat at silicomp dot fr>]

On Mon, 21 Jul 2003 10:59:49 -0500
"Andy Dyer" <adyer@righthandtech.com> wrote:

> I think I've found a bug in processing make_object rules
> in a .cdl file.
> 
> In trying to figure out how to add some FPGA configuration
> data into my redboot ROM I tried putting this
> in my .cdl file:
> 
> 	# custom build rule to make spartan2_top.o
> 	make_object {
>         spartan2_top.o.d : <PACKAGE>/src/spartan2_top.bin
>         $(OBJCOPY) -I binary -O elf32-littlemips --rename-section
> .data=.rodata,alloc,load,readonly,data,contents $< $@
>     }
> 
> when I look at the generated makefile, I see:
> 
> spartan2_top.o.d: <PACKAGE>/src/spartan2_top.bin
> 	$(OBJCOPY) -I binary -O elf32-littlemips --rename-section
> .data=.rodata,alloc,load,readonly,data,contents $< $@
> 
> where the <PACKAGE> token didn't get replaced like it says it should in
> http://sources.redhat.com/ecos/docs-latest/cdl-guide/build.make.html#BUI
> LD.CUSTOM
> 
> Looking in tools/src/tools/configtool/common/common/build.cxx I see this
> snippet,
> which looks suspicious in that extra stuff gets done for the make rules
> but not
> the make objects rules.  However, I don't know c++ so I really don't
> know for sure 
> what's going on here...
> 
> 	// generate make objects rules
> 	for (count = 0; count < info.make_objects.size (); count++) { //
> for each make object
> 		fprintf (stream, "%s: %s\n%s\n", info.make_objects
> [count].object.c_str (), info.make_objects[count].deps.c_str (),
> tab_indent (info.make_objects [count].rules).c_str ());
> 	}
> 
> 	// generate makes rules
> 	for (count = 0; count < info.makes.size (); count++) { // for
> each make
> 		fprintf (stream, "%s: $(wildcard %s)\n%s\n",
> resolve_tokens (info.makes [count].target).c_str (), resolve_tokens
> (info.makes [count].deps).c_str (), tab_indent (info.makes
> [count].rules).c_str ());
> 	}
> 

A interesting work-around is to not use objcopy at all. The binary is still
equivalent to the elf file (so the file is duped), and ld can eat any fileformat
too (objcopy and ld share the same bfd code). With a bonus, IMHO, you
can do much more control on imported binary data via an
additionnal .ld script


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss