A while ago I used the existing gccvb patches to write new ones for gcc4. It’s quite possible that they contain bugs.
So far I haven’t tested code compiled with this version on a real VB, but it runs well in Reality Boy.
I’ve noticed another caveat with this version: it’s much more strict about the syntax of in-line assembly blocks. Namely, the endings have to be right. Something like this:
The thing to notice is the “;” or “\n\t” at the end of every statement line (which are interchangeable, I just used those for aesthetics). Just something to keep in mind when porting older code or writing new.
I am attempting to patch and compile gcc for the first time, and I am running into some trouble.
I am using Ubuntu 10.04 32-bit and gcc 4.4.3. I have downloaded binutils-2.20.tar.bz2, gcc-core-4.4.2.tar.bz2, and newlib-1.17.0.tar.gz from their respective locations and applied the patches posted by M.K.
I followed the general outline of the “make_v810.sh” script in [http://goliathindustries.com/vb/download/gccvb/vb_v810_gcc_03.tar.gz], which was originally intended for gcc 2.95. Essentially, I untarred the three archives, applied the three patches, built and installed binutils successfully, then continued on to configure and compile gcc.
The issue is that, during the gcc build, I eventually hit an error. Here’s how I configured and compiled it:
> mkdir gcc_build
> cd gcc_build
> ../gcc-4.4.2/configure –target=v810 –prefix=/opt/gccvb/bin –enable-languages=c –without-headers –with-newlib
> make all install
And after several minutes of compiling, I hit this:
————————-
(A bit too long, so I uploaded it. Note that this output was produced without the –without-headers flag, but it’s pretty much identical) http://www.codeupload.com/526
————————-
I find it peculiar that the preprocessor cannot find “string.h” and the others, as they are definitely on my system. Note the line: “checking for string.h… (cached) no” This seems to be a configure step performed specifically for zlib.
How to I ensure compiler finds all the necessary headers? Am I missing a step or compiling incorrectly?
Just to follow up on my compilation problem: I successfully built GCC 4.4.2, used it to compile the VB demo from the dev wiki, and ran it on Mednafen.
Here’s some of the commands I used:
1. mkdir binutils_build
2. cd binutils_build
3. ../binutils-2.20/configure –target=v810 –prefix=/opt/gccvb
4. make all install
5. PATH=$PATH:/opt/gccvb
6. mkdir ../gcc_build
7. cd ../gcc_build
8. ../gcc-4.4.2/configure –target=v810 –prefix=/opt/gccvb –enable-languages=c –without-headers –with-newlib –disable-shared –disable-threads
9. make all-gcc install-gcc
10. mkdir ../newlib_build
11. cd ../newlib_build
12. PATH=$PATH:/opt/gccvb/bin
13. sudo ln -s /opt/gccvb/bin/v810-gcc /opt/gccvb/bin/v810-cc # Because newlib wanted to use v810-cc but couldn’t find it.
14. ../newlib-1.17.0/configure –target=v810 –prefix=/opt/gccvb
15. make all install
16. cd ../gcc_build/
17. ../gcc-4.4.2/configure –target=v810 –prefix=/opt/gccvb –enable-languages=c
18. make all install
It was really ticking me off that I couldn’t get the old gccvb to compile under linux, so I tried these new patches. Once I got all the minor glitches worked out, compilation seemed to go without a hitch… until I tried to use v810-gcc to compile something. I tried what Tarsius did to compile one of my demos, binutils seems to work as the header assembled properly, but then when I tried to compile, I got this:
[fwirt@sploopby demo1]$ v810-gcc -nodefaultlibs -mv810 -x c -o demo1.o demo1.c
/usr/local/bin/../lib/gcc/v810/4.4.2/../../../../v810/lib/crt0.o: In function `_int_table':
(.vbvectors+0x28): undefined reference to `_key_vector'
…there are 9 more of those errors, pertaining to undefined references to _tim_vector, _cro_vector, _com_vector, and _vpu_vector. I also tried compiling the simplest program I could think of:
int main()
{
return 0;
}
…and got exactly the same result. Is this the result of me compiling gcc incorrectly? To be honest, I’ve never compiled gcc before, so I have no clue what I’m supposed to be doing. Any suggestions would be great, I haven’t had the drive to write any VB code the last few days because booting into Windows just so I can use an outdated version of gccvb is kind of a pain…
Depending how you’re set up you may need to declare your interrupt functions, like:
void key_vector(void){}
void tim_vector(void){}
void cro_vector(void){}
void com_vector(void){}
void vpu_vector(void){}
If that doesn’t work, try:
extern u32 key_vector;
extern u32 tim_vector;
extern u32 cro_vector;
extern u32 com_vector;
extern u32 vpu_vector;
The first one actually declares the functions, the second one assumes that they exist, but are external to the code (some gccVB configurations use one, others use the other). From the error, I’d guess you need the first.
I can’t thank you enough… that did the trick. I recompiled everything 2 or 3 times today because I thought I had neglected to compile in support for a library or something… Any reason why that’s necessary now when it didn’t used to be? (And is there any way to disable interrupts so I don’t need to do that every time? I guess I could just shove those lines into a header somewhere…) Well, at any rate, I had no idea how to put code at the interrupt vectors before, so this should do the trick. 😀 I’ve done some development on AVRs, but my knowledge is still pretty spotty when developing for a console like this. I hope that some day I have some idea of what I’m doing like you guys do…
I’d just always include them… they’re pointed to by the crt0, so you could take them out of that… but the easiest thing is just to always make the functions (and use them if you like).
Following those steps, I hit a roadblock at step 15, where I am building newlib. Here is the relevant output when make fails:
v810-cc -B/home/tarsius4/gccvb/newlib_build/v810/newlib/ -isystem /home/tarsius4/gccvb/newlib_build/v810/newlib/targ-include -isystem /home/tarsius4/gccvb/newlib-1.17.0/newlib/libc/include -DPACKAGE_NAME=\”newlib\” -DPACKAGE_TARNAME=\”newlib\” -DPACKAGE_VERSION=\”1.17.0\” -DPACKAGE_STRING=\”newlib\ 1.17.0\” -DPACKAGE_BUGREPORT=\”\” -I. -I../../../../../newlib-1.17.0/newlib/libc/stdlib -O2 -DPREFER_SIZE_OVER_SPEED -mv810 -DMISSING_SYSCALL_NAMES -fno-builtin -g -O2 -c -o lib_a-strtoll_r.o `test -f ‘strtoll_r.c’ || echo ‘../../../../../newlib-1.17.0/newlib/libc/stdlib/’`strtoll_r.c
/tmp/ccNqOS8G.s: Assembler messages:
/tmp/ccNqOS8G.s:176: Error: mov 9223372036854775807,r24: immediate operand is too large
/tmp/ccNqOS8G.s:337: Error: mov -9223372036854775808,r24: immediate operand is too large
/tmp/ccNqOS8G.s:393: Error: mov 9223372036854775807,r10: immediate operand is too large
/tmp/ccNqOS8G.s:459: Error: mov -9223372036854775808,r10: immediate operand is too large
make[5]: *** [lib_a-strtoll_r.o] Error 1
I couldn’t find anything like this online. I also tried compiling the entire toolchain _without_ the patches (using v850 as the target) and everything compiled successfully on my 64-bit machine. Therefore I suspect that either (A) there is something subtly wrong with how I am building gccvb and I would appreciate a makefile or some directions for building correctly, or (B) this is a flaw in the patches.
Also, I looked through the patches and notice that they specifically add “v810” as a target for gcc. Would it then be possible to submit these patches for inclusion in the GCC, binutils, and newlib projects? If accepted, wouldn’t this alleviate the problem of gccvb aging as the other GCC et. al are updated?
That’s weird… Again, I’m still a newb, but it looks like the assembly generated when compiling is seriously bugged. That number is even bigger than a long 😯 . I just took a quick look at strtoll_r.c, and the comment at the top says:
It is used to convert a string into a signed long long.
long long _strtoll_r (struct _reent *rptr, const char *s,
char **ptr, int base);
My guess is, since you’re compiling on 64-bit machine, the definition of a 64-bit long long is too big for v810-gcc. I think that on 64-bit systems, there’s usually some kind of 32-bit compatibility mode… I just googled it and I think that ubuntu has some 32-bit compatibility libraries. Maybe you could try that? (Or you could figure out some way to rewrite strtoll_r.c. 😛 )
Sorry for double posting… I thought something looked wrong about the VB ROM compilation process Tarsius in his previous post, so I checked it against the old make batch file… You did follow the compilation process there, but then you forgot to put the header into the rom and pad it. Padding isn’t an issue, RunnerPack’s padromvb.c compiles and works just fine in linux, but as far as combining the header and the rom, running
as mednafen won’t work on the resulting file (and my system doesn’t even reconize it as a binary.) Is having a ROM without a header a huge issue? (It doesn’t seem to be for mednafen, but will this do anything funky on hardware?)
hmmm… I’m relatively new to compiling gcc as well, but I’m under the impression that gccvb is a cross-compiler for the V810 processor. So I believe compiling gccvb on a 64-bit processor would have the effect of making gccvb’s machine code 64-bit compatible whereas gccvb will then compile code for Virtual Boy’s 32-bit registers.
It is an interesting observation, though, that my 64-bit GCC might be somehow spilling 64 bit code into the cross-compiler. GCCVB could then generate 64-bit literal values in the assembly output as it compiles newlib, which is rejected by the assembler. Note that I successfully compiled the toolchain for the “V850” target–no errors compiling newlib. This could be an indication of a bug in the patches.
Fwirt wrote:
Sorry for double posting… I thought something looked wrong about the compilation process Tarsius used,
It’s very likely that I did not compile the demo properly. I essentially did my best to mimic the steps employed by the Windows batch file included with the demo. The demo did run in mednafen after I followed those steps. I posted my procedure mainly to get feedback, since I’m not sure it’s correct. I see now that I generated “demo.hdr” but my steps do not appear to incorporate it into “demo.vb”
Fwirt wrote:
Is having a ROM without a header a huge issue?
Considering the code that tells the VB where to start executing is located there, I’d say it’s pretty important 😉
The reason for tarsius4’s ROM working and Fwirt’s “cat demo.vb demo.hdr > final.vb” one not working could be that the header code has been incorporated into the crt0. The external “vbh/hdr” files are no longer required. However, this does mean that default values are used for the ROM name, manufacturer ID, etc. and will have to be changed afterward if desired (or changed once in the crt0, if you just want a generic one). lameboyadvance made a handy viewer/editor for VB header info. It’s Win32 only, but should work in Wine, or you could just use a hex editor.
Good job to both of you for detailing your process and results in building the new compiler. @tarsius4: I hope you can get it built on your 64-bit machine (even though I don’t own such a beast ;-)). I also hope someone is still working on the wonky function call generation problem (since I wouldn’t know where to even start looking for it, even if I had the time to do so :-P).
tarsius4 wrote:
Also, I looked through the patches and notice that they specifically add “v810” as a target for gcc. Would it then be possible to submit these patches for inclusion in the GCC, binutils, and newlib projects? If accepted, wouldn’t this alleviate the problem of gccvb aging as the other GCC et. al are updated?
That would be great, but whoever took v810 support out in the first place might do so again, anyway. But maybe patches produced for gcc4 can continue to be applied to the v810 patched version and we can keep it updated that way… Sounds like more research is required 😉
You were right RunnerPack, the header is getting added automatically. I opened one of the freshly compiled demos up in the header editor, and the ROM title is “change this title”. I wonder if there’s a way to set that during compile time…
On a side note, in order to get the header editor to open with wine, I had to copy a couple of files from my XP install to the wine folder to get it to run. (Although I’m sure if you don’t have a Windows install, you can probably find them online.) Personally, I think it would be great if all the VB software that has been written went open source…
Fwirt wrote:
You were right RunnerPack, the header is getting added automatically. I opened one of the freshly compiled demos up in the header editor, and the ROM title is “change this title”. I wonder if there’s a way to set that during compile time…
I don’t think the built-in title etc. can be changed without editing the crt0, but I was thinking of making a command-line header editor that can be used in a makefile.
Personally, I think it would be great if all the VB software that has been written went open source…
I second that! Especially the tools released by Alberto “Virtual-E” Covarrubias. I would love to have the source for his assembler, C compiler, and VIDE.
RunnerPack wrote:
I was thinking of making a command-line header editor that can be used in a makefile.
You must have read my mind. I was thinking that I should do that but (a) I would have no clue where to start and (b) I thought it would only be really necessary on ROMs built for release. But if you want to write one, I’d probably end up using it. 🙂
(The forum wouldn’t accept the attachments :question: :-?)
@Dev’rs: After it’s posted, try it out and let me know about any bugs you find (or if the docs are confusing). It’s so simple it should work fine, and it does have some error checking, but it still needs more field-testing.
