Skip to content

Commit 32dd5b2

Browse files
authored
Work around a bug in the interaction between newer dyld's and older simulator dyld's (llvm#78004)
There's a bad interaction between the macOS 14 dyld and the "dyld_sim" shim that comes from older (iOS 15) simulator downloads that results in dyld reporting some modules twice in the return from the dyld callback to list modules. The records were identical, but lldb wasn't happy with seeing the duplicates... Since it's not possible to load two different modules at the same address, this change just picks the first instance of any entries that have the same load address. There really isn't a good way to test this patch.
1 parent 070738b commit 32dd5b2

File tree

1 file changed

+8
-0
lines changed

1 file changed

+8
-0
lines changed

lldb/tools/debugserver/source/MacOSX/MachProcess.mm

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -33,6 +33,7 @@
3333
#include <algorithm>
3434
#include <chrono>
3535
#include <map>
36+
#include <unordered_set>
3637

3738
#include <TargetConditionals.h>
3839
#import <Foundation/Foundation.h>
@@ -1053,9 +1054,16 @@ static bool mach_header_validity_test(uint32_t magic, uint32_t cputype) {
10531054
dyld_process_info info =
10541055
m_dyld_process_info_create(m_task.TaskPort(), 0, &kern_ret);
10551056
if (info) {
1057+
// There's a bug in the interaction between dyld and older dyld_sim's
1058+
// (e.g. from the iOS 15 simulator) that causes dyld to report the same
1059+
// binary twice. We use this set to eliminate the duplicates.
1060+
__block std::unordered_set<uint64_t> seen_header_addrs;
10561061
m_dyld_process_info_for_each_image(
10571062
info,
10581063
^(uint64_t mach_header_addr, const uuid_t uuid, const char *path) {
1064+
auto res_pair = seen_header_addrs.insert(mach_header_addr);
1065+
if (!res_pair.second)
1066+
return;
10591067
struct binary_image_information image;
10601068
image.filename = path;
10611069
uuid_copy(image.macho_info.uuid, uuid);

0 commit comments

Comments
 (0)