Re: objcopy / binary inclusion weirdness (repost)

[Anders Norlander <anorland at synergenix dot se>]

Another option is to use the recently added .incbin assembler
directive (which was added to solve precisely these kind
of problems) to get full control over the symbols.

You could then do something like this:

== sprite.s
	.data
	.globl sprite

sprite:
	.incbin "sprite.dat"

	.globl sprite_size
sprite_size:
	.word . - sprite

== test.c
extern char sprite[];
extern int sprite_size;
.
.
printf ("size=%d, value=%x\n", sprite_size, sprite[0]);
.
.

gcc -o test.elf test.c sprite.s

Regards,
Anders

On Wed, 2002-02-27 at 12:16, Matthew Bloch wrote:
> On Wednesday 27 February 2002 8:33 am, Nick Clifton wrote:
> > Hi Matthew,
> >
> > > objcopy -I binary -O elf32-arm sprite sprite.o
> > > gcc -o test.elf test.c
> > > objcopy -O binary test.elf test.gba
> >
> > I assume that you are including sprite.o on that gcc command line as
> > well ?
> 
> Oh, umm, yes.  Thanks for the explanations!  It's confusing that you're 
> always given the impression that char* == char[] types in C, but it's not 
> entirely accurate in this case.
> 
> > > Can somebody tell me whether I should be passing different arguments
> > > to objcopy to get it to generate binaries that can be referenced
> > > sensibly from C,
> >
> > Sorry - objcopy does not have any way to change the construction of
> > these symbols.
> 
> Okay so if I want a proper externally referencable int I should convert my 
> binaries to C / ASM and compile them into object files that way?  Fair enough.
> 
> thanks again,
> 
> -- 
> Matthew       > http://www.soup-kitchen.net/
>               > ICQ 19482073
>