Why do you need to Get all caller addresses of a given function procedure ?
This can be solved with static code analysis - as long as there is no
procedural variables involved - but its weird to have such a
necessity... Sounds like the project started with the wrong
assumptions...
Thats my two
Am Sunday 12 August 2012 09:49:36 schrieb Jorge Aldo G. de F. Junior:
Why do you need to Get all caller addresses of a given function procedure
?
If you read the thread you will now.
Because I need an easy handling multi language interface.
This can be solved with static code analysis - as
Rainer Stratmann wrote:
For the above mentioned purpose it works perfect since some days.
I got all caller adresses and even more I got all text snippets (pchar to the
snippet!). If you know something about assembler language then it is not a
huge effort to get this information from the
On 12 Aug 2012, at 15:25, Mark Morgan Lloyd wrote:
Rainer Stratmann wrote:
For the above mentioned purpose it works perfect since some days.
I got all caller adresses and even more I got all text snippets (pchar to
the snippet!). If you know something about assembler language then it is
Am Sunday 12 August 2012 15:29:44 schrieb Jonas Maebe:
Florian already implemented that quite a while ago :) I suggest to drop the
topic though, because Rainer does not appear to be open to taking another
approach
It depends on the approach.
If you have a better solution would you take another
On 12.08.2012 15:37, Rainer Stratmann wrote:
Am Sunday 12 August 2012 15:25:17 schrieb Mark Morgan Lloyd:
Hey, Jonas, when are you introducing the optimisation that a call at the
end of a procedure can be replaced by a jmp? :-)
Jonas only introduces something if it causes not much work :-)
Am Sunday 12 August 2012 15:46:00 schrieb Sven Barth:
I know there is a smiley, but: Only because Jonas sees no gain in
implementing something in the compiler that would help you in your
specific case does not mean that Jonas doesn't add anything that causes
not much work.
That my suggestions
On 12.08.2012 15:57, Rainer Stratmann wrote:
Am Sunday 12 August 2012 15:46:00 schrieb Sven Barth:
I know there is a smiley, but: Only because Jonas sees no gain in
implementing something in the compiler that would help you in your
specific case does not mean that Jonas doesn't add anything
The code below finds all caller adresses in a program to a known
procedure/function adress.
With this I can get all caller adresses to the translate function.
Moreover - with another piece of code (not shown here) I got also the text
snippets itself, because they are loaded immediately before
Am Saturday 11 August 2012 13:40:44 schrieb Rainer Stratmann:
procedure i_realy_know_what_i_am_doing( p_opcode : pbyte ; count : longint
; proc_adr : pointer );
Better: i_really_know_what_i_am_doing
___
fpc-pascal maillist -
On 11/08/2012 12:48, Rainer Stratmann wrote:
Am Saturday 11 August 2012 13:40:44 schrieb Rainer Stratmann:
procedure i_realy_know_what_i_am_doing( p_opcode : pbyte ; count : longint
; proc_adr : pointer );
Better: i_really_know_what_i_am_doing
You have read the long discussion thread, about
Am Saturday 11 August 2012 13:52:58 schrieb Martin:
On 11/08/2012 12:48, Rainer Stratmann wrote:
Am Saturday 11 August 2012 13:40:44 schrieb Rainer Stratmann:
procedure i_realy_know_what_i_am_doing( p_opcode : pbyte ; count :
longint ; proc_adr : pointer );
Better:
On 11/08/2012 13:00, Rainer Stratmann wrote:
Am Saturday 11 August 2012 13:52:58 schrieb Martin:
On 11/08/2012 12:48, Rainer Stratmann wrote:
Am Saturday 11 August 2012 13:40:44 schrieb Rainer Stratmann:
procedure i_realy_know_what_i_am_doing( p_opcode : pbyte ; count :
longint ; proc_adr :
Am Saturday 11 August 2012 14:15:11 schrieb Martin:
I do not read all discussions.
Which exactly headline has it?
Does it affect the possibility to get the information I want?
Re: [fpc-devel] Re: Class field reordering
The searched procedure/function is not a class procedure or function.
On 11/08/2012 13:32, Rainer Stratmann wrote:
Am Saturday 11 August 2012 14:15:11 schrieb Martin:
If that changes, then your code fails.
I can easily adopt the code then.
There are not many different ways for a call.
http://css.csail.mit.edu/6.858/2011/readings/i386/CALL.htm
Yes, so the
Am Saturday 11 August 2012 14:46:53 schrieb Martin:
On 11/08/2012 13:32, Rainer Stratmann wrote:
Am Saturday 11 August 2012 14:15:11 schrieb Martin:
If that changes, then your code fails.
I can easily adopt the code then.
There are not many different ways for a call.
In our previous episode, Rainer Stratmann said:
There are not many different ways for a call.
http://css.csail.mit.edu/6.858/2011/readings/i386/CALL.htm
Yes, so the amount of effort may increase drastically. New CPU may bring
new ways too.
But not the 80x86 CPU. It is still the
Sorry for posting without bringing a solution, but i am curious, why
do you need this ?
Doesnt sound like good programming practice...
2012/8/11 Marco van de Voort mar...@stack.nl:
In our previous episode, Rainer Stratmann said:
There are not many different ways for a call.
Am Saturday 11 August 2012 17:34:44 schrieb Marco van de Voort:
In our previous episode, Rainer Stratmann said:
But not the 80x86 CPU. It is still the same opcode for a call ($E8).
Maybe not the call, but changing or adding address encoding is quite
realistic.
I assume you tested your code
Am Saturday 11 August 2012 19:18:39 schrieb Jorge Aldo G. de F. Junior:
Sorry for posting without bringing a solution, but i am curious, why
do you need this ?
Doesnt sound like good programming practice...
See Thread:
Get all caller adresses of a given function/procedure before executing
We
20 matches
Mail list logo
