Remove unused copy-pasted class method declarations.

Removed unused REG_CONTEXT_SIZE.

Is there a specific reason you've only covered x0..x7 in the test?

You seem to be removing more than adding there.

Change the patch to remove the hack entirely.

I can confirm that it builds fine without that block and that there are no changes in CMakeCache.txt.

Trying to add people responsible for the DragonFly part.

In D94491#2492663, @arichardson wrote:

What happens if you just drop this block unconditionally?

I suppose this has waited long enough to deserve another test run.

Fixed FPR writing bug, updated tests and removed anonymous namespace.

Made sources conditional to platform via CMake. If this is good, I'll update FreeBSD afterwards.

Compare using weak_ptr to the interpreter module.

In D92187#2450976, @labath wrote:

In D92187#2450526, @mgorny wrote:

Another fix: we should only unload duplicate ld.so if it's actually a duplicate, i.e. the path differs. Otherwise, we've ended up unloading the only copy.

Would comparing the module shared_pointers work? I think that's exactly what we want here. I think it's possible for LoadModuleAtAddress to return the same module, even with paths which don't match exactly. But if it does that, then we will still end up unloading the original interpreter module...

Another fix: we should only unload duplicate ld.so if it's actually a duplicate, i.e. the path differs. Otherwise, we've ended up unloading the only copy.

Updated to unload duplicate ld.so as suggested by @labath.

Avoid adding duplicate entry for ld-linux.

One possible hackaround would be to do this only if 1st breakpoint hit is consistent (vs add on Linux), or just make the whole logic #if defined(__FreeBSD__).

Actually, I can still reproduce the double symbol problem with Arch's ld-2.32.so. I can't figure out what's wrong.

In D92872#2440764, @JDevlieghere wrote:

Nice!

Currently we have the lldb man page listed under "Reference" on the website. Do you think it would be worth creating a separate section for the man pages with lldb and lldb-server listed there? I thinking about adding a man page for debugserver as well.

This is half-guesswork since platform command seems to be undocumented, so I'd appreciate any suggestions what I got wrong.

Updated to perform the logic inside DynamicLoaderPOSIXDYLD, without touching DYLDRendezvous. This is much safer, and does not cause the double-load of ld-linux.

This causes ld-linux to be added twice on Linux. I need to change the logic a bit.

Rewritten the test wrt comments, that is:

1. Added a breakpoint-continue to ensure that the program is past all initial work before we test it.
2. Print a global variable to test it.

In D92264#2436440, @labath wrote:

I am having second thoughts about the image list approach to testing this. The regex matching is somewhat messy.

A bad load address should manifest itself in plenty of other ways.. Could we print the value of some global variable to check that we got the correct one?

Added an explanatory comment.

In D92314#2422995, @emaste wrote:

No objection, but maybe add a comment explaining the status of this implementation? Does/will NetBSD do the same?

With D92667, I've finally found a way to reproduce this without running lldb-server explicitly — we need to spawn the program via relative path though. I've added a test that does that, and compares the address from image list with the one gotten after explicitly creating target via file path. This clearly reproduces the problem if you don't modify the sources (i.e. mismatch between 0x400000 and 0x200000).

In D85278#2434383, @thakis wrote:

From what I understand, linking lld as a shared library is an explicit non-goal of lld. It trusts inputs and crashes on bad inputs, since it's designed to be run as a separate process.

Can you say more about what you want this for? It seems like something we don't want to do.

In D92667#2434223, @emaste wrote:

No objection here. I'm curious why the two modified tests work on Linux or NetBSD today though?

Updated as discussed on IRC, to instead add libs returned by the first 'take snapshot' action.

@thakis, you seem to have been touching lld recently.

In D92187#2425378, @labath wrote:

In D92187#2425301, @mgorny wrote:

I've added some more debug as requested, and it confirmed that Linux and FreeBSD dyld are behaving differently here.

Linux triggers the breakpoint twice: first time in add state, including only /lib64/ld-linux-x86-64.so.2 and linux-vdso.so.1 in module list, and the second time in consistent state, adding soentries for all shared libraries.

FreeBSD triggers it only once, in consistent state and the remote list includes all libraries immediately

Thanks for investigating this. And I'm sorry for being so picky -- this is all very messy, and I am trying to understand things to avoid making an even bigger mess.

When you say "FreeBSD triggers it only once", which breakpoint are you referring to? The "rendezvous" breakpoint? Judging by the log's, I would say yes.

Full logs below.

I've added some more debug as requested, and it confirmed that Linux and FreeBSD dyld are behaving differently here.

GDB indeed handles it somehow. I'm going to investigate.

In D92264#2422199, @labath wrote:

Seems reasonable(ish), but needs a test case. Do you need to launch a separate server instance, or would just a plain attach work?

In D92187#2422085, @labath wrote:

What's the state of TestBreakpointInGlobalConstructor.py after this change? Does it continue to fail?

I was referring to:

I disagree. Since we're repeating gdb protocol, it would be nice to use offsets consistent with the gdb protocol, even if it means some extra padding. I do realize that this is broken right now and not trivially fixable but I don't think we should make things worse.

In D92063#2416162, @labath wrote:

+@mgorny, as he's been navigating these waters lately...

So... I presume we can't just slap __attribute__((packed)) on the structure, because the kernel actually expects that the data structure will have the extra space for the padding. Is that so?

Even if we can't, I'm wondering if it wouldn't be cleaner to use two structures for this. Something like:

LLVM_PACKED_START
struct GPR {
  // as before...
};
/// Big comment explaining the purpose of padding
struct GPRBuffer: GPR {
  uint32_t pad;
};
LLVM_PACKED_END

and then using GPR or GPRBuffer accordingly. What do you think?

Added system-debugserver feature to skip tests.

In D91847#2410564, @labath wrote:

Still looks good to me. :) Jason, do you have any concerns?

Unfortunately, we still need a @skipIfOutOfTreeDebugserver equivalent....

Rebase and fix TestRegisters.