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.

I'll also add a TODO here wrt unsupported registers.

Ok, will add the comment and push.

Curious enough, I can't reproduce this failure.

Added aliases to all regsets, not just the first ones. Updated test status.

Updated to pass can_debug parameter, as suggested by @labath.

Skipped python test on non-Darwin, xfailed shell test on Darwin, added respective comments.

In D91504#2407397, @labath wrote:

Well... I think that will make the test fail on mac, as debugserver hasn't been updated.

This test comes from D12592, and is actually serves a very similar purpose to the test you just wrote. Normally, I would say we don't need both of them, but since we still have debugserver with the old behavior, and your new test is consistent with how we've (you've) been writing other register tests, maybe we could just slap @skipUnlessDarwin on TestRegisters.py, and put some comments (on both tests) that explain the situation and cross-reference each other (?)

In D91810#2407461, @labath wrote:

I think that the real fix here would be to change the plugin selection logic (Target::CreateProcess) to convey the fact that we're looking for a connectable plugin. The method already contains a FileSpec *core_file argument, which I guess is needed to select the proper core file subclass, so adding a can_connect argument would not be unreasonable (though not exactly pretty either).

Does this change to TestRegister.py look good? It makes the test pass for me (and seems logically correct).

Update TestRegisters.py.

In D91504#2405504, @goncharov wrote:

Hi @mgorny! http://lab.llvm.org:8011/#/builders/68/builds/2298 build failed. Could you please fix the test?

Updated to cover i386, reformatted the macro.

Declare MMSRegComp type explicitly to avoid warnings:

Simplified FreeBSD & Linux code as @labath suggested. Also added the scope thingy to tests.

@labath, what do you think about this approach? What really sucks is that we have to repeat the whole voodoo for i386 and amd64 separately.

Added contained/invalidate entries for FIP/FDP.

Updated Linux to use pointer comparison and FreeBSD. It's ready for review now, though I'd use a better suggestion for FreeBSD.

In D91461#2402833, @serge-sans-paille wrote:

In D91461#2402720, @mgorny wrote:

Or to put it the other way, LINK_COMPONENTS is not equivalent to target_link_libraries with the PUBLIC keyword.

Do you think we should revert the whole patch, or only a subpart of it?

Or to put it the other way, LINK_COMPONENTS is not equivalent to target_link_libraries with the PUBLIC keyword.

This broke building LLDB with BUILD_SHARED_LIBS=ON:

Updated the test comment.

Port NetBSD plugin.

Move the functions into a new file, add comment, use llvm::ArrayRef.

Fix wrong output num ($2 instead of $1) in x86-fp-read.test.

Implemented requested changes. Clang-formatted. Extended fp-write tests to cover both writing fioff/fooff and fip/fdp.

I'll port to other platforms once we agree on the approach.