[fpc-pascal] Re: Get all caller adresses of a given
function/procedure before executing
RainerStratmann at t-online.de
Wed Aug 15 17:05:03 CEST 2012
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?]
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
Very huge labour intensive I think!
More information about the fpc-pascal