#19576 - -Ramirez- - Thu Apr 22, 2004 7:12 am
Yeah... I'm just that... a newbie to assembly. I've been doing extensive research on the language for the past few days, and it's quite different from what I'm used to. However, I'm getting the hang of it... slowly, with a few bumps along the way.
For future reference (as I'm no doubt going to be asking more questions later), I thought I'd mention what I'm learning assembly for. It's not to create a GBA game or anything of that sort. It's merely so I can read the disassembly of a ROM and be able to extract certain formulas for use in an IRC bot. Weird? Maybe... but I've always wanted to do it. :) In case you're wondering, the game is Pokemon Sapphire. Yeah yeah, I know, Pokemon?! I've always loved the battle system that's in the game, as well as the extreme selection of different characters.
Now... on to the questions! (I sure hope you guys aren't evil to newcomers... :P) First off... the research I've done suggests that Mappy VM is probably the best emulator to use for debugging needs. (For me anyway.) The problem is... I get no video or sound on that emulator, so it's kind of hard to use. So... if you have a way to fix that, or another emulator suggestion, that would be very helpful. (I know, this has nothing to do with assembly, but I imagine you don't want me creating a new thread for each new question... so I plan to just post new questions in this thread over and over.)
Ok... now on to a few assembly questions, which are extremely basic, so you guys shouldn't even have to think to answer them. :P For the code to be able to read any values stored in the RAM, it has to first load them, correct? If so, shouldn't I be able to search the disassembly for an address that matches an address I know of in RAM and be able to find it? For example, I know that 0x02025C96 is the address that contains the value of the amount of an item you have in the game. A search for that address in the disassembly produces no results. I know that it could be loading an earlier address and simply add to that one and eventually reach the address I mentioned, but that makes me wonder how one is ever to find certain things if it's so broad. Any suggestions you may have about finding where the code loads certain addresses would be appreciated. Oh... and while we're on the subject of searching for addresses... I have been COMPLETELY unable to find anything that can actually save disassembly to a file, or let you search through it, with the exception of Mappy. (Mappy loads the ROM, but the screen stays blank and I get no sound. I was able to use its export feature even under these conditions. The problem is that it doesn't even recognize all of the mnemonics/opcodes used.) So... I'd like to know what's good to use for disassembling a ROM file, or of an emulator that can accurately export it.
Well, I guess that's all for now. Sorry if I'm an annoying newbie, but everyone has to start somewhere, right? :(
#19582 - torne - Thu Apr 22, 2004 11:30 am
Your questions:
I would recommend No$GBA rather than Mappy - you will have to do some hunting to find a copy as the author has discontinued the free version, but the licence explicitly allows previously released versions to still be distributed (it's just not on his site any more). It has a very nice debugger in it. =)
On the subject of addressing, it's not the case that that address will have to be in the disassembly. It may be being accessed as a PC-relative offset, which depending on your disassembler (I've not seen Mappy's output) may be displayed as just an offset, rather than an absolute address. More likely, it is being accessed as an offset into a structure; for example, the address given could be being accessed like:
| Code: |
ldr r0,=0x02025c00
ldr r1, [r0, #0x96] |
Of course, there are a massive number of variations on this, and the pair of instructions are not guarenteed to be adjacent.. or even to be a pair.
The easiest way to find where the address is loaded is to have a debugger that can trap memory accesses; simply have it break whenever you read that address. =)
The best disassembly tool I've ever used is DataRescue IDA Pro, which has godlike analysis and reverse engineering powers (it's used by security teams to analyse new worms/viruses just entering the wild when an explanation is desired in, say, an hour). Unfortunately it costs $400 for the standard version and $800 for the advanced version (the standard version is sufficient for the GBA as it understands ARM, but for PPC support I had to get the advanced version). If you want something free, objdump (part of GNU binutils) is a complete disassembler, but not a very smart one; any of the GBA devkits you can download from this site (devkitadvance, devkitarm..etc) will contain objdump. It will happily disassemble every byte in the ROM, regardless of whether it's code or data. This might be the issue you are having with Mappy; some of the 'unknown opcodes' may in fact actually just be data bytes. It's normal to have a few bytes of data at the end of each function, depending on the compiler and settings used to generate the code - this is the constant pool used to load values that cannot be constructed directly as operands. IDA determines what is code and what is data automatically based on tracing memory accesses and execution flow (static analysis, so it needs a little help from a human for difficult code).
You're not an annoying newbie; you asked sensible questions politely, and in good Englis, and thus deserve all the assistance we can give you =)
#19586 - isildur - Thu Apr 22, 2004 2:24 pm
As for the debugger choice, did you try Cowbite? That's the one I prefer (not having the free No$GBA, the shareware version is too limited).
http://cowbite.emuunlim.com
#19596 - -Ramirez- - Thu Apr 22, 2004 5:11 pm
| torne wrote: |
| Your questions:I would recommend No$GBA rather than Mappy - you will have to do some hunting to find a copy as the author has discontinued the free version, but the licence explicitly allows previously released versions to still be distributed |
I searched like crazy for older versions of it... the oldest one I found was 1.0b or something along those lines. It still had that 256KB limit, which makes loading the Sapphire ROM impossible.
| torne wrote: |
On the subject of addressing, it's not the case that that address will have to be in the disassembly. It may be being accessed as a PC-relative offset, which depending on your disassembler (I've not seen Mappy's output) may be displayed as just an offset, rather than an absolute address. More likely, it is being accessed as an offset into a structure; for example, the address given could be being accessed like:
| Code: | ldr r0,=0x02025c00
ldr r1, [r0, #0x96] |
Of course, there are a massive number of variations on this, and the pair of instructions are not guarenteed to be adjacent.. or even to be a pair. |
Yeah, that's what I assumed must have been going on, considering searching for the exact address produced nothing. The problem now becomes tracking it down.
| torne wrote: |
| The easiest way to find where the address is loaded is to have a debugger that can trap memory accesses; simply have it break whenever you read that address. =) |
Which ones do you know of that are capable of doing such a thing? I don't recall seeing this option on any of the emulators I've tried.
| torne wrote: |
| The best disassembly tool I've ever used is DataRescue IDA Pro, which has godlike analysis and reverse engineering powers. Unfortunately it costs $400 for the standard version and $800 for the advanced version (the standard version is sufficient for the GBA as it understands ARM, but for PPC support I had to get the advanced version). |
I've seen a lot about this program while I was searching for something good to debug with. It definitely seemed like a good program... but that price is completely undoable for me. *sigh* Nothing is ever free anymore, is it?
| torne wrote: |
| If you want something free, objdump (part of GNU binutils) is a complete disassembler, but not a very smart one; any of the GBA devkits you can download from this site (devkitadvance, devkitarm..etc) will contain objdump. It will happily disassemble every byte in the ROM, regardless of whether it's code or data. |
I tried that after you mentioned it, and it appears to only allow me to disassemble .ELF files. Unless I was using it wrong or something... that's not going to work.
| torne wrote: |
| This might be the issue you are having with Mappy; some of the 'unknown opcodes' may in fact actually just be data bytes. It's normal to have a few bytes of data at the end of each function, depending on the compiler and settings used to generate the code |
I considered that... but other emulators (namely VGBA) were showing actual opcodes rather than "undefined" or whatever in the same addresses that Mappy showed "undefined.' I just assumed Mappy is the one with problems, as it's the one that can't even display anything for me. :P
| torne wrote: |
| and in good Englis |
Haha, seems like that's rare nowadays, doesn't it?
| isildur wrote: |
| As for the debugger choice, did you try Cowbite? |
Yes. It has the same video problem for me as Mappy.
#19602 - torne - Thu Apr 22, 2004 7:05 pm
| -Ramirez- wrote: |
| It still had that 256KB limit, which makes loading the Sapphire ROM impossible. |
Unfortunately, that's the limitation imposed by the free version. All versions of the free version have that limit. I forgot you were disassembling a commercial cart. =)
| Quote: |
| torne wrote: | | The easiest way to find where the address is loaded is to have a debugger that can trap memory accesses; simply have it break whenever you read that address. =) |
Which ones do you know of that are capable of doing such a thing? I don't recall seeing this option on any of the emulators I've tried. |
VBA should be able to do this, either natively or through the GDB stub.
| Quote: |
| I've seen a lot about this program while I was searching for something good to debug with. It definitely seemed like a good program... but that price is completely undoable for me. *sigh* Nothing is ever free anymore, is it? |
I can't afford it either, but the computer lab with which I'm associated has licences and thus I can use it on the lab machines. =)
| Quote: |
| torne wrote: | | If you want something free, objdump (part of GNU binutils) is a complete disassembler, but not a very smart one; any of the GBA devkits you can download from this site (devkitadvance, devkitarm..etc) will contain objdump. It will happily disassemble every byte in the ROM, regardless of whether it's code or data. |
I tried that after you mentioned it, and it appears to only allow me to disassemble .ELF files. Unless I was using it wrong or something... that's not going to work. |
You're using it wrong. It defaults to assuming the input file is ELF. All you need to do is tell it what it is - the object type you have is 'binary'. =) You may also need to use the 'disassemble all' option because there is no section information in a binary. You also need to manually tell it whether to disassemble as ARM or Thumb; this is yet another thing which may be a problem for Mappy. IIRC, VBA disassembles instructions based on what the CPU is currently set to; so if it's executing ARM code, it will disassemble everything as ARM code (which will look wrong for anything that's Thumb) and vice versa. There is no way of telling what is Thumb and what is ARM reliably other than using execution tracing (which, yes, IDA does for you).
| Quote: |
| torne wrote: | | and in good Englis |
Haha, seems like that's rare nowadays, doesn't it? |
Well, now I look dumb. =)
#19616 - -Ramirez- - Thu Apr 22, 2004 10:03 pm
| torne wrote: |
| VBA should be able to do this, either natively or through the GDB stub. |
It certainly doesn't appear to have this feature built-in. So... what is this "GDB stub?" I've seen the menu option for "GDB," but had no idea what it was for.
| torne wrote: |
| I can't afford it either, but the computer lab with which I'm associated has licences and thus I can use it on the lab machines. =) |
Lucky... :P
| torne wrote: |
| You're using it wrong. It defaults to assuming the input file is ELF. All you need to do is tell it what it is - the object type you have is 'binary'. =) You may also need to use the 'disassemble all' option because there is no section information in a binary. You also need to manually tell it whether to disassemble as ARM or Thumb |
Oh... I should have looked at the options more closely. I figured it out now, thanks.
-Edit-
Well, not quite. Is it capable of saving the output to a file? If so, I don't see the option for it anywhere...
| torne wrote: |
| this is yet another thing which may be a problem for Mappy. IIRC, VBA disassembles instructions based on what the CPU is currently set to; so if it's executing ARM code, it will disassemble everything as ARM code (which will look wrong for anything that's Thumb) and vice versa. There is no way of telling what is Thumb and what is ARM reliably other than using execution tracing (which, yes, IDA does for you). |
So it can actually switch between ARM and Thumb in the middle of the disassembly? Does objdump account for that?
| torne wrote: |
| Well, now I look dumb. =) |
Everyone typos. :P It's not as if you don't know how to spell the word, or intentionally spelled it that way.
#19620 - torne - Thu Apr 22, 2004 10:25 pm
| -Ramirez- wrote: |
| It certainly doesn't appear to have this feature built-in. So... what is this "GDB stub?" I've seen the menu option for "GDB," but had no idea what it was for. |
Are you using the VBA command-line debugger? You shouldn't be looking on the menu options. =)
A GDB stub is the piece of code that GDB, the GNU Debugger, connects to in order to debug a target machine. You get GDB, or Insight, or some other GDB front end, and connect to the stub in VBA, and then you can debug doing anything that GDB supports.
| Quote: |
| torne wrote: | | You're using it wrong. It defaults to assuming the input file is ELF. All you need to do is tell it what it is - the object type you have is 'binary'. =) You may also need to use the 'disassemble all' option because there is no section information in a binary. You also need to manually tell it whether to disassemble as ARM or Thumb |
Oh... I should have looked at the options more closely. I figured it out now, thanks.
-Edit-
Well, not quite. Is it capable of saving the output to a file? If so, I don't see the option for it anywhere... |
Uhm.. just redirect the output to a file. 'objdump --options inputfile > output.asm'
| Quote: |
| So it can actually switch between ARM and Thumb in the middle of the disassembly? Does objdump account for that? |
Well, yes. The ARM code, the Thumb code, and the data are all mixed up together in what will seem to be a pretty random fashion. If you don't understand how that works, then you are unlikely to get far disassembling a rom, tbh.. there is no way to distinguish which is which without tracing the execution flow, which is extremely nontrivial to do by hand, and is hard to do even with a debugger. No disassembler that I've ever seen or heard of can do it, other than IDA, and IDA still needs human guidance to do it.
You will do reasonably well to assume that almost all the code is Thumb, because it *probably* is. There might be large chunks of ARM, there might only be small chunks, there might be hardly any at all, but I would be very suprised if the majority wasn't Thumb. Of course, Pokemon is a big, complicated ROM, and easily the vast majority of it is not code at all but data. =)
#19624 - -Ramirez- - Thu Apr 22, 2004 11:03 pm
| torne wrote: |
| Are you using the VBA command-line debugger? You shouldn't be looking on the menu options. =) |
Haha, nope. I didn't realize it had more options. I'm certainly using it now. :)
| torne wrote: |
| A GDB stub is the piece of code that GDB, the GNU Debugger, connects to in order to debug a target machine. You get GDB, or Insight, or some other GDB front end, and connect to the stub in VBA, and then you can debug doing anything that GDB supports. |
Oh, I'll have to try that then. If you don't mind, can you point me to where I can download one of the two? I can always go search if you don't have one.
| torne wrote: |
| Uhm.. just redirect the output to a file. 'objdump --options inputfile > output.asm' |
I feel like a moron now. I had no idea you could do that with any program. Looks like I'm not exactly an expert with the command prompt either. :P
| torne wrote: |
| Well, yes. The ARM code, the Thumb code, and the data are all mixed up together in what will seem to be a pretty random fashion. If you don't understand how that works, then you are unlikely to get far disassembling a rom, tbh.. there is no way to distinguish which is which without tracing the execution flow, which is extremely nontrivial to do by hand, and is hard to do even with a debugger. No disassembler that I've ever seen or heard of can do it, other than IDA, and IDA still needs human guidance to do it. |
Thanks for the boost in confidence... :( Somehow I think I'll still be able to manage. One of my friends was able to do quite a bit in terms of extracting the formulas he needed from another ROM. He didn't have IDA Pro or anything like that either. (If you're wondering why I don't ask HIM about all of this, it was a while ago, and I don't see him very often anymore.)
| torne wrote: |
| You will do reasonably well to assume that almost all the code is Thumb, because it *probably* is. There might be large chunks of ARM, there might only be small chunks, there might be hardly any at all, but I would be very suprised if the majority wasn't Thumb. Of course, Pokemon is a big, complicated ROM, and easily the vast majority of it is not code at all but data. =) |
VBA seems to display it as ARM almost all the time. ARM is the language I've been researching and studying, so I hope you're wrong. :(
-Edit-
Actually, now that I'm using the SDL version, you seem to be correct, unfortunately. It's showing most things in Thumb now. *goes to find Thumb versions of the documents he has*
#19626 - torne - Thu Apr 22, 2004 11:18 pm
| -Ramirez- wrote: |
| torne wrote: | | Are you using the VBA command-line debugger? You shouldn't be looking on the menu options. =) |
Haha, nope. I didn't realize it had more options. I'm certainly using it now. :) |
It's the only debugger I've really used much, though I tend not to use debuggers (on any platform).
| Quote: |
| torne wrote: | | A GDB stub is the piece of code that GDB, the GNU Debugger, connects to in order to debug a target machine. You get GDB, or Insight, or some other GDB front end, and connect to the stub in VBA, and then you can debug doing anything that GDB supports. |
Oh, I'll have to try that then. If you don't mind, can you point me to where I can download one of the two? I can always go search if you don't have one. |
GDB is just, well, GDB. It's GNU software, same as everything else. VBA's site has a copy of Insight compiled for Windows, targetting ARM and all ready to plug into VBA.
| Quote: |
| torne wrote: | | Uhm.. just redirect the output to a file. 'objdump --options inputfile > output.asm' |
I feel like a moron now. I had no idea you could do that with any program. Looks like I'm not exactly an expert with the command prompt either. :P |
What you can do using an NT shell (presumably you are) is nothing compared to what you get with a Unix-style shell (such as the Cygwin version of bash). Shell is magic. =)
| Quote: |
| Thanks for the boost in confidence... :( Somehow I think I'll still be able to manage. One of my friends was able to do quite a bit in terms of extracting the formulas he needed from another ROM. He didn't have IDA Pro or anything like that either. (If you're wondering why I don't ask HIM about all of this, it was a while ago, and I don't see him very often anymore.) |
Well, if you can get the debugger to work for you nicely, you shouldn't have many problems; the kind of thing you're looking for will probably be easier through a debugger than just a disassembly.
| torne wrote: |
| VBA seems to display it as ARM almost all the time. ARM is the language I've been researching and studying, so I hope you're wrong. :( |
VBA displays it as ARM if it's executing ARM code at the moment. This means that wherever the current instruction pointer is, is ARM code; typically, the code just in front of and behind that will be the same. =)
Thumb and ARM are two different opcode encodings for the same processor; every Thumb instruction maps to an ARM instruction which has the same effects (though the converse is not true) - thus, they are not different languages and you shouldn't have to learn anything. Almost every opcode is the same, they just have restricted choices of operands/flags, or take two operands instead of three (e.g. arithmetic instructions in Thumb always assume that the destination is the same as the first source).
#19627 - -Ramirez- - Thu Apr 22, 2004 11:35 pm
| torne wrote: |
| VBA's site has a copy of Insight compiled for Windows, targetting ARM and all ready to plug into VBA. |
I'll go take a look, thanks.
| torne wrote: |
| What you can do using an NT shell (presumably you are) is nothing compared to what you get with a Unix-style shell (such as the Cygwin version of bash). Shell is magic. =) |
So I've heard... but I really have no reason to use any unix OSs, so I'll have to live with Windows. :P
| torne wrote: |
| Well, if you can get the debugger to work for you nicely, you shouldn't have many problems; the kind of thing you're looking for will probably be easier through a debugger than just a disassembly. |
Yeah, VBA's debugger is working extremely well for me now. This should be all I need.
#19630 - torne - Fri Apr 23, 2004 12:11 am
| -Ramirez- wrote: |
| torne wrote: | | What you can do using an NT shell (presumably you are) is nothing compared to what you get with a Unix-style shell (such as the Cygwin version of bash). Shell is magic. =) |
So I've heard... but I really have no reason to use any unix OSs, so I'll have to live with Windows. :P |
I use Windows. Cygwin lets you have a perfectly good *nix shell anyway. My default command prompt is bash, and my Windows machine runs X. =)
#19632 - -Ramirez- - Fri Apr 23, 2004 12:35 am
| torne wrote: |
| I use Windows. Cygwin lets you have a perfectly good *nix shell anyway. My default command prompt is bash, and my Windows machine runs X. =) |
Wtf, now I REALLY didn't know about that. I'll definitely have to look into it after I'm all done with this.
Btw, VBA's debugger is so useful. I'm able to do exactly what I was wanting. Thanks a lot for all of your help. :) I may need some help with understanding some assembly concepts later... if I do, I'll be sure to post. :P
Thanks again.
#19634 - torne - Fri Apr 23, 2004 12:49 am
That's what Cygwin does; lets *nix software compile to run under Windows. Your ARM devkit (objdump..etc) is almost certainly compiled for Cygwin. =)
And yeah, the inbuilt debugger is quite nice; I could never get the GDB stub to work right so I just used that.
#19642 - -Ramirez- - Fri Apr 23, 2004 1:58 am
| torne wrote: |
| I could never get the GDB stub to work right so I just used that. |
I couldn't either. Even if it did work, I can't imagine it being much more useful than the built-in one already is.
Oh, and I have a new question. ;) What exactly do the opcodes "PUSH" and "POP" do? Something to do with stack, which I guess is what I need to have explained to me. What is the stack? It appears to be some sort of storage area.
-Edit-
...and another. How exactly does branching work? When it executes the branch, does it just jump to the specified position and execute whatever is on that address? Does it just do that one "command", or does it execute more than that? If it goes longer, how does it know where to stop?
#19654 - Miked0801 - Fri Apr 23, 2004 4:12 am
Push places registers on the stack (a memory pointer that grows backwards from roughly the end of memory.) Pop takes them back off. Branch is a goto - it jumps to the location and continues running - no return. BTW, the code never stops executing so beware where you jump to... :)
#19656 - -Ramirez- - Fri Apr 23, 2004 4:29 am
| Miked0801 wrote: |
| Push places registers on the stack (a memory pointer that grows backwards from roughly the end of memory.) Pop takes them back off. |
I see. So... how does it read from the stack once it's placed something there?
| Miked0801 wrote: |
| Branch is a goto - it jumps to the location and continues running - no return. BTW, the code never stops executing so beware where you jump to... :) |
Ok, that makes sense. So what's the difference between B, BL, and BX?
#19661 - poslundc - Fri Apr 23, 2004 5:32 am
| -Ramirez- wrote: |
| Miked0801 wrote: | | Push places registers on the stack (a memory pointer that grows backwards from roughly the end of memory.) Pop takes them back off. |
I see. So... how does it read from the stack once it's placed something there? |
You use pop to read off the most recent (top) entry on the stack, at the same time as you remove it. That is the general principle behind stack operation: you only ever either add new stuff onto it or access the top item when you remove it, and it is last-in-first-out (LIFO) as opposed to a queue, which is FIFO.
(In practice you can access elements other than the top one but this is how general stack behaviour works.)
| Quote: |
| Miked0801 wrote: | | Branch is a goto - it jumps to the location and continues running - no return. BTW, the code never stops executing so beware where you jump to... :) |
Ok, that makes sense. So what's the difference between B, BL, and BX? |
B - Branch jumps to a local address that is calculated as an offset relative to the program counter (PC).
BL - Branch and Link is the same as Branch, but it stores the current address in the link register (LR) before jumping so that you can return from what is usually a subroutine.
BX - Branch and Exchange reads the destination address out of a register instead of calculating a PC-relative offset. This makes it possible to jump much further than you can with B or BL. It also lets you switch processing modes from ARM to Thumb or vice-versa.
For more details read the docs for the ARM7TDMI processor.
Dan.
#19709 - -Ramirez- - Fri Apr 23, 2004 7:39 pm
| poslundc wrote: |
| You use pop to read off the most recent (top) entry on the stack, at the same time as you remove it. That is the general principle behind stack operation: you only ever either add new stuff onto it or access the top item when you remove it, and it is last-in-first-out (LIFO) as opposed to a queue, which is FIFO. |
I understand, thanks.
| poslundc wrote: |
| B - Branch jumps to a local address that is calculated as an offset relative to the program counter (PC). |
What exactly is the PC? How is it set?
| poslundc wrote: |
| BL - Branch and Link is the same as Branch, but it stores the current address in the link register (LR) before jumping so that you can return from what is usually a subroutine. |
Ok, is this the only way LR can be modified?
| poslundc wrote: |
| BX - Branch and Exchange reads the destination address out of a register instead of calculating a PC-relative offset. This makes it possible to jump much further than you can with B or BL. It also lets you switch processing modes from ARM to Thumb or vice-versa. |
I actually don't have any questions about this one. :P
| poslundc wrote: |
| For more details read the docs for the ARM7TDMI processor. |
Yeah... I already have several documents, but they're not exactly newbie friendly most of the time.
I also have a new question. Is it possible to use VGBA to break when a certain address is accessed? That would be the absolute best thing for what I need to do. The Sapphire ROM is huge, and I have quite a few areas mapped out. If I could simply set a breakpoint whenever a certain address is read from, I could see the code I need very easily.
#19716 - tepples - Fri Apr 23, 2004 8:12 pm
| -Ramirez- wrote: |
| What exactly is the PC? How is it set? |
The program counter (r15) contains the address a few bytes ahead of the currently executing instruction. Set it with branch instructions or with just plain moves into r15. However, only the BX instruction can change between ARM and Thumb modes on ARM7TDMI. (Later revisions of the ARM architecture have fixed this bug and can change modes on moves to r15.)
| Quote: |
| Ok, is [the BL instruction] the only way LR can be modified? |
LR is a general-purpose register. Moves in and out of it work as expected.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#19724 - torne - Fri Apr 23, 2004 9:29 pm
| tepples wrote: |
| However, only the BX instruction can change between ARM and Thumb modes on ARM7TDMI. (Later revisions of the ARM architecture have fixed this bug and can change modes on moves to r15.) |
Calling that a bug is a bit much; the logic required is totally different, so it's not like it's something they forgot. =)
#19735 - -Ramirez- - Sat Apr 24, 2004 2:07 am
Thanks. It's nice to know people are willing to answer simple questions.
Now... (to anyone) what about the breakpoint on memory access?
#19736 - poslundc - Sat Apr 24, 2004 3:17 am
It should be doable if you get GDB working with VBA... but without it I think the best you can do is place an infinite loop where you want the code to break.
Dan.
#19737 - -Ramirez- - Sat Apr 24, 2004 4:05 am
| poslundc wrote: |
| It should be doable if you get GDB working with VBA... but without it I think the best you can do is place an infinite loop where you want the code to break. |
I don't think you understand what I'm looking for. I need to find the code area that actually accesses a certain address in the ROM. I would have no clue where to place a breakpoint in the actual disassembly.
#19738 - poslundc - Sat Apr 24, 2004 5:00 am
Unless GDB supports watching specific memory locations (which it may; I haven't used it in years so I don't recall), I don't know how you would go about doing something like that without some major hacking.
Dan.
#19741 - -Ramirez- - Sat Apr 24, 2004 6:19 am
I know several events in the game itself that would definitely access that area. If I were to enter the debugger while the game was waiting for me to select a menu item (which leads directly to the event which accesses that memory address), wouldn't that allow me to find the code that checks for the menu option to be selected, then follow the path it would take from there? Bah, I didn't word that too well.
Basically... this:
1. Get to the point in the game that gives me the menu to select what I want to do.
2. Enter the debugger.
3. Follow the code from the current address until I find an area checking the state of the A key, which would tell the game to start the event. (Haha, that brings up another problem in itself... how do I check for the A key?)
4. Follow the code along the path it would take if the A key was pressed.
5. I'd eventually find the code that accesses that memory address I'm looking for, would I not?
If that would work, it'd be acceptable. It might take quite a while to follow through to where I need to be though, I don't know.
#19745 - Miked0801 - Sat Apr 24, 2004 8:08 am
No$GBA allows breakpoints on writes to any memory adress and possibly reads though I haven't tried that yet. This was enabled in the freeware version around somewhere...
#19749 - -Ramirez- - Sat Apr 24, 2004 3:10 pm
| Miked0801 wrote: |
| No$GBA allows breakpoints on writes to any memory adress and possibly reads though I haven't tried that yet. This was enabled in the freeware version around somewhere... |
I can't use No$GBA due to the 256KB limit. I'm not creating a ROM, but loading an existing one.
Btw, is SP another one of these registers that can be used by anything?
#19857 - -Ramirez- - Mon Apr 26, 2004 11:23 pm
Did everyone decide to go on a vacation or something? ;)
#19864 - torne - Tue Apr 27, 2004 12:41 am
I suspect we just don't know the answers. I haven't used a debugger for some time and can't tell you how to stop at a memory access, though I recall it being possible in GDB.
Oh, one I do know the answer to: SP (r13) is the stack pointer, and points to the current top of the stack. It's what pop/push use to keep track of where to pop and push. You can push it down as much as you like (to a point) to give yourself space for local variables, but you have to put it back before you exit the function. =)
#19866 - -Ramirez- - Tue Apr 27, 2004 12:46 am
| torne wrote: |
| I suspect we just don't know the answers. |
You can always post and say you don't know, as you just did. :)
| torne wrote: |
| though I recall it being possible in GDB. |
Yeah, I was just experimenting with that a minute ago. Apparently... trying to set a watchpoint while connected to VBA-SDL doesn't work. That's EXACTLY what I was looking for though. Figures it doesn't work.
| torne wrote: |
| Oh, one I do know the answer to: SP (r13) is the stack pointer, and points to the current top of the stack. It's what pop/push use to keep track of where to pop and push. You can push it down as much as you like (to a point) to give yourself space for local variables, but you have to put it back before you exit the function. =) |
Thanks... are there any other registers with special names that I should know about?
#19880 - poslundc - Tue Apr 27, 2004 7:07 am
| -Ramirez- wrote: |
| torne wrote: | | I suspect we just don't know the answers. |
You can always post and say you don't know, as you just did. :) |
Well, I think it was pretty clear from the previous posts that you were in uncharted territory.
| Quote: |
| Thanks... are there any other registers with special names that I should know about? |
PC - program counter, r15, has the current instruction address in it
LR - link register, r14, is used by subroutines and is updated automatically on the BL instruction. Can be modified so long as it is restored.
IP - intra-procedure scratch register, r12, is always safe to modify in subroutines (ie. you don't have to worry about preserving it).
A1 to A4 - the function-parameter registers, r0-r3, contain any parameters passed to a subroutine and may also be used to return values. Like IP, they do not have to be preserved across function calls.
Those are the biggies.
Dan.
#19885 - Miked0801 - Tue Apr 27, 2004 2:23 pm
and of course Stak Pointer mentioned earlier at r13. I believe r7 is usually the frame-pointer as well though that shouldn't matter for anything.
#19886 - tepples - Tue Apr 27, 2004 2:42 pm
| -Ramirez- wrote: |
| You can always post and say you don't know, as you just did. :) |
I think people avoid cluttering the board with numerous "I don't know" posts because they don't want to appear as post sex-professionals.
| Quote: |
| Apparently... trying to set a watchpoint while connected to VBA-SDL doesn't work. That's EXACTLY what I was looking for though. Figures it doesn't work. |
Then perhaps you might try reporting this as a bug to the VBA maintainers.
| Quote: |
| Thanks... are there any other registers with special names that I should know about? |
R12-R15 (ip, sp, lr, pc) are pretty much all the registers that anybody calls by a special name. Look up their purposes in the ARM Thumb Procedure Call Standard.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#19894 - torne - Tue Apr 27, 2004 8:14 pm
| Miked0801 wrote: |
| I believe r7 is usually the frame-pointer as well though that shouldn't matter for anything. |
Nope, the frame pointer is r11. Code compiled with -fomit-frame-pointer will generally not care what you do with it. r7 is the Thumb-state work register, which means.. well, nothing, really - ARM's compiler likes to use r7 for various things when generating Thumb code, but nothing that forces you to treat it differently to r4-r6, and GCC just doesn't care.
#19908 - Miked0801 - Tue Apr 27, 2004 10:10 pm
Ok, I'd assumed it was r7 as that register isn't pushed/popped as often when omit-framepointer is used. Thanks for the correction.
#19993 - poslundc - Thu Apr 29, 2004 3:03 pm
It was discussed in another thread and it's been my observation that GCC uses r7 as a frame pointer in Thumb mode. It seems to do this regardless of whether a frame pointer is advisable or not (unless the aforementioned omit switch is present, I suppose).
This is also consistent with the ARM/Thumb intraprocedure call standard, which recommends the use of any of r4 to r7 as a frame pointer in Thumb mode.
Dan.
#20002 - Quirky - Thu Apr 29, 2004 6:41 pm
VBA SDL's built in debugger, for DOS/Windows at least, has breaks on memory writes. You may need to use the .elf file. When I didn't have a clue about some silly bugs I found it pretty handy for trapping "random" errors. The command line'll be something like:
vba-sdl -d mygame.elf
Then when the debugger starts, use it like this
> break AgbMain
> c
> bpw 3003cc0
> c
That sets a break at the C start of the prog, then continues to that point. Then you set the break point where you want and continue again. Course, if the point's never reached, you won't break again, so maybe put another break in there somewhere.