Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

I'm encountering what appears to be common linker error messages:

Error: L6265E: Non-RWPI Section libspace.o(.bss) cannot be assigned to PI Exec region ER_ZI.
Error: L6248E: libspace.o(.text) in PI region 'ER_RO' cannot have address type relocation to __libspace_start in PI region 'ER_ZI'.

I've checked to make sure I'm not using static global data.

I've added some linker options to print out some info. I

Quote:Originally posted by Benjamin
I'm encountering what appears to be common linker error messages:
Error: L6265E: Non-RWPI Section libspace.o(.bss) cannot be assigned to PI Exec region ER_ZI.
Error: L6248E: libspace.o(.text) in PI region 'ER_RO' cannot have address type relocation to __libspace_start in PI region 'ER_ZI'.
I've checked to make sure I'm not using static global data.
I've added some linker options to print out some info. I
Woops, submitted reply before I was done...
I've added some linker options to print out some info. I'm puzzled. Based on the linker errors, I checked the ER_ZI region. I've got this:
Execution Region ER_ZI (Base: 0x00000000, Size: 0x00000060, Max: 0xffffffff, PI)
Base Addr Size Type Attr Idx E Section Name Object
0x00000000 0x00000060 Zero RW 250 .bss libspace.o(c_t__un.l)
Then I checked the image component sizes, and get this:
Code RO Data RW Data ZI Data Debug Library Name
2336 299 0 96 2140 c_t__un.l
According to the linker output, it looks like a standard c library, c_t__un.l is the only object using the ER_ZI region...none of my modules are using any ZI Data.
Has anyone encountered this ?
Regards,
Ben

Quote:Originally posted by Benjamin
I'm encountering what appears to be common linker error messages:
Error: L6265E: Non-RWPI Section libspace.o(.bss) cannot be assigned to PI Exec region ER_ZI.
Error: L6248E: libspace.o(.text) in PI region 'ER_RO' cannot have address type relocation to __libspace_start in PI region 'ER_ZI'.
I've checked to make sure I'm not using static global data.
I've added some linker options to print out some info. I
Woops, submitted reply before I was done...
I've added some linker options to print out some info. I'm puzzled. Based on the linker errors, I checked the ER_ZI region. I've got this:
Execution Region ER_ZI (Base: 0x00000000, Size: 0x00000060, Max: 0xffffffff, PI)
Base Addr Size Type Attr Idx E Section Name Object
0x00000000 0x00000060 Zero RW 250 .bss libspace.o(c_t__un.l)
Then I checked the image component sizes, and get this:
Code RO Data RW Data ZI Data Debug Library Name
2336 299 0 96 2140 c_t__un.l
According to the linker output, it looks like a standard c library, c_t__un.l is the only object using the ER_ZI region...none of my modules are using any ZI Data.
Has anyone encountered this ?
Regards,
Ben

I found the problem. I had some hidden references to malloc and free...doh!

I found the problem. I had some hidden references to malloc and free...doh!

Benjamin wrote:Woops, submitted reply before I was done...
I've added some linker options to print out some info. I'm puzzled. Based on the linker errors, I checked the ER_ZI region. I've got this:
Execution Region ER_ZI (Base: 0x00000000, Size: 0x00000060, Max: 0xffffffff, PI)
Base Addr Size Type Attr Idx E Section Name Object
0x00000000 0x00000060 Zero RW 250 .bss libspace.o(c_t__un.l)
Then I checked the image component sizes, and get this:
Code RO Data RW Data ZI Data Debug Library Name
2336 299 0 96 2140 c_t__un.l
According to the linker output, it looks like a standard c library, c_t__un.l is the only object using the ER_ZI region...none of my modules are using any ZI Data.
Has anyone encountered this ?
Regards,
Ben
I encounter the same question, after having got the map and info, I get this:
Execution Region ER_ZI (Base: 0x00000000, Size: 0x00000060, Max: 0xffffffff, PI)
Base Addr Size Type Attr Idx E Section Name Object
0x00000000 0x00000060 Zero RW 670 .bss libspace.o(c_t__un.l)
I surprised that almost everything is same as Ben's. Because Ben solve the problem through the way of memory allocate and free, I make efforts on this. Unfortunately I can't step any further. So I comment every function, link once and again. Finally I'd found that a explicit conversion from double to integer generate the ER_ZI data. Get rid of it! Cheer!

Benjamin wrote:Woops, submitted reply before I was done...
I've added some linker options to print out some info. I'm puzzled. Based on the linker errors, I checked the ER_ZI region. I've got this:
Execution Region ER_ZI (Base: 0x00000000, Size: 0x00000060, Max: 0xffffffff, PI)
Base Addr Size Type Attr Idx E Section Name Object
0x00000000 0x00000060 Zero RW 250 .bss libspace.o(c_t__un.l)
Then I checked the image component sizes, and get this:
Code RO Data RW Data ZI Data Debug Library Name
2336 299 0 96 2140 c_t__un.l
According to the linker output, it looks like a standard c library, c_t__un.l is the only object using the ER_ZI region...none of my modules are using any ZI Data.
Has anyone encountered this ?
Regards,
Ben
I encounter the same question, after having got the map and info, I get this:
Execution Region ER_ZI (Base: 0x00000000, Size: 0x00000060, Max: 0xffffffff, PI)
Base Addr Size Type Attr Idx E Section Name Object
0x00000000 0x00000060 Zero RW 670 .bss libspace.o(c_t__un.l)
I surprised that almost everything is same as Ben's. Because Ben solve the problem through the way of memory allocate and free, I make efforts on this. Unfortunately I can't step any further. So I comment every function, link once and again. Finally I'd found that a explicit conversion from double to integer generate the ER_ZI data. Get rid of it! Cheer!

