gpg: failed to create temporary file '/var/lib/lurker/.#lk0x57448100.hantslug.org.uk.7097': Permission denied
gpg: keyblock resource '/var/lib/lurker/pubring.gpg': Permission denied
gpg: Signature made Sat Jul 24 22:09:10 2010 BST
gpg: using DSA key 20ACB3BE515C238D
gpg: Can't check signature: No public key
On Sat, Jul 24, 2010 at 09:21:57AM +0100, James Courtier-Dutton wrote:
> I am writing a open source tool that decompiles binary code.
> I have it working quite well, taking the binary code and outputting a
> .c program.
> I call it "libbeauty" and it is hosted here: http://revenge.berlios.de/
>
> I am trying to come up with an algorithm that will discover the size
> of the data array.
Don't bother, you're on a hiding to nothing with that one.
If you examine the code, you'll find that the memory for
locally-scoped arrays array is typically allocated on the stack. IIRC,
on x86 (and certainly on ARM, which is where my experience in
decompiling things comes from), the standard stack grows *downwards*.
This means that if you keep a map of the contents of the stack
below(*) the current stack frame, you can look at the base address of
the array, and take the difference between that and the next thing
up(**) on the stack, divide by sizeof(array_type), and Robert's your
uncle's live-in lover, as they say.
(*) below in terms of memory address. Actually "above" in terms of stack growth.
(**) up by memory, down by stack growth...
Keeping said map should be relatively easy, because every variable
in local scope will either be on the stack (and accessed at SP+i, for
some i), or will only be allocated to a register (in which case you
don't care about it, for these purposes).
> Can anyone come up with a better algorithm?
HTH,
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- In event of Last Trump, please form an orderly queue ---
and await judgement.
