avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Creating a hole in the .text section


From: Andy Warner
Subject: Re: [avr-gcc-list] Creating a hole in the .text section
Date: Wed, 20 Oct 2004 09:29:59 -0500
User-agent: Mutt/1.2.5i

Peter Zuur wrote:
> I wrote a boot-loader for the Mega128 and I made a really dumb mistake by 
> thinking that the __asm__ __volatile__ ("jmp 0xf000\n\t" ::) would jump to 
> word address 0xf000. In reality, the avr-gcc assembler works with byte 
> addresses and thus the jump is made to word address 0x7800. This was not an 
> issue until my code size grew to 0xf000 (61440) bytes since the erased flash 
> would cause the program counter to land up at the right address in any case. 
> Now however some real code is sitting there and funny behaviour is obviously 
> the result after using the boot-loader (which restarts itself after a load).
> 
> The solution to this is obviously putting a __asm__ __volatile__ ("jmp 
> 0x1e000\n\t" ::) at byte address 0xf000. It seems that the only way to do 
> this is to create a new section at address 0xf000 and putting the jump in the 
> special section. The linker now obviously complains that the .text and the 
> new section overlap. How do I create a hole in the .text section to prevent 
> this?

I don't know about creating a hole in .text, but here's a fairly ugly
idea that works - albeit with significant caveats:

Create kludge.s along the lines of:

        .file   "kludge.s"
        .arch atmega128
        .text

        .org 0x7800
.kludge:
        jmp  0x1e000

Then link this in with your other binaries at a point in the list of
.o files that puts it in roughly the right place. The problem is that
the .org psuedo op can only move the current location forward in a
section, not backwards, so all the files that follow in the link
order are based off this new offset. So, include it too early and
you waste space, include it too late and it won't work !

You should be able to test that the resulting object file still
fits in the available space, either manually or by a script.
I guess wastage won't matter until you run out of space, so
you should be good to go for a while yet. It will break
(silently) if the .o files included before the kludge mean
that the address is already past 0x7800 before kludge.o is
linked - you can test the final binary with avr-nm to see if
.kludge really lives at 0x7800.

Maybe this can form the basis of a hack, it may be too ugly,
but I'm sure it can be improved. I'm not a linker-script guru,
maybe someone who is can come up with an elegant fix that way.
-- 
address@hidden

Andy Warner             Voice: (612) 801-8549   Fax: (208) 575-5634


reply via email to

[Prev in Thread] Current Thread [Next in Thread]