It seems that on Cocoa an exe is by default relocatable. At least a basic test shows that dumping a stack at runtime for each run (no new compile) gives new addresses.
Fpc 3.2.2
Is there a way to turn this off? (some flag to pass to the linker?)
Mailing lists / fpc-devel / 2023-06
Cocoa and NOT relocatable
6 messages · 3 people · –
- Giuliano Colla 2
- Jonas Maebe 2
- Martin Frb 2
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Il 08/06/23 18:40, Martin Frb via fpc-devel ha scritto:
Show quoted text 7 lines
It seems that on Cocoa an exe is by default relocatable.
At least a basic test shows that dumping a stack at runtime for each
run (no new compile) gives new addresses.
Fpc 3.2.2
Is there a way to turn this off? (some flag to pass to the linker?)
AFAIK there's no way. It's a feature deep in the way the OS handles memory. In a multiprogramming environment any executable must be by definition relocatable, because at each run it must fit in a free area of memory. So the OS has two choices. Either the executable is not relocatable, and you trick it by altering the Memory Management Unit tables to map its virtual fixed addresses to any free memory area, or you make it relocatable, loose a little time when loading to locate it, and do not tamper with MMU mapping tables. It's a system design choice.
Giuliano
Giuliano Colla wrote 19 lines
Il 08/06/23 18:40, Martin Frb via fpc-devel ha scritto:
> It seems that on Cocoa an exe is by default relocatable.
> At least a basic test shows that dumping a stack at runtime for each
> run (no new compile) gives new addresses.
>
> Fpc 3.2.2
>
> Is there a way to turn this off? (some flag to pass to the linker?)
AFAIK there's no way. It's a feature deep in the way the OS handles
memory. In a multiprogramming environment any executable must be by
definition relocatable, because at each run it must fit in a free area
of memory. So the OS has two choices. Either the executable is not
relocatable, and you trick it by altering the Memory Management Unit
tables to map its virtual fixed addresses to any free memory area, or
you make it relocatable, loose a little time when loading to locate
it, and do not tamper with MMU mapping tables. It's a system design
choice.
Great... Yes, it is an important security feature. But a show stopper for people who need to debug.
https://forum.lazarus.freepascal.org/index.php/topic,63571.0.html
1) Afaik, FPC still can't resolve addresses with -gl (the line info unit, that produces nice dumps on other Platforms).
2) Users can't later resolve them either.
It seems that on Cocoa an exe is by default relocatable. At least a basic test shows that…
Martin Frb wrote 7 lines
It seems that on Cocoa an exe is by default relocatable.
At least a basic test shows that dumping a stack at runtime for each run
(no new compile) gives new addresses.
Fpc 3.2.2
Is there a way to turn this off? (some flag to pass to the linker?)
It's not called relocation, but address space layout randomization (ASLR). You can disable it by compiling/linking your binary with -k-no_pie
Alternatively, you can launch a program via posix_spawnp using a custom attribute to disable ASLR for just that invocation. See e.g. main.c at https://github.com/svlobanov/disable-aslr-on-mac
Jonas
Great... Yes, it is an important security feature. But a show stopper for people who need…
Martin Frb wrote1) Afaik, FPC still can't resolve addresses with -gl (the line info unit, that produces nice dumps on other Platforms).
FPC trunk can do it (provided you compile with -Xg)
Jonas
Great... Yes, it is an important security feature. But a show stopper for people who need…
Il 08/06/23 20:33, Martin Frb via fpc-devel ha scritto:
Show quoted text 9 lines
Great... Yes, it is an important security feature. But a show stopper
for people who need to debug.
https://forum.lazarus.freepascal.org/index.php/topic,63571.0.html
1) Afaik, FPC still can't resolve addresses with -gl (the line info
unit, that produces nice dumps on other Platforms).
2) Users can't later resolve them either.
I wasn't aware of the ASLR feature. But digging in my memory I remembered a similar crash issue. After digging in the scant information provided by the debugger it turned out that the problem was generated in the thread initialization code. As in the application involved I wasn't using threads, I just commented out the cthreads line in the uses clause, and the problem disappeared. I didn't investigate further.
Giuliano