gnupic: A possible bug with udata


Previous by date: 6 Sep 2004 06:58:45 +0100 Re: A possible bug with udata, Craig Franklin
Next by date: 6 Sep 2004 06:58:45 +0100 Re: A possible bug with udata, Julian Green
Previous in thread: 6 Sep 2004 06:58:45 +0100 Re: A possible bug with udata, Craig Franklin
Next in thread: 6 Sep 2004 06:58:45 +0100 Re: A possible bug with udata, Julian Green

Subject: Re: A possible bug with udata
From: Craig Franklin ####@####.####
Date: 6 Sep 2004 06:58:45 +0100
Message-Id: <413B0D6E.5060809@users.sourceforge.net>

I have added both features to gplink.  The changes are in cvs.

Craig Franklin wrote:

> That linker script defines the 16f871 data memory as all sharebank.
>
> SHAREBANK   NAME=gprnobnk0     START=0x20     END=0x6F
> SHAREBANK   NAME=gprnobnk0     START=0x120    END=0x16F
>
> SHAREBANK   NAME=gprnobnk1     START=0xA0     END=0xBF
> SHAREBANK   NAME=gprnobnk1     START=0x1A0    END=0x1BF
>
> There are no unprotected databank definitions.  Here is an example 
> from the 16f877:
>
> DATABANK   NAME=gpr0     START=0x20     END=0x6F
>
> The linker has a udata section to relocate, but no data sections are 
> defined, so it reports no memory is available.
>
> If you change the directive from udata to udata_shr, it will work.
>
> I tested mplink and it behaves the same way.
>
> 1.  I really could generate a better error message in this case.  
> Maybe I should distinguish between running out of memory and not 
> having any to begin with.  I will put it on my list.
>
> 2.  I have considered relocating udata sections to shared memory, when 
> you run out of unshared memory.  I really never fully considered the 
> consequences.  I will take another look at it.
>
> Julian Green wrote:
>
>> I have constructed a small project that reproduces the problem.
>>
>> I hope .tgz file attachments get through
>>
>> Julian
>>
>> On Sat, 4 Sep 2004, Craig Franklin wrote:
>>
>>  
>>
>>> This can happen if you have used all available data memory or if the
>>> size of the section exceeds the size of one bank on the target device.
>>>
>>> If you send me your code, I can figure out what happened.
>>>
>>> If you can't send me your code, link the project with the "--debug"
>>> flag.  This will print many messages about the internal operation of 
>>> the
>>> linker.  You might be able to figure out what is happening.  Send me 
>>> the
>>> debug message, I can help.
>>>
>>> Julian Green wrote:
>>>
>>>   
>>>
>>>> I am using gputils-0.12.3.
>>>>
>>>> I have a project consisting of a library and a main module from 
>>>> which I
>>>> call library code.   However I am getting a linker error:
>>>>
>>>>     error: no target memory available for section "fbw_u"
>>>>
>>>> If I add an address to the udata declararion I can make the error 
>>>> go away,
>>>> but that defeats the purpose of relocatable modules.
>>>>
>>>>     fbw_u   udata  0x21
>>>>
>>>> Julian
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ####@####.####
>>>> For additional commands, e-mail: ####@####.####
>>>>
>>>>
>>>>
>>>>
>>>>     
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ####@####.####
>>> For additional commands, e-mail: ####@####.####
>>>
>>>   
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ####@####.####
>>> For additional commands, e-mail: ####@####.####
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>


Previous by date: 6 Sep 2004 06:58:45 +0100 Re: A possible bug with udata, Craig Franklin
Next by date: 6 Sep 2004 06:58:45 +0100 Re: A possible bug with udata, Julian Green
Previous in thread: 6 Sep 2004 06:58:45 +0100 Re: A possible bug with udata, Craig Franklin
Next in thread: 6 Sep 2004 06:58:45 +0100 Re: A possible bug with udata, Julian Green


Powered by ezmlm-browse 0.20.