[fpc-pascal] Re: Get all caller adresses of a given function/procedure before executing

[Rainer Stratmann]

Am Wednesday 15 August 2012 16:45:03 schrieb Lukasz Sokol:
> >> For example if FPC internals decide to add or remove some padding in
> >> front of the constants.
> >
> > Very unlikely.
> > For which reason should there be padding in front?
>
> For the reason that they always say not to rely on 'internal workings of
> the FPC' :)

For me it was quite easy to see a system in how the compiler generates the 
opcodes. There aren't this much variants to do so.

> > I can not see any insolvable problem here.
>
> Yeah. But it is labour intensive.

Initial search code about 3 hours work.
Add another search method (which should be very rarely) about 10-30 minutes 
work I guess.

> >> Will all your translation work go to waste ?
> >
> > Then I would have a look at the opcodes directly and see what has been
> > changed and likely find a solution.
>
> See above.
>
> > If the maintainers decide to build in the suggested function above then
> > everthing is solved. By now no one of the maintainers wants this.
>
> I can understand why, more or less - this could be a security flaw if you
> can find the final procedure call address like that [and then inject/patch
> it from outside, while the program is running - see what I mean?]

Please explain.
I do not change the code. I am only searching some pointers.

> Sort of the reason why Linux doesn't export System.map any more...
> And the sort of reason why (dx)gettext scans the _source_ not the binary.

If the pointers were provided natively then scaning the source (labour 
intensive) is no more necessary.

> > I also can ask what happens if there are no more maintainers for fpc?
>
> Then you can fork it and maintain for you and for others for eternal glory
> :J

Very huge labour intensive I think!