Hi, I’ve been working with the last gccvb version from David Tucker’s site, and everything have been great until now that my code has grown so much making the linker to throw this:

make -k clean all
/usr/local/v810/bin/ld: section .vbvectors [0701fde0 -> 0701ffff] overlaps section .data [0701ddd0 -> 0701fdf7]
collect2: ld returned 1 exit status
make: *** [vbJaEngineDemo.elf] Error 1
make: Target `all’ not remade because of errors.

I guess the problem has something to do with the total memory for data allocation, but here are some facts:

· David Tucker told me that everything declared as const will be created in the rom memory region (at least thats what I remember, I’ve lost the mail).

· Every char, bgmap and object definition is declared as const (but it doesn’t seem to do any difference with the new compiler and linker).

· With the previous gccvb’s version all my binaries had 1024Kb… with the last one they are fixed at 128Kb.

Any idea?

Thanks a lot.

Jorgeche

I’ve missed something else:

I thought the rom memory space was 16MB (Virtual Boy Programmers Manual page 9) and all my binary has 128Kb… where is the problem? Why rom data is overlapping with data memory.

By the way, the const directive seems to work fine:

0701701c g O .rodata 00002001 _MOUNTCHAR

if the rodata means rom memory’s data.

Hmm… I haven’t used DT’s gccVB build, but it definately looks like you’ve got a problem being stuck at 128KB. I don’t remember having to do anything special using the old build to make it larger… IIRC it would just expand itself, then you just had to make sure the padder was set to pad to the correct size.

I’d send DT an email and see if he can help you out. Otherwise you could try the old version and see if it makes any difference.

DogP

Did you ever solve this? It sounds like you are overflowing the stack or ram. Maby you are passing a large struct to a function, or you are declaring ararys within functions without declaring them static (this includes images imported from external files).

My version of vbgcc came around from the need to compile a very large project (2MBit). It workes very well I might add (but the gcc optimization is not quite 100% yet). So any troubles you are having with the memory is a side effect of your own code.

Sorry I have not been around much but life got realy buisy once I moved.

David Tucker

I’m getting the same error. My rom is only 8 K, all my arrays are const. How did you fix this?

Hi dasi, well I really don’t remember how I did get rid of the error, it haven’t happened me since then (2 years ago), but I would suggest you to remove the parts of the code you think could be causing the problem until you find it, then you could post that code and maybe I could be of more help.

But as David said it could be a very large function call or/and a very big amount of auto variables (local variables -> stack memory).

jorgeche

I get this every now and then… I believe it’s a bug in the new gccvb that doesn’t move the vectors after the code grows into the vector area until the code actually grows beyond the vector area (ie. code normally will fill up to 1d280, vectors go at 1fde0 to 1ffff, but if code is from 1fde0 to 1ffff, it still tries to place the vectors there, untill code gets to 20000). Whenever it happens to me, I just do a bunch of identical function calls in a row at the startup, until I get enough new code that I can get rid of them.

DogP

> I get this every now and then…

That must be it. Thanks guys!

I just experienced this the other day, and it went away just as quickly. Now I know what caused it. Thanks for reviving this thread, dasi. 😉

[dasi]

In vb.ld:

v = .;

/* Ram memory */

__data_lma = .;
.data __data_vma : AT(__data_lma) {
*(.data)
*(.data.*)
*(.gnu.linkonce.d*)
/* CONSTRUCTORS */
} >ram = 0xFF
__data_end = .;

/* prevent overlaps with vbvectors */
v += SIZEOF(.data);

I think this should fix the problem. However, copying vb.ld to /usr/local/v810/lib/ like it says in build.txt doesn’t override the default script.

• This reply was modified 16 years ago by dasi.

dasi wrote:

I think this should fix the problem. However, copying vb.ld to /usr/local/v810/lib/ like it says in build.txt doesn’t override the default script.

All you have to do (if you don’t want to/can’t recompile the compiler) is add something like:

[font=Courier]-T/usr/local/v810/vb.ld[/font]

to the compiler command line.

I implemented this and it didn’t break my build process, but I don’t have any code that exhibits the problem, so I can’t say if it works. If it does, good job! 😀

In fact, you deserve kudos for even looking into the problem 😉

(BTW, I attached the edited file).

Another thing that would be nice is if gcc padded the ROM to the next size w/ 0xFF rather than 0x00 (for faster chip burning, and also so I can quickly tell how big my program by watching the progress bar in the burning software). I guess since I pad the ROM every time anyway, I could just get rid of the auto padding in the linker and I’d avoid the vbvectors problem as well as padding the ROM with 0xFFs.

DogP

dasi wrote:
In vb.ld:

v = .;

/* Ram memory */

__data_lma = .;
.data __data_vma : AT(__data_lma) {
*(.data)
*(.data.*)
*(.gnu.linkonce.d*)
/* CONSTRUCTORS */
} >ram = 0xFF
__data_end = .;

/* prevent overlaps with vbvectors */
v += SIZEOF(.data);

I think this should fix the problem. However, copying vb.ld to /usr/local/v810/lib/ like it says in build.txt doesn’t override the default script.

Just wanted to let you know I ran across this problem again today and this change does seem to fix the problem (it fails w/o and works w/… as long as it doesn’t just make it break somewhere else 😛 ). Like you said, copying the vb.ld to /usr/local/v810/lib/ doesn’t make the change, but adding that into v810.sc and recompiling fixed it (or you can manually specify the vb.ld in your build script as RunnerPack said).

DogP