https://bugs.kde.org/show_bug.cgi?id=517304
Bug ID: 517304
Summary: Apple pointer wrong on macOS 12
Classification: Developer tools
Product: valgrind
Version First 3.27 GIT
Reported In:
Platform: Other
OS: macOS
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
I thought that this was just an out-by-one (or more likely 2) error in the
Darwin stack construction. But no.
The test none/tests/darwin/apple-main-arg fails because of this.
Here's what I understand of the Darwin flow.
1. I'm not sure if the initial stack is specified in macho as __UNIXSTACK or
whether it is based on rlimit. Either way the stack doesn't get mapped like
FreeBSD Linux and Solaris (where we build a grow down stack). The Darwin stack
gets mapped all at once.
2. argv and envp are much like the other systems. Darwin doesn't have auxv, it
has the apple pointer instead. That's kind of like a smaller obfuscated
(nothing like elf_common.h with a list of the entries).
3. The kernel only passes argc and argv to dyld. It has to find env and the
apple pointers itself.
4. argc, argv envp and apple all get passed to main in registers.
I'm a bit shaky on how the stack gets allocated.
At present our support of the apple pointer is limited. On macOS 11 and 12 I've
printed out the contents, which look like
j 0 &apple[j] 0x7ffee8a7dc60 apple[j] executable_path=./apple-main-arg
j 1 &apple[j] 0x7ffee8a7dc68 apple[j]
j 2 &apple[j] 0x7ffee8a7dc70 apple[j]
j 3 &apple[j] 0x7ffee8a7dc78 apple[j]
j 4 &apple[j] 0x7ffee8a7dc80 apple[j] ptr_munge=
j 5 &apple[j] 0x7ffee8a7dc88 apple[j] main_stack=
j 6 &apple[j] 0x7ffee8a7dc90 apple[j] executable_file=0x1a01000004,0x1aa6fc
j 7 &apple[j] 0x7ffee8a7dc98 apple[j] dyld_file=0x1a01000004,0xfffffff000d892b
j 8 &apple[j] 0x7ffee8a7dca0 apple[j] th_port=
j 9 &apple[j] 0x7ffee8a7dca8 apple[j] (null)
At the moment we only create the executable_path entry.
I don't know what executable_file or dyld_file mean.
Three of the entries are empty strings. My understanding of these is that there
were variables there added by the kernel but dyld has processed them and
blanked them out.
One of them is stack_guard= which contains a random hex value that will set the
global variable __stack_chk_guard. The default value is 0. For the moment I
think that we should leave that alone.
A second one is subsystem_root_path=. I think that contains an alternative path
for system libraries, useful for emulation and debugging. Again, leave that one
alone.
Last one, executable_cdhash=. That looks like it is for code signing. Not sure
what we can do with that. Doesn't seem to pose a problem that it is missing.
Back to the problem. I'll try to keep it short. From what I've seen on macOS 12
the apple pointer should be obtained by findApple()
const char** KernelArgs::findApple() const
{
// envp array has nullptr at end, apple starts after that
const char** p = findEnvp();
while ( *p != nullptr )
++p;
++p;
return p;
}
That just walks over env until the ending NULL is found, steps one more slot
after that and returns the pointer.
What we are building on the stack seems to match that.
Traces running under Valgrind on macOS 12:
3 slots after envp
i 16 &envp[i] 0x1048c7c00 envp[i] (null)
i 17 &envp[i] 0x1048c7c08 envp[i] executable_path=./apple-main-arg
i 18 &envp[i] 0x1048c7c10 envp[i] (null)
apple 0x1048c7c18
That is wrong, 'apple' should be 2 slots lower at 0x1048c7c08 rather than
0x1048c7c10.
Debugging this is hard. dyld has no symbols. The code for dyld changed
completely between macOS 11 and 12 (dyld3 to dyld4). Which is probably why we
are having problems.
So far I have just 2 ideas.
Is it a problem to not have everything in the apple pointer area?
dyld can modify env and the apple pointer area. Is that confusing findApple()?
--
You are receiving this mail because:
You are watching all bug changes.
