From danilo.d.bojovic at gmail.com Thu Jan 5 13:37:48 2012 From: danilo.d.bojovic at gmail.com (Danilo Bojovic) Date: Thu, 5 Jan 2012 14:37:48 +0100 Subject: [arm-gnu] Cross-compilation issue - Help! Message-ID: Respectable, Can you help me with my issue? Namely, I want to compile my UART driver to run on ARM architecture. I'm using arm2009q3 cross compiler to do that, and during compiling I get this messages: WARNING: "__aeabi_d2iz" [/home/danilo/Desktop/Work/UartDriverSingle/uartDriverSingle0.4/duologUartDriver.ko] undefined! WARNING: "__aeabi_d2uiz" [/home/danilo/Desktop/Work/UartDriverSingle/uartDriverSingle0.4/duologUartDriver.ko] undefined! WARNING: "__aeabi_fmul" [/home/danilo/Desktop/Work/UartDriverSingle/uartDriverSingle0.4/duologUartDriver.ko] undefined! WARNING: "__aeabi_i2d" [/home/danilo/Desktop/Work/UartDriverSingle/uartDriverSingle0.4/duologUartDriver.ko] undefined! WARNING: "__aeabi_f2iz" [/home/danilo/Desktop/Work/UartDriverSingle/uartDriverSingle0.4/duologUartDriver.ko] undefined! WARNING: "__aeabi_dsub" [/home/danilo/Desktop/Work/UartDriverSingle/uartDriverSingle0.4/duologUartDriver.ko] undefined! WARNING: "__aeabi_dadd" [/home/danilo/Desktop/Work/UartDriverSingle/uartDriverSingle0.4/duologUartDriver.ko] undefined! WARNING: "__aeabi_dmul" [/home/danilo/Desktop/Work/UartDriverSingle/uartDriverSingle0.4/duologUartDriver.ko] undefined! WARNING: "__aeabi_dcmplt" [/home/danilo/Desktop/Work/UartDriverSingle/uartDriverSingle0.4/duologUartDriver.ko] undefined! WARNING: "__aeabi_i2f" [/home/danilo/Desktop/Work/UartDriverSingle/uartDriverSingle0.4/duologUartDriver.ko] undefined! I suppose that there is a problem with linking but I'm not so sure. I tried to google it out but with no success. Is there any way to fix this warnings? Because of them I can't insert module into a linux platform that runs on ARM architecture. Is there some option to put in my Makefile or something else to do? Thanks in advance. Kind regards, Danilo Bojovic -------------- next part -------------- An HTML attachment was scrubbed... URL: From linux at bohmer.net Fri Jan 6 16:20:07 2012 From: linux at bohmer.net (Remy Bohmer) Date: Fri, 6 Jan 2012 17:20:07 +0100 Subject: [arm-gnu] Cross-compilation issue - Help! In-Reply-To: References: Message-ID: Hi, 2012/1/5 Danilo Bojovic : > Respectable, > > Can you help me with my issue? Namely, I want to compile my UART driver to > run on ARM architecture. I'm using arm2009q3 cross compiler to do that, and > during compiling I get this messages: > WARNING: "__aeabi_i2f" > [/home/danilo/Desktop/Work/UartDriverSingle/uartDriverSingle0.4/duologUartDriver.ko] > undefined! > I suppose that there is a problem with linking but I'm not so sure. I tried > to google it out but with no success. Is there any way to fix this warnings? > Because of them I can't insert module into a linux platform that runs on ARM > architecture. Is there some option to put in my Makefile or something else > to do? > > Thanks in advance. If you really want help then you really need to be more clear in how you are asking questions. Beside the fact that you have a linking problem with, what I assume, an out-of-tree Linux kernel module (due to the .ko filename-extension) I really have no idea what you are doing, what your code looks like, or either what your makefile looks like. Therefor I am not able to help you. Maybe you should read: http://catb.org/~esr/faqs/smart-questions.html Kind regards, Remy From gds at chartertn.net Sat Jan 21 02:39:22 2012 From: gds at chartertn.net (Gene Smith) Date: Fri, 20 Jan 2012 21:39:22 -0500 Subject: [arm-gnu] Static template member in assigned section -- section type conflict Message-ID: <4F1A255A.40601@chartertn.net> Attached are two test cases that illustrate an error I am seeing with templates. When bad.cpp is compiled it shows this error: t.cpp:31:59: error: innerInst causes a section type conflict By editing bad.cpp this error can be removed with several changes: 1. Change the #if 1 to #if 0 so that the static template member "b" is not assigned to a special section but to a default section (probably .bss). 2. Or leave #if 1 in place and change the section name on the static "b" variable definition to something else, like ".myysect" (different than the section assigned to the static variable in main()). 3. Or don't access the "b" variable in main(). None of these are really acceptable but the bad.cpp then compiles without a fatal error. I have tried this with several CS-lite versions of arm-none-eabi-g++ with the same result. I haven't tried the latest version that was just recently released. I have also tried other gcc version such as cygwin and linux that are 4.5.x and see the same error. The file good.cpp illustrates the same thing (static member in its own section and non-static member in default section) only without using templates. It builds with no error with the various gnu tool chains including CS. I am not sure if the error is legitimate or actually a gcc bug. Bad.cpp is a simplification of a larger program that reportedly builds OK with another proprietary tool chain (ghs) but fails with CS-lite and other gcc versions with this "section type conflict" error. -gene -------------- next part -------------- A non-text attachment was scrubbed... Name: bad.cpp Type: text/x-c++src Size: 705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: good.cpp Type: text/x-c++src Size: 312 bytes Desc: not available URL: From gds at chartertn.net Sat Jan 21 19:58:42 2012 From: gds at chartertn.net (Gene Smith) Date: Sat, 21 Jan 2012 14:58:42 -0500 Subject: [arm-gnu] Static template member in assigned section -- section type conflict Message-ID: <4F1B18F2.2070707@chartertn.net> Attached are two test cases that illustrate an error I am seeing with templates. When bad.cpp is compiled it shows this error: t.cpp:31:59: error: innerInst causes a section type conflict By editing bad.cpp this error can be removed with several changes: 1. Change the #if 1 to #if 0 so that the static template member "b" is not assigned to a special section but to a default section (probably .bss). 2. Or leave #if 1 in place and change the section name on the static "b" variable definition to something else, like ".myysect" (different than the section assigned to the static variable in main()). 3. Or don't access the "b" variable in main(). None of these are really acceptable but the bad.cpp then compiles without a fatal error. I have tried this with several CS-lite versions (including the latest) of arm-none-eabi-g++ with the same result. I have also tried other gcc version such as cygwin and linux that are 4.5.x and see the same error. The file good.cpp illustrates the same concept (static member in its own section and non-static member in default section) but without using templates. It builds with no error with the various gnu tool chains including CS-lite. I am not sure if the error is legitimate or actually a gcc bug. Bad.cpp is a simplification of a larger program that reportedly builds OK with a proprietary tool chain (ghs) but fails with CS-lite and other gcc versions/variants with this "section type conflict" error. Thanks, -gene P/S: The arm-gnu at codesourcery.com list seems to be inactive and not accepting posts since about 1/6 so I am bcc'ing the moderators. This is a re-post that was sent yesterday that has yet to appear in the Jan 2012 archives. -------------- next part -------------- A non-text attachment was scrubbed... Name: bad.cpp Type: text/x-c++src Size: 706 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: good.cpp Type: text/x-c++src Size: 313 bytes Desc: not available URL: From gds at chartertn.net Mon Jan 23 01:36:01 2012 From: gds at chartertn.net (Gene Smith) Date: Sun, 22 Jan 2012 20:36:01 -0500 Subject: [arm-gnu] Static template member in assigned section -- section type conflict In-Reply-To: <4F1B18F2.2070707@chartertn.net> References: <4F1B18F2.2070707@chartertn.net> Message-ID: <4F1CB981.8060608@chartertn.net> On 01/21/2012 02:58 PM, Gene Smith wrote: > Attached are two test cases that illustrate an error I am seeing with > templates... This is the closest thing I can find to my test case: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091 However, the test cases there compile with no error for me. Here is a simpler variation on my test case that shows the same error: //@! test: g++ bad2.cpp // bad2.cpp:18:25: error: priv causes a section type conflict template class outer { public: t1 a; static t2 b; }; template t2 outer::b __attribute__((section(".s1"))); int main (void) { static outer priv __attribute__((section(".s1"))); priv.a = 10; priv.b = 10; } //@! end of file From carlos_odonell at mentor.com Thu Jan 26 17:01:33 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Thu, 26 Jan 2012 12:01:33 -0500 Subject: [arm-gnu] Static template member in assigned section -- section type conflict In-Reply-To: <4F1CB981.8060608@chartertn.net> References: <4F1B18F2.2070707@chartertn.net> <4F1CB981.8060608@chartertn.net> Message-ID: <4F2186ED.2080202@mentor.com> On 1/22/2012 8:36 PM, Gene Smith wrote: > //@! test: g++ bad2.cpp > // bad2.cpp:18:25: error: priv causes a section type conflict > > template > class outer > { > public: > t1 a; > static t2 b; > }; > > template > t2 outer::b > __attribute__((section(".s1"))); > > int main (void) > { > static outer priv __attribute__((section(".s1"))); You can't place common data and non-common data in the same section. The conflict is as follows: * The variable t2 in outer->t2 is static and therefore common data, there must only be one instance of t2 at all times. * Moving t2 into .s1 causes section .s1 to be marked as common data, this is a flag that the linker must honour and it will bind other references to t2 to the common location in .s1 (that's how static is implemented in this case). * In main you say you want to store the *entire* contents of the instantiated template into .s1, but .s1 is common data, and the object is not common data, and that is a conflict. > priv.a = 10; > priv.b = 10; > } > //@! end of file The solution is to place priv into some *other* section. You will never have *all* of priv in the same place because the `static' clause makes that impossible for > 1 instances of the object (given the current implementation for static). Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos at codesourcery.com +1 (613) 963 1026 From gds at chartertn.net Fri Jan 27 05:19:05 2012 From: gds at chartertn.net (Gene Smith) Date: Fri, 27 Jan 2012 00:19:05 -0500 Subject: [arm-gnu] Static template member in assigned section -- section type conflict In-Reply-To: <4F2186ED.2080202@mentor.com> References: <4F1B18F2.2070707@chartertn.net> <4F1CB981.8060608@chartertn.net> <4F2186ED.2080202@mentor.com> Message-ID: <4F2233C9.7010606@chartertn.net> On 01/26/2012 12:01 PM, Carlos O'Donell wrote: > On 1/22/2012 8:36 PM, Gene Smith wrote: >> //@! test: g++ bad2.cpp >> // bad2.cpp:18:25: error: priv causes a section type conflict >> >> template >> class outer >> { >> public: >> t1 a; >> static t2 b; >> }; >> >> template >> t2 outer::b >> __attribute__((section(".s1"))); >> >> int main (void) >> { >> static outer priv __attribute__((section(".s1"))); > > You can't place common data and non-common data in the same section. > > The conflict is as follows: > > * The variable t2 in outer->t2 is static and therefore common data, > there must only be one instance of t2 at all times. > > * Moving t2 into .s1 causes section .s1 to be marked as common data, > this is a flag that the linker must honour and it will bind other > references to t2 to the common location in .s1 (that's how static > is implemented in this case). > > * In main you say you want to store the *entire* contents of the > instantiated template into .s1, but .s1 is common data, and the > object is not common data, and that is a conflict. > >> priv.a = 10; >> priv.b = 10; >> } >> //@! end of file > > The solution is to place priv into some *other* section. > > You will never have *all* of priv in the same place because > the `static' clause makes that impossible for> 1 instances > of the object (given the current implementation for static). > > Cheers, > Carlos. Thanks for the detailed explanation. However, I am not sure I follow it all and will look up the concept of "common" you refer to. While waiting for a response I found a solution by breaking up the code into 3 separate files and I get the result I expect. // temp.h template class outer { public: t1 a; static t2 b; }; // temp.cpp #include "temp.h" template t2 outer::b __attribute__((section(".s1"))); // Explicit instantiation (NEW!) template class outer; //main.c #include "temp.h" int main (void) { static outer priv __attribute__((section(".s1"))); priv.a = 10; priv.b = 10; } arm-none-eabi-g++ -c temp.cpp arm-none-eabi-g++ -c main.cpp arm-none-eabi-g++ main.o temo.o Produces a.out with only a warning about lack of _start. An objdump shows all objects/variables in the expected section. Why does this work but having it all in a single file doesn't -gene From carlos_odonell at mentor.com Fri Jan 27 18:45:32 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Fri, 27 Jan 2012 13:45:32 -0500 Subject: [arm-gnu] Static template member in assigned section -- section type conflict In-Reply-To: <4F2233C9.7010606@chartertn.net> References: <4F1B18F2.2070707@chartertn.net> <4F1CB981.8060608@chartertn.net> <4F2186ED.2080202@mentor.com> <4F2233C9.7010606@chartertn.net> Message-ID: <4F22F0CC.6000108@mentor.com> On 1/27/2012 12:19 AM, Gene Smith wrote: >> You will never have *all* of priv in the same place because >> the `static' clause makes that impossible for> 1 instances >> of the object (given the current implementation for static). >> >> Cheers, >> Carlos. > > Thanks for the detailed explanation. However, I am not sure > I follow it all and will look up the concept of "common" > you refer to. While waiting for a response I found a solution > by breaking up the code into 3 separate files and I get the > result I expect. > > // temp.h > template > class outer > { > public: > t1 a; > static t2 b; > }; > > // temp.cpp > #include "temp.h" > > template > t2 outer::b > __attribute__((section(".s1"))); > > // Explicit instantiation (NEW!) > template class outer; > > //main.c > #include "temp.h" > int main (void) > { > static outer priv __attribute__((section(".s1"))); > > priv.a = 10; > priv.b = 10; > } > > arm-none-eabi-g++ -c temp.cpp > arm-none-eabi-g++ -c main.cpp > arm-none-eabi-g++ main.o temo.o > Produces a.out with only a warning about lack of _start. An objdump shows all objects/variables in the expected section. > > Why does this work but having it all in a single file doesn't It doesn't work. Use -save-temps and -Wl,-Map,linkermap.txt to see where everything goes (I suggest also printing &priv, &priv.a, and &priv.b). You will see that priv.a goes into .s1 because of the section attribute in main.cpp. However, because of the explicit instantiation priv.b goes into .bss, it's a specialization, and isn't shared amongst other uses of the template so it's not common data anymore (which is the normal way in which static data is handled). e.g. 6009d8 &priv 6009d8 &priv.a .s1 0x00000000006009d8 0x4 .s1 0x00000000006009d8 0x4 priv2.o 6009f0 &priv.b .bss 0x00000000006009e0 0x18 ... .bss 0x00000000006009f0 0x0 priv2-temp.o .bss._ZN5outerIiiE1bE 0x00000000006009f0 0x4 priv2-temp.o 0x00000000006009f0 _ZN5outerIiiE1bE You are perilously poking under the hood of a complex system :-) Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos at codesourcery.com +1 (613) 963 1026 From gds at chartertn.net Sat Jan 28 20:01:32 2012 From: gds at chartertn.net (Gene Smith) Date: Sat, 28 Jan 2012 15:01:32 -0500 Subject: [arm-gnu] Static template member in assigned section -- section type conflict In-Reply-To: <4F22F0CC.6000108@mentor.com> References: <4F1B18F2.2070707@chartertn.net> <4F1CB981.8060608@chartertn.net> <4F2186ED.2080202@mentor.com> <4F2233C9.7010606@chartertn.net> <4F22F0CC.6000108@mentor.com> Message-ID: <4F24541C.70101@chartertn.net> On 01/27/2012 01:45 PM, Carlos O'Donell wrote: > On 1/27/2012 12:19 AM, Gene Smith wrote: >>> You will never have *all* of priv in the same place because >>> the `static' clause makes that impossible for> 1 instances >>> of the object (given the current implementation for static). >>> >>> Cheers, >>> Carlos. >> >> Thanks for the detailed explanation. However, I am not sure >> I follow it all and will look up the concept of "common" >> you refer to. While waiting for a response I found a solution >> by breaking up the code into 3 separate files and I get the >> result I expect. >> >> // temp.h >> template >> class outer >> { >> public: >> t1 a; >> static t2 b; >> }; >> >> // temp.cpp >> #include "temp.h" >> >> template >> t2 outer::b >> __attribute__((section(".s1"))); >> >> // Explicit instantiation (NEW!) >> template class outer; >> >> //main.c >> #include "temp.h" >> int main (void) >> { >> static outer priv __attribute__((section(".s1"))); >> >> priv.a = 10; >> priv.b = 10; >> } >> >> arm-none-eabi-g++ -c temp.cpp >> arm-none-eabi-g++ -c main.cpp >> arm-none-eabi-g++ main.o temo.o >> Produces a.out with only a warning about lack of _start. An objdump shows all >> objects/variables in the expected section. >> >> Why does this work but having it all in a single file doesn't > > It doesn't work. > > Use -save-temps and -Wl,-Map,linkermap.txt to see where everything goes (I > suggest also printing &priv, &priv.a and &priv.b). > > You will see that priv.a goes into .s1 because of the section attribute in main.cpp. > > However, because of the explicit instantiation priv.b goes into .bss, it's a > specialization, and isn't shared amongst other uses of the template so it's not common > data anymore (which is the normal way in which static data is handled). > > e.g. > > 6009d8 &priv > 6009d8 &priv.a > > .s1 0x00000000006009d8 0x4 > .s1 0x00000000006009d8 0x4 priv2.o > > 6009f0 &priv.b > > .bss 0x00000000006009e0 0x18 > ... > .bss 0x00000000006009f0 0x0 priv2-temp.o > .bss._ZN5outerIiiE1bE > 0x00000000006009f0 0x4 priv2-temp.o > 0x00000000006009f0 _ZN5outerIiiE1bE > > You are perilously poking under the hood of a complex system :-) > > Cheers, > Carlos. Don't know why but it works for me with all g++. In the previous example, I see priv.a, priv.b and priv *all* in section .s1 (translated mangled names with c++-filt in parens): $ ./a.out 0x600c20 &priv 0x600c20 &priv.a 0x600c1c &priv.b .s1 0x0000000000600c1c 0x8 .s1 0x0000000000600c1c 0x4 temp.o 0x0000000000600c1c _ZN5outerIiiE1bE (outer::b) .s1 0x0000000000600c20 0x4 main.o Double check location with objdump: 24 .s1 00000008 0000000000600c1c 0000000000600c1c 00000c1c 2**2 CONTENTS, ALLOC, LOAD, DATA 25 .bss 00000128 0000000000600c40 0000000000600c40 00000c24 2**5 ALLOC None of the "priv" elements appear in .bss! Here's a more general example that works for me with arm-none-eabi-g++ (from CS) and generic g++ on linux. This is somewhat closer to my actually application where some elements in template class are static and assigned to the containing object's section (.b), others are static and not assigned a section (.c[]) and some are nether static nor assigned an explicit section (.a): // temp.h template class outer { public: int c[3]; // goes to .mysec -- where containing object is assigned static t2 b; // goes to .mysec -- explicitly assigned independently static t1 a; // goes to .bss -- always to default section: unassigned static }; // temp.cpp #include "temp.h" template t2 outer::b __attribute__((section(".mysect"))); template t1 outer::a; template class outer; // main.cpp #include "temp.h" int main (void) { static outer priv __attribute__((section(".mysect"))); // li:31 priv.a = 10; priv.b = 10; priv.c[0] = 144; priv.c[1] = 145; priv.c[2] = 146; cout << &priv << " &priv\n"; cout << &priv.a << " &priv.a\n"; cout << &priv.b << " &priv.b\n"; cout << &priv.c[0] << " &priv.c[0]\n"; } I build with linux g++ like this (as you suggested): g++ -save-temps -c -g main.cpp g++ -save-temps -c -g temp.cpp g++ -save-temps -g -Wl,-Map,linkermap.txt temp.o main.o .mysect 0x0000000000600c6c 0x10 .mysect 0x0000000000600c6c 0x4 temp.o 0x0000000000600c6c _ZN5outerIiiE1bE (outer::b) .mysect 0x0000000000600c70 0xc main.o .bss 0x0000000000600da0 0x0 temp.o .bss._ZN5outerIiiE1aE (outer::a) 0x0000000000600da0 0x4 temp.o 0x0000000000600da0 _ZN5outerIiiE1aE Program output: $ ./a.out 0x600c70 &priv <---in .mysect 0x600da0 &priv.a <---in .bss 0x600c6c &priv.b <---in .mysect 0x600c70 &priv.c[0] <---in .mysect Exactly what I want! -gene From carlos_odonell at mentor.com Mon Jan 30 14:54:13 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Mon, 30 Jan 2012 09:54:13 -0500 Subject: [arm-gnu] Static template member in assigned section -- section type conflict In-Reply-To: <4F24541C.70101@chartertn.net> References: <4F1B18F2.2070707@chartertn.net> <4F1CB981.8060608@chartertn.net> <4F2186ED.2080202@mentor.com> <4F2233C9.7010606@chartertn.net> <4F22F0CC.6000108@mentor.com> <4F24541C.70101@chartertn.net> Message-ID: <4F26AF15.1030806@mentor.com> On 1/28/2012 3:01 PM, Gene Smith wrote: > Program output: > $ ./a.out > 0x600c70 &priv <---in .mysect > 0x600da0 &priv.a <---in .bss > 0x600c6c &priv.b <---in .mysect > 0x600c70 &priv.c[0] <---in .mysect > > Exactly what I want! Does `static' still work correctly? Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos at codesourcery.com +1 (613) 963 1026 From gds at chartertn.net Tue Jan 31 02:35:50 2012 From: gds at chartertn.net (Gene Smith) Date: Mon, 30 Jan 2012 21:35:50 -0500 Subject: [arm-gnu] Static template member in assigned section -- section type conflict In-Reply-To: <4F26AF15.1030806@mentor.com> References: <4F1B18F2.2070707@chartertn.net> <4F1CB981.8060608@chartertn.net> <4F2186ED.2080202@mentor.com> <4F2233C9.7010606@chartertn.net> <4F22F0CC.6000108@mentor.com> <4F24541C.70101@chartertn.net> <4F26AF15.1030806@mentor.com> Message-ID: <4F275386.7040103@chartertn.net> On 01/30/2012 09:54 AM, Carlos O'Donell wrote: > On 1/28/2012 3:01 PM, Gene Smith wrote: >> Program output: >> $ ./a.out >> 0x600c70&priv<---in .mysect >> 0x600da0&priv.a<---in .bss >> 0x600c6c&priv.b<---in .mysect >> 0x600c70&priv.c[0]<---in .mysect >> >> Exactly what I want! > > Does `static' still work correctly? > > Cheers, > Carlos. Seems to. I defined a non-static variable "local" like this: // main.cpp #include using namespace std; #include "temp.h" int main (void) { static outer priv __attribute__((section(".mysect"))); // li:31 priv.a = 10; priv.b = 10; priv.c[0] = 144; priv.c[1] = 145; priv.c[2] = 146; cout << &priv << " &priv\n"; cout << &priv.a << " &priv.a\n"; cout << &priv.b << " &priv.b\n"; cout << &priv.c[0] << " &priv.c[0]\n"; outer local; local.a = 10; local.b = 10; local.c[0] = 144; local.c[1] = 145; local.c[2] = 146; cout << &local << " &local\n"; cout << &local.a << " &local.a\n"; cout << &local.b << " &local.b\n"; cout << &local.c[0] << " &local.c[0]\n"; } Statics print the same address but containing object and non-static element c[] differs: $ ./a.out 0x600d40 &priv 0x600e80 &priv.a <-- static 0x600d3c &priv.b <---static 0x600d40 &priv.c[0] 0x7fff96482990 &local 0x600e80 &local.a <---static (still .bss) 0x600d3c &local.b <---static (still .mysect) 0x7fff96482990 &local.c[0] From carlos_odonell at mentor.com Tue Jan 31 15:03:10 2012 From: carlos_odonell at mentor.com (Carlos O'Donell) Date: Tue, 31 Jan 2012 10:03:10 -0500 Subject: [arm-gnu] Static template member in assigned section -- section type conflict In-Reply-To: <4F275386.7040103@chartertn.net> References: <4F1B18F2.2070707@chartertn.net> <4F1CB981.8060608@chartertn.net> <4F2186ED.2080202@mentor.com> <4F2233C9.7010606@chartertn.net> <4F22F0CC.6000108@mentor.com> <4F24541C.70101@chartertn.net> <4F26AF15.1030806@mentor.com> <4F275386.7040103@chartertn.net> Message-ID: <4F2802AE.6040600@mentor.com> On 1/30/2012 9:35 PM, Gene Smith wrote: > Statics print the same address but containing object and non-static element > c[] differs: > > $ ./a.out > 0x600d40 &priv > 0x600e80 &priv.a <-- static > 0x600d3c &priv.b <---static > 0x600d40 &priv.c[0] > 0x7fff96482990 &local > 0x600e80 &local.a <---static (still .bss) > 0x600d3c &local.b <---static (still .mysect) > 0x7fff96482990 &local.c[0] > That looks good to me. You may want to add this as a regression test to your application to ensure that the tools keep working the same way. You are relying on some implementation defined behaviour here so it might change in the future. Cheers, Carlos. -- Carlos O'Donell Mentor Graphics / CodeSourcery carlos at codesourcery.com +1 (613) 963 1026