Resuming activity from the LED blinker program - page 4 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 3 [4]   Go Down

Resuming activity from the LED blinker program

  • 37 Replies
  • 14538 Views
*

Offline reyalp

  • ******
  • 14125
Re: Resuming activity from the LED blinker program
« Reply #30 on: 27 / August / 2009, 16:54:46 »
Advertisements
Quote from: RaduP on 27 / August / 2009, 13:38:53
After thinking for a while, I came upon a question I can't find an answer for.
Except for data values that change PC, is there really a point to change the other data (pointers) from the old address to the new address? I mean, it's not like the ROM dissapears or anything, so that data is still valid. So long as the code execution doesn't go to the ROM functions, why would we want to change the pointers?
As I said before, not all code pointers are loaded directly into PC. Many are passed to functions, stored in memory etc. So how do you distinguish between data and code pointers ? How about data structures that contain function pointers ?

Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Resuming activity from the LED blinker program
« Reply #31 on: 27 / August / 2009, 17:07:05 »
oh, I thought you were talking about pointers in general, like data pointers.
If code pointers are passed, yeah, that would be a problem :/
Logged
*

Offline RaduP

  • *****
  • 926
Re: Resuming activity from the LED blinker program
« Reply #32 on: 27 / August / 2009, 17:12:21 »
Well, now that I am thinking about it, perhaps code pointers are not that problematic, so long as they point to functions rather than middle of functions. It is easy to determine a function beginning from the STMFD instruction (at least in the Canon firmware).
Logged
*

Offline reyalp

  • ******
  • 14125
Re: Resuming activity from the LED blinker program
« Reply #33 on: 27 / August / 2009, 17:14:34 »
Quote from: RaduP on 27 / August / 2009, 17:12:21
Well, now that I am thinking about it, perhaps code pointers are not that problematic, so long as they point to functions rather than middle of functions. It is easy to determine a function beginning from the STMFD instruction (at least in the Canon firmware).
No, it isn't.
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Resuming activity from the LED blinker program
« Reply #34 on: 27 / August / 2009, 20:16:16 »
Well, can you elaborate on that?
Logged
*

Offline reyalp

  • ******
  • 14125
Re: Resuming activity from the LED blinker program
« Reply #35 on: 28 / August / 2009, 00:49:18 »
Quote from: RaduP on 27 / August / 2009, 20:16:16
Well, can you elaborate on that?
There are lots of functions that don't start with the standard prologue.
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Resuming activity from the LED blinker program
« Reply #36 on: 28 / August / 2009, 03:15:45 »
Ok, I worked a few hours today at my disassembler, and improved the code analyze feature.
I am now able to find MOST of the code (maybe 90%) with a pretty good accuracy (there are a few garbage instructions marked as code, but that's because I don't check for the validity of the instructions yet).

This is done by looking at all the b/bl instructions, seeing if they are within the proper range, and then check where it ends and stuff.
As I expected, some code is not found, for example in what the compiler compiles some of the "case/switch" statements. Some of the not found code begins with stmfd, some does not.

So far, it's looking good, I'll improve the accuracy as I go, and once I have most of my code and data marked properly, I can actually check for pointers to the code, which have to be replaced.
Logged
*

Offline RaduP

  • *****
  • 926
Re: Resuming activity from the LED blinker program
« Reply #37 on: 28 / August / 2009, 15:50:56 »
I was thinking last night, this method will probably not work in the camera, because it takes too long.
On my PC (AMD at 2.4 Ghz), it can take up to 10 seconds, and probably longer when I do more error checkins and stuff. On the camera it will probably take minutes.
So I am thinking of saving the values that need to be modified, so the camera will just use them, without having to analyze the code. Saving them in a binary file won't do the trick because at that stage we can't read files. So I will save them in a C or h file, which will be specific for each camera and firmware version.
Logged
Pages: 1 2 3 [4]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal