When lldb is processing the first couple of binaries in a process launch, it needs to compute load addresses before the files' sections have been added to the TargetSectionList, so our normal mechanism is not sufficient. ObjectFileMachO::ParseSymtab() calls GetMachHeaderSection() to find that segment, then uses the difference between that segment and the LINKEDIT segment, plus the Mach-O header load address that we were given, to calculate the load address of LINKEDIT.
This scheme works until one of the binaries we're treating in this special way is in the shared cache. GetMachHeaderSection() explicitly looks for a segment at file offset 0, as a way of implying the __TEXT segment without hardcoding its name. In a file in the shared cache, it will have a non-zero file address. It's laudable that ParseSymtab already handles the offset calculation correctly for a non-zero file offset -- but it won't match a segment which is nonzero.
This patch adds a backup mechanism if we find no segment at file offset 0, to find the __TEXT segment and return that.
Outside of an environment where one of these very initial binaries are in the shared cache, this can't be reproduced. Individual Mach-O binaries have file __TEXT with a file offset of 0. I haven't thought of a way to construct a well formed Mach-O binary that behaves like this, outside of the shared cache binary blob.