Re: [avr-gcc-list] introducing a new section in data memory
--- On Sat, 2/21/09, Georg-Johann Lay a...@gjlay.de 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
--- On Sat, 2/21/09, Weddington, Eric ewedding...@cso.atmel.com 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
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
-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
-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+79EG-I;VX*879R+6=C8R M
M3W,@+6UM8W4]871M96=A. M8R!T97-T+F,@+...@=5S=YOF%VBUG8V,@
M+6UM8W4]871M96=A. M5VPL+2US96-T:6]N+7-T87)T/2YT97-T/3!X.# P
M,C P(U7;PM+4UA#UT97-T+FUApm+6-r...@=5S=YO(UO('1EW0N
G96QFF%VBUO8FID=6UP(UD('1EW0N96QF(#...@=5S=YD:7,*
`
end
begin 666 test.c
M(VEN8VQU94@/'-TFEN9RYH/@H*=6YS:6=n...@8vaaB!M96TS6S(U-ET@
M7U]A='1R:6)U=5?7R H*'-E8W1I;VXH(BYT97-T(BDI*3L*=6YS:6=N960@
M8VAAB!M96TR6S5=.PH*:6YT(UA:6XH=F]I9D*PH@( @;65MV5T*UE
M;3,L(#!X04$L(#(U-BD[B @( *( @(UE;3-;,3(X72 ](#!X-34[B @
D( *( @(UE;3);,UT@/2 S.PH@( @F5T=7)N(# [GT*
`
end
begin 666 test.dis
M#0IT97-T+F5L9CH@( @(9I;4...@9f]r;6%T(5L9C,R+6%V@T*#0H-D1I
MV%SV5M8FQY(]F('-E8W1I;v...@+g1e'0Z#0H-C P,# P,# P(#Q?7W9E
M8W1OG,^...@t*( @,#H),3(@8S @( @( @7)J;7 )+BLS-B @( @3L@
M,'@R-B \7U]C=]RU]E;F0^#0H@( r...@dr,2!C, @( @( )FIM DN
M*S8V( @( ).R P#0V(#Q?7V)A9%]I;G1EG)U'0^#0H@( t...@dr,!C
M, @( @( )FIM DN*S8T( @( ).R P#0V(#Q?7V)A9%]I;G1EG)U
M'0^#0H@( v...@dq9b!c, @( @( )FIM DN*S8R( @( ).R P#0V
M(#Q?7V)A9%]I;G1EG)U'0^#0H@( x...@dq92!c, @( @( )FIM DN
M*S8P( @( ).R P#0V(#Q?7V)A9%]I;G1EG)U'0^#0H@(!...@dq9!C
M, @( @( )FIM DN*S4X( @( ).R P#0V(#Q?7V)A9%]I;G1EG)U
M'0^#0H@(!...@dq8r!c, @( @( )FIM DN*S4V( @( ).R P#0V
M(#Q?7V)A9%]I;G1EG)U'0^#0H@(!...@dq8b!c, @( @( )FIM DN
M*S4T( @( ).R P#0V(#Q?7V)A9%]I;G1EG)U'0^#0H@(#...@dq82!c
M, @( @( )FIM DN*S4R( @( ).R P#0V(#Q?7V)A9%]I;G1EG)U
M'0^#0H@(#...@dq.2!c, @( @( )FIM DN*S4P( @( ).R P#0V
M(#Q?7V)A9%]I;G1EG)U'0^#0H@(#...@dq.!C, @( @( )FIM DN
M*S0X( @( ).R P#0V(#Q?7V)A9%]I;G1EG)U'0^#0H@(#...@dq-r!c
M, @( @( )FIM DN*S0V( @( ).R P#0V(#Q?7V)A9%]I;G1EG)U
M'0^#0H@(#...@dq-b!c, @( @( )FIM DN*S0T( @( ).R P#0V
M(#Q?7V)A9%]I;G1EG)U'0^#0H@(#...@dq-2!c, @( @( )FIM DN
M*S0R( @( ).R P#0V(#Q?7V)A9%]I;G1EG)U'0^#0H@(#...@dq-!C
M, @( @( )FIM DN*S0P( @( ).R P#0V(#Q?7V)A9%]I;G1EG)U
M'0^#0H@(#...@dq,R!C, @( @( )FIM DN*S,X( @( ).R P#0V
M(#Q?7V)A9%]I;G1EG)U'0^#0H@(#(p...@dq,B!C, @( @( )FIM DN
M*S,V( @( ).R P#0V(#Q?7V)A9%]I;G1EG)U'0^#0H@(#(r...@dq,2!C
M, @( @( )FIM DN*S,T( @( ).R P#0V(#Q?7V)A9%]I;G1EG)U
M'0^#0H@(#(t...@dq,!C, @( @( )FIM DN*S,R( @( ).R P#0V
M(#Q?7V)A9%]I;G1EG)U'0^#0H-C P,# P,#(V(#Q?7V-T;W)S7V5N9#XZ
M#0H@(#(v...@dq,2 R- @( @( )96]R7(Q+!R,0T*( R.#H),6...@8f4@
M( @( @6]U= DP#-F+!R,0D[(#8S#0H@(#)a...@ec9b!e-2 @( @( )
M;1I7(R.P@,'@u...@d[(#DU#0H@(#)c...@ed-!E, @( @( );1I7(R
M.2P@,'@P- D[(#0-B @,F4Z61E()F( @( @( EO=70),'@S92P@C(Y
M3...@-c(-B @,S Z6-D()F( @( @( EO=70),'@S9P@C(X3...@-c$-
M@T*,# P,# P,S(@/%]?9]?8VQE87)?8G-S/CH-B @,S(Z3$P(4P( @
M( @( EL9D)C$W+ P# P3L@, T*( S-#H)83 @938@( @( @6QD
M:0ER,C8L(#!X-C ).R y...@t*( S-CH)8C @93 @( @( @6QD:0ER,CL
M(#!X,# ).R P#0H@(#,x...@dp,2!C, @( @( )FIM DN*S(@( @( )
M.R P#-C(#PN9]?8VQE87)?8G-S7W-T87)T/@T*#0HP,# P,# S82 \+F1O
M7V-L96%R7V)SU]L;V]P/CH-B @,V$Z3%D(#DR( @( @( ES= E8*RP@
MC$-@T*,# P,# P,V,@/YD;U]C;5AE]BW-?W1Ag...@t*( S8SH)
M834@,S8@( @( @6-P:0ER,C8L(#!X-C4).R Q,#$-B @,V4Z6(Q(# W
M( @( @( EC,)C(W+!R,3-B @-# Z64Q(8W( @( @( EBFYE
M2XM. @( @( D[(#!X,V$@/YD;U]C;5AE]BW-?;]O#X-B @-#(Z
M3 R(0P( @( @( ER8V%L; DN*S0@( @( ).R P#0X(#QM86EN/@T*
M( T-#H),3@@8S @( @( @7)J;7 )+BLT. @( @3L@,'@W-B \7V5X
M:70^#0H-C P,#
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 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
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: 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
-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
RE: [avr-gcc-list] introducing a new section in data memory
--- On Fri, 2/20/09, Weddington, Eric ewedding...@cso.atmel.com 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
