RE: [avr-gcc-list] introducing a new section in data memory
--- On Sat, 2/21/09, Weddington, Eric wrote: > > It works for me. > > > > See attached demo. After the build look at the .map > file and > > the disassembly file (.dis). > > > > Just realize that because your variable is now in the > .test > Attachment error. Trying again for the list. Thank you very much. Will compile, check and revert. Regards Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] introducing a new section in data memory
--- On Sat, 2/21/09, Georg-Johann Lay wrote: > The trouble might return if .data/.bss will grow and then > overlap(s) No sir, I needed 256 bytes buffers two and the other variables may total to about 10 or so. > The problem is that you cannot > introduce holes in a section, i.e. start with .data, reserve > a hole of 0x100 (or put .stuff in it) and then proceed with > .data. Therefore, there may be a waste of RAM of up to 0xff > bytes. If .data and .test are two adjacent sections, I guess there will be no issue (well they need not be adjacent for that matter). If my .test section starts at a page boundary, it is enough. > The only safe way to do this is > -- supplying own linker script that introduces alignment as > needed. > -- supplying own linker script that introduces sections > .data.lo at >0x60, .test at 0x100, .data.hi at 0x200. But depending > on the >size of .data, you will have to split .bss instead and > explicitely >say that has to go in the .data fragments. Not nice. > -- or allocate 0x1ff bytes and compute the effective > address at runtime. >But then you must access indirect through a pointer. > -- Maybe it's best to take the space from the top of > RAM. Then you will >waste just 0x60 bytes (or can put some other stuff > there), and you >can use direct addressing if you prefer or need that. > Yust init the >stach pointer to an other value by means of -minit-stack > from command >line or simply by __builtin_alloca (0x160) resp. auto > char >test_buffer[0x160] upon entering main(). > > > Just realize that because your variable is now in the > .test section, don't expect the toolchain to > automatically initialize the variable to zeros in the > future. Thank you for the clue. I will take care to init the section myself. >It may do that now, but the toolchain will change to > not include the __do_clear_bss if it detects that there is > nothing in the .bss section. The variable is now outside the > .bss, so there are no guarantees that it will be initialized > to a known value (zeros) in the startup code. > > This can be fixed by renaming the section to .bss.test, as > far as you refer to > http://lists.gnu.org/archive/html/avr-gcc-list/2009-01/msg00162.html > But note that the linker assumes one monolithic section, > and resp. does > the code in __do_clear_bss resp. __do_copy_data! > > Also nothe that there are some bugs in the patch cited > above. > I will fix them as soon I will find the time for it. > > By the way, what is the specification for the handling of > orphans? > Seems as if they are assumed to be adopted by .data? Regards Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] introducing a new section in data memory
> -Original Message- > From: Georg-Johann Lay [mailto:a...@gjlay.de] > Sent: Friday, February 20, 2009 4:05 PM > To: Weddington, Eric > Cc: partha_nay...@yahoo.com; avr-gcc-list > Subject: Re: [avr-gcc-list] introducing a new section in data memory > > Weddington, Eric schrieb: > > The trouble might return if .data/.bss will grow and then overlap(s) > with .test section again. The problem is that you cannot > introduce holes > in a section, i.e. start with .data, reserve a hole of 0x100 (or put > .stuff in it) and then proceed with .data. Therefore, there may be a > waste of RAM of up to 0xff bytes. > > The only safe way to do this is > -- supplying own linker script that introduces alignment as needed. > -- supplying own linker script that introduces sections .data.lo at > 0x60, .test at 0x100, .data.hi at 0x200. But depending on the > size of .data, you will have to split .bss instead and explicitely > say that has to go in the .data fragments. Not nice. > -- or allocate 0x1ff bytes and compute the effective address > at runtime. > But then you must access indirect through a pointer. > -- Maybe it's best to take the space from the top of RAM. > Then you will > waste just 0x60 bytes (or can put some other stuff there), and you > can use direct addressing if you prefer or need that. > Yust init the > stach pointer to an other value by means of -minit-stack > from command > line or simply by __builtin_alloca (0x160) resp. auto char > test_buffer[0x160] upon entering main(). Agreed, on all of the above. I was just merely testing that the toolchain was not giving some weird error, and that, in theory, it could be done. > > Just realize that because your variable is now in the .test > section, don't expect the toolchain to automatically > initialize the variable to zeros in the future. It may do > that now, but the toolchain will change to not include the > __do_clear_bss if it detects that there is nothing in the > .bss section. The variable is now outside the .bss, so there > are no guarantees that it will be initialized to a known > value (zeros) in the startup code. > > This can be fixed by renaming the section to .bss.test, as far as you > refer to > http://lists.gnu.org/archive/html/avr-gcc-list/2009-01/msg00162.html > But note that the linker assumes one monolithic section, and > resp. does > the code in __do_clear_bss resp. __do_copy_data! Hmm. If the OP puts it into .bss.test, that may work for the clearing code in the startup, but then you may not be able to relocate that section with just a command line switch. My guess is that you will have to use a custom linker script. > Also nothe that there are some bugs in the patch cited above. Such as? It works well for most purposes AFIACT. > I will fix them as soon I will find the time for it. Thanks. > By the way, what is the specification for the handling of orphans? > Seems as if they are assumed to be adopted by .data? Could you be more specific? ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] introducing a new section in data memory
Weddington, Eric schrieb:
-Original Message-
From:
avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org
[mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
org] On Behalf Of Parthasaradhi Nayani
Sent: Thursday, February 19, 2009 11:37 AM
To: avr-gcc-list
Subject: [avr-gcc-list] introducing a new section in data memory
Hello all,
I needed to create a buffer of 256 bytes starting at a page
boundary (xx00) in the RAM memory (Mega8).
I added this line in the makefile
LDFLAGs = -wl,--section-start=.test=0x800200
and defined a variable in the .C file (shown below)
unsigned char mem3 __attribute__ ((section(".test")));
However variable mem3 is being assigned address 0x60 in the
controller???
also if I define another global in next line to mem3 I get
error that .data and .bss overlap lma 0xa0??
I am of the opinion that all variable defined with attribute
.test will be located in that memory area and all other
global variables will be located in their native memory.
Perhaps if I ma able locate the .test section properly the
overlap error may vanish. Can you correct the problem please?
Thank you.
It works for me.
See attached demo. After the build look at the .map file and the disassembly
file (.dis).
Hi. Without having read all this thread...
The trouble might return if .data/.bss will grow and then overlap(s)
with .test section again. The problem is that you cannot introduce holes
in a section, i.e. start with .data, reserve a hole of 0x100 (or put
.stuff in it) and then proceed with .data. Therefore, there may be a
waste of RAM of up to 0xff bytes.
The only safe way to do this is
-- supplying own linker script that introduces alignment as needed.
-- supplying own linker script that introduces sections .data.lo at
0x60, .test at 0x100, .data.hi at 0x200. But depending on the
size of .data, you will have to split .bss instead and explicitely
say that has to go in the .data fragments. Not nice.
-- or allocate 0x1ff bytes and compute the effective address at runtime.
But then you must access indirect through a pointer.
-- Maybe it's best to take the space from the top of RAM. Then you will
waste just 0x60 bytes (or can put some other stuff there), and you
can use direct addressing if you prefer or need that. Yust init the
stach pointer to an other value by means of -minit-stack from command
line or simply by __builtin_alloca (0x160) resp. auto char
test_buffer[0x160] upon entering main().
Just realize that because your variable is now in the .test section, don't
expect the toolchain to automatically initialize the variable to zeros in the
future. It may do that now, but the toolchain will change to not include the
__do_clear_bss if it detects that there is nothing in the .bss section. The
variable is now outside the .bss, so there are no guarantees that it will be
initialized to a known value (zeros) in the startup code.
This can be fixed by renaming the section to .bss.test, as far as you
refer to
http://lists.gnu.org/archive/html/avr-gcc-list/2009-01/msg00162.html
But note that the linker assumes one monolithic section, and resp. does
the code in __do_clear_bss resp. __do_copy_data!
Also nothe that there are some bugs in the patch cited above.
I will fix them as soon I will find the time for it.
By the way, what is the specification for the handling of orphans?
Seems as if they are assumed to be adopted by .data?
Georg-Johann
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] introducing a new section in data memory
> -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of Ruud Vlaming > Sent: Friday, February 20, 2009 2:33 PM > To: avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] introducing a new section in data memory > > On Friday 20 February 2009 19:41, Weddington, Eric wrote: > > > Attachment error. Trying again for the list. > > Just to inform you, the first post contained readable and correct > attachments, whereas the second one needs manual uudecoding. > I saw this before on your posts. Somehow it seems posts appear > differently to you as it does to me, or may be others. > I keep forgetting that it's just the avr-libc-dev list that is set strangely that it doesn't take my attachments. I remembered that after I sent the second email. Oh, well. :-/ ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] introducing a new section in data memory
On Friday 20 February 2009 19:41, Weddington, Eric wrote: > Attachment error. Trying again for the list. Just to inform you, the first post contained readable and correct attachments, whereas the second one needs manual uudecoding. I saw this before on your posts. Somehow it seems posts appear differently to you as it does to me, or may be others. regards Ruud ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] introducing a new section in data memory
> > -Original Message-
> > From:
> > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org
> > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
> > org] On Behalf Of Parthasaradhi Nayani
> > Sent: Thursday, February 19, 2009 11:37 AM
> > To: avr-gcc-list
> > Subject: [avr-gcc-list] introducing a new section in data memory
> >
> >
> > Hello all,
> > I needed to create a buffer of 256 bytes starting at a page
> > boundary (xx00) in the RAM memory (Mega8).
> >
> > I added this line in the makefile
> >
> > LDFLAGs = -wl,--section-start=.test=0x800200
> >
> > and defined a variable in the .C file (shown below)
> >
> > unsigned char mem3 __attribute__ ((section(".test")));
> >
> > However variable mem3 is being assigned address 0x60 in the
> > controller???
> >
> > also if I define another global in next line to mem3 I get
> > error that .data and .bss overlap lma 0xa0??
> >
> > I am of the opinion that all variable defined with attribute
> > .test will be located in that memory area and all other
> > global variables will be located in their native memory.
> > Perhaps if I ma able locate the .test section properly the
> > overlap error may vanish. Can you correct the problem please?
> > Thank you.
>
> It works for me.
>
> See attached demo. After the build look at the .map file and
> the disassembly file (.dis).
>
> Just realize that because your variable is now in the .test
> section, don't expect the toolchain to automatically
> initialize the variable to zeros in the future. It may do
> that now, but the toolchain will change to not include the
> __do_clear_bss if it detects that there is nothing in the
> .bss section. The variable is now outside the .bss, so there
> are no guarantees that it will be initialized to a known
> value (zeros) in the startup code.
>
> Eric Weddington
Attachment error. Trying again for the list.
Eric
begin 666 build.sh
M(r...@+v)I;B]S: is...@+7@*879R+6=C8R M+79EPH@(" @;65M'0Z#0H-"C P,# P,# P(#Q?7W9E
M8W1O#0V(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V
M(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V
M(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V
M(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V
M(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V
M(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V(#Q?7V)A9%]I;G1E#0V
M(#Q?7V)A9%]I;G1E#-F+"!R,0D[(#8S#0H@(#)a...@ec9b!e-2 @(" @(" )
M;&1I"7(R."P@,'@u...@d[(#DU#0H@(#)c...@ed-"!E," @(" @(" );&1I"7(R
M.2P@,'@P- D[(#0-"B @,F4Z"61E(&)F(" @(" @( EO=70),'@S92P@# P"3L@, T*(" S-#H)83 @938@(" @(" @"6QD
M:0ER,C8L(#!X-C ).R y...@t*(" S-CH)8C @93 @(" @(" @"6QD:0ER,C#-C(#PN9&]?8VQE87)?8G-S7W-T87)T/@T*#0HP,# P,# S82 \+F1O
M7V-L96%R7V)S#0X(#QM86EN/@T*
M(" T-#H),3@@8S @(" @(" @"7)J;7 )+BLT." @(" @"3L@,'@W-B \7V5X
M:70^#0H-"C P,# P,#0V(#Q?7V)A9%]I;G1E# P"3L@, T*(" T83H).3(@93 @(" @(" @"6QD:0ER,C4L(#!X,#()
M.R R#0H@(#...@dv82!e82 @(" @(" );&1I"7(R,BP@,'A!00D[(#$W, T*
M(" T93H)-S @93 @(" @(" @"6QD:0ER,C,L(#!X,# ).R P#0H@(#...@dt
M,"!E," @(" @(" );&1I"7(R,"P@,'@P, D[(# -"B @-3(Z"34Q(&4P(" @
M(" @( EL9&D)# Q"3L@,0T*(" U-#H),#...@9# @(" @(" @"7)C
M86QL"2XK,3@@(" @( D[(#!X-C@@/&UE;7-E=#X-"B @-38Z"3...@u(&4U(" @
M(" @( EL9&D)#4U"3...@.#4-"B @-...@z"3...@p(#DS(#...@p(# R( ES
M=',),'@P,c...@p+"!R,C0-"B @-6,Z"3...@s(&4P(" @(" @( EL9&D)# S"3L@,PT*(" U93H).# @.3,@-C,@,# @"7-T# P-C,L('(R- T*
M(" V,CH).# @93 @(" @(" @"6QD:0ER,C0L(#!X,# ).R P#0H@(#...@dy
M,"!E," @(" @(" );&1I"7(R-2P@,'@P, D[(# -"B @-C8Z"3 X(#DU(" @
M(" @( ER970-"@T*,# P,# P-C@@/&UE;7-E=#XZ#0H@(#...@ed8r P,2 @
M(" @(" );6]V=PER,C8L('(R- T*(" V83H),#...@8s @(" @(" @"7)J;7 )
M+BLR(" @(" @"3L@,'@V92 \;65M#9C
M(#QM96US970K,'@T/@T*(" W-#H),#@@.34@(" @(" @"7)E= T*#0HP,# P
M,# W-B \7V5X:7...@t*(" W-CH)9C@@.30@(" @(" @"6-L:0T*#0HP,# P
M,# W." \7U]S=&]P7W!R;v=r86...@t*(" W.#H)9...@8v8@(" @(" @"7)J
F;7 )+BTR(" @(" @"3L@,'@W." \7U]S=&]P7W!R;V=R86T^#0H`
`
end
begin 666 test.map
M07)C:&EV92!M96UB97(@:6YC;'5d...@8f5c875s92!o9b!f:6QE("AS>6UB
M;VPI#0H-"F,Z+W!R;V=R86UM92]W:6YA=G(M,C P.3 R,#$O8FEN+RXN+VQI
M8B]G8V,O879R+S0N,RXR+V%V&ET*0T*8SHO<')O9W)A;6UE+W=I
M;F%V6UB;VQS#0I#;VUM;VX@F4@(" @(" @(" @(" @(&9I;&4-"@T*;65M,B @(" @(" @(" @(" @
M(" P>#4@(" @(" @(" @(" @("!T97-T+F\-"@T*365M;W)Y($-O;F9I9W5R
M871I;VX-"@T*3F%M92 @(" @(" @(" @("!/# P.# P,#8P(" @(" @(" @,'@P,# P9F9A
M," @(" @(" @(')W("%X#0IE97!R;VT@(" @(" @(" @(#!X,# X,3 P,# @
M(" @(" @(" P># P,#$P,# P(" @(" @(" @ T*;&]C:R @(" @(" @(" @(" P># P.#,P,# P(" @(" @(" @,'@P
M,# P,#0P," @(" @(" @(')W("%X#0IS:6=N871U# P,# P-# P(" @(" @(" @6YS>6T-
M"B J*"YD>6YS>6TI#0H-"BYD>6YS='(-"B J*"YD>6YS='(I#0H-"BYG;G4N
M=F5R'0N*BD-"B J*"YR96QA+F=N=2YL:6YK;VYC92YT*BD-"@T*+G)E;"YF
M:6yi...@*b@N'0@(" @(" @(" @(#!X,# P,# P,# @(" @(" @
M,'@W80T*("HH+G9E8W1O#(V(&,Z+W!R;V=R86UM92]W:6YA=G(M,C P.3 R,#$O8FEN
M+RXN+VQI8B]G8V,O879R+S0N,RXR+RXN+RXN+RXN+RXN+V%V# P,# P,# P
M(" @(" @(" @(" @(" @(%]?=F5C=&]R7V1E9F%U;'0-"B J*"YV96-T;W)S
M*0T*("HH+G!R;V=M96TN9V-C*BD-"B J*"YP# P,# P,#(V(" @(" @(" @(" @(" @("X@/2!!3$E'3B H
RE: [avr-gcc-list] introducing a new section in data memory
> -Original Message-
> From:
> avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org
> [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.
> org] On Behalf Of Parthasaradhi Nayani
> Sent: Thursday, February 19, 2009 11:37 AM
> To: avr-gcc-list
> Subject: [avr-gcc-list] introducing a new section in data memory
>
>
> Hello all,
> I needed to create a buffer of 256 bytes starting at a page
> boundary (xx00) in the RAM memory (Mega8).
>
> I added this line in the makefile
>
> LDFLAGs = -wl,--section-start=.test=0x800200
>
> and defined a variable in the .C file (shown below)
>
> unsigned char mem3 __attribute__ ((section(".test")));
>
> However variable mem3 is being assigned address 0x60 in the
> controller???
>
> also if I define another global in next line to mem3 I get
> error that .data and .bss overlap lma 0xa0??
>
> I am of the opinion that all variable defined with attribute
> .test will be located in that memory area and all other
> global variables will be located in their native memory.
> Perhaps if I ma able locate the .test section properly the
> overlap error may vanish. Can you correct the problem please?
> Thank you.
It works for me.
See attached demo. After the build look at the .map file and the disassembly
file (.dis).
Just realize that because your variable is now in the .test section, don't
expect the toolchain to automatically initialize the variable to zeros in the
future. It may do that now, but the toolchain will change to not include the
__do_clear_bss if it detects that there is nothing in the .bss section. The
variable is now outside the .bss, so there are no guarantees that it will be
initialized to a known value (zeros) in the startup code.
Eric Weddington
build.sh
Description: build.sh
test.c
Description: test.c
test.map
Description: test.map
test.dis
Description: test.dis
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] introducing a new section in data memory
First off, is that a typo above? It's suppose to be an uppercase 'W' like so: LDFLAGs = -Wl,--section-start=.test=0x800200 Hi, Checked the 'W' and it was indeed capital letter only. The problem persists!! Any more suggestions please? Thank you. Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] introducing a new section in data memory
--- On Fri, 2/20/09, Weddington, Eric wrote: First off, is that a typo above? It's suppose to be an uppercase 'W' like so: LDFLAGs = -Wl,--section-start=.test=0x800200 It was a typo. Will test and reply. Thank you for your time. Regards Nayani ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] introducing a new section in data memory
Hello all,
My sincere apologies for posting the same thread again. I found my original
thread and replies to that post in my spam folder!!! I am surprised why some
mails should land up in spam folder while other from the same mail ID find
themselves in the inbox Thank you.
Parthasaradhi
Hyderabad
--- On Fri, 2/20/09, Parthasaradhi Nayani wrote:
From: Parthasaradhi Nayani
Subject: [avr-gcc-list] introducing a new section in data memory
To: "avr-gcc-list@nongnu.org"
Date: Friday, February 20, 2009, 10:46 AM
Hello all,
I sent a mail on the subject but it seems to have got lost and therefore
posting again
I need to have a buffer of about 256 bytes starting at a page boundary in the
ram of Mega8. To get this I introduced a new section and assigned it an address
in makefile. I defined variables, to test, using attribute section. However
when I try to debug the code I see the variables are allotted memory locations
other than specified in the section?
My makefile has the following statement
LDFLAGs = -wl,--section-start=.test=0x800100
My .C file has the following statements
unsigned char mem3 __attribute__ ((section(".test")));
int mem5 __attribute__ ((section(".test")));
I have also noticed, if I declare a global variable I get overlap error. Please
help me solve this problem. Thank you.
Nayani
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] introducing a new section in data memory
> -Original Message- > From: > avr-gcc-list-bounces+eweddington=cso.atmel@nongnu.org > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel@nongnu. > org] On Behalf Of Parthasaradhi Nayani > Sent: Thursday, February 19, 2009 11:37 AM > To: avr-gcc-list > Subject: [avr-gcc-list] introducing a new section in data memory > > > Hello all, > I needed to create a buffer of 256 bytes starting at a page > boundary (xx00) in the RAM memory (Mega8). > > I added this line in the makefile > > LDFLAGs = -wl,--section-start=.test=0x800200 > First off, is that a typo above? It's suppose to be an uppercase 'W' like so: LDFLAGs = -Wl,--section-start=.test=0x800200 ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