I know this is an old toppic, but I'm having the same errors you guys mentioned:
Error: L6265E: Non-RWPI Section libspace.o(.bss) cannot be assigned to PI Exec region ER_ZI.
Error: L6248E: libspace.o(.text) in PI region 'ER_RO' cannot have address type relocation to __libspace_start in PI region 'ER_ZI'.
I don't know what Benjamin tried to mean with: "had some hidden references to malloc and free." Could someone explain it better ?
Next time give us an more details about how to fix it, like an example of error and solution :)
Thank you.

I know this is an old toppic, but I'm having the same errors you guys mentioned:
Error: L6265E: Non-RWPI Section libspace.o(.bss) cannot be assigned to PI Exec region ER_ZI.
Error: L6248E: libspace.o(.text) in PI region 'ER_RO' cannot have address type relocation to __libspace_start in PI region 'ER_ZI'.
I don't know what Benjamin tried to mean with: "had some hidden references to malloc and free." Could someone explain it better ?
Next time give us an more details about how to fix it, like an example of error and solution :)
Thank you.

you're using standard library C calls that require loadtime address relocation fixups.
find the use of malloc/new/delete/free or one of the other things that are pulling in that library, as for examples, this topic has been done to death on the forums, almost every new to brew developer posts about it.

you're using standard library C calls that require loadtime address relocation fixups.
find the use of malloc/new/delete/free or one of the other things that are pulling in that library, as for examples, this topic has been done to death on the forums, almost every new to brew developer posts about it.

charliex wrote:you're using standard library C calls that require loadtime address relocation fixups.
find the use of malloc/new/delete/free or one of the other things that are pulling in that library, as for examples, this topic has been done to death on the forums, almost every new to brew developer posts about it.
I'm using this functions to replace new and delete operators, are these functions the ones which are generating the problems you said ?
#include "memory.h"
inline static void* new_object( size_t size )
{
return( MALLOC( size ) ) ;

inline static void delete_object( void* memory )
{
FREE( memory ) ;

void* operator new( size_t size )
{
return( new_object( size ) ) ;

void* operator new[]( size_t size )
{
return( new_object( size ) ) ;

void operator delete( void* memory )
{
delete_object( memory ) ;

void operator delete[]( void* memory )
{
delete_object( memory ) ;

extern "C" void __cxa_pure_virtual( )
{

Thanks.

charliex wrote:you're using standard library C calls that require loadtime address relocation fixups.
find the use of malloc/new/delete/free or one of the other things that are pulling in that library, as for examples, this topic has been done to death on the forums, almost every new to brew developer posts about it.
I'm using this functions to replace new and delete operators, are these functions the ones which are generating the problems you said ?
#include "memory.h"
inline static void* new_object( size_t size )
{
return( MALLOC( size ) ) ;

inline static void delete_object( void* memory )
{
FREE( memory ) ;

void* operator new( size_t size )
{
return( new_object( size ) ) ;

void* operator new[]( size_t size )
{
return( new_object( size ) ) ;

void operator delete( void* memory )
{
delete_object( memory ) ;

void operator delete[]( void* memory )
{
delete_object( memory ) ;

extern "C" void __cxa_pure_virtual( )
{

Thanks.

I presume thats in a header ?
check the map file for what its using libspace for .

I presume thats in a header ?
check the map file for what its using libspace for .

This is a cpp file which is used by the game.
What do you mean "map file" ?
Thanks

This is a cpp file which is used by the game.
What do you mean "map file" ?
Thanks

the file that is generated when you use -map option at the time of linking.

the file that is generated when you use -map option at the time of linking.

if its a cpp file most likely its not being used correctly, for instance its inline static, which is pretty much useless in a project with multiple .cpp files, so its probably including the generic libspace new/deletes in any another cpp files you're using, unless you're sure all the new/deletes you're using are all declared after and in the same .cpp file.
put them in a header thats included in all the cpp files, if you still get issues check the map file, use -list $(TARGET).map -map on the ld line in the makefile.

if its a cpp file most likely its not being used correctly, for instance its inline static, which is pretty much useless in a project with multiple .cpp files, so its probably including the generic libspace new/deletes in any another cpp files you're using, unless you're sure all the new/deletes you're using are all declared after and in the same .cpp file.
put them in a header thats included in all the cpp files, if you still get issues check the map file, use -list $(TARGET).map -map on the ld line in the makefile.

Just to recap, after I was bitten for the umpteenth time by this...
Any of the following will cause a libspace.o error:
a) Use of floating point.
b) Use of standard library functions like memcmp or isupper. Use the appropriate BREW equivalents, or define your own methods
c) Use of new/delete. Again, define your own.

Just to recap, after I was bitten for the umpteenth time by this...
Any of the following will cause a libspace.o error:
a) Use of floating point.
b) Use of standard library functions like memcmp or isupper. Use the appropriate BREW equivalents, or define your own methods
c) Use of new/delete. Again, define your own.

a) is not entirely true, you can use floating point without libspace.o problems.
http://brewforums.qualcomm.com/showthread.php?t=6657
there are other ways of using floating point too, its somewhat dependant on the version of ads too.

a) is not entirely true, you can use floating point without libspace.o problems.
http://brewforums.qualcomm.com/showthread.php?t=6657
there are other ways of using floating point too, its somewhat dependant on the version of ads too.