Implement xfer:libraries-svr4:read packet

[aadsm]

Summary

This is the fourth patch to improve module loading in a series that started here (where I explain the motivation and solution): D62499

Implement the xfer:libraries-svr4 packet by adding a new function that generates the list and then in Handle_xfer I generate the XML for it. The XML is really simple so I'm just using string concatenation because I believe it's more readable than having to deal with a DOM api.

Concerns

• I'm not sure about the having the ELFLinkMap and the SharedLibraryInfo struct in there. I thought about creating a function or class outside of NativeProcessLinux so it could be reusable in other contexts but the core functions need to use ReadMemory so it was not convinent and I guess would have forced me to pass a lambda as a wrapper to ReadMemory. This would introduce more complexity to the code and I'm not sure if it would be worthwhile.

• On Handle_xfer function the backing buffer structure uses MemoryBuffers so I had to create one out of the StreamString response I generate with the XML. This kind of sucks because I'm copying all this data when I usually don't even need it. And if I do need it still sucks because I'm copying something that I just generated right there. I couldn't find a way to generate the XML into a MemoryBuffer (as it requires to know the size before hand) or use another structure that would make this easier. I've thought about changing the backing structure to StringRefs but that object doesn't really own the underlying "const char*" so I can't keep it without copying again. Any suggestions here? [After measuring more carefully this doesn't seem to be an issue. (<0.1ms)]

[aadsm]

Rebase

[aadsm]

Update with the correct commit...

[aadsm]

Address comments and add tests

[labath]

Regarding the test, I am wondering whether requiring the /proc/%d/maps and the linker rendezvous structure to match isn't too strict of a requirement. Dynamic linkers (and particularly android dynamic linkers) do a lot of crazy stuff, and trying to assert this invariant exposes us to all kinds of "optimizations" that the linkers do or may do in the future. I'm wondering if it wouldn't be better to just build an executable with one or two dependent libraries, and then just assert that their entries are present in the library list. However, I'm not completely sure on this, so I'd like to hear what you think about that..

[clayborg]

lldb/include/lldb/Host/common/NativeProcessProtocol.h

37–39

These seem very linux specific. Why do we need 3 addresses here? Seems like we should just need one. Or is this the structure of the "xfer:libraries-svr4:read" that is required to be returned? If so, maybe we rename "SharedLibraryInfo" to "SVR4ModuleInfo"?

40

Why is "main" important? Hopefully the dynamic linker can figure out what is what without needing to know this? Seems verify linux specific. Or is this "xfer:libraries-svr4:read" specific?

41

Why do we need this "next" member here? We get a list of these from:

virtual Status GetLoadedSharedLibraries(std::vector<SharedLibraryInfo> &library_list);

Seems like we shouldn't need this. Darwin based systems doesn't store the shared library list as a linked list. Hopefully not "xfer:libraries-svr4:read" specific?

lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp

2191

Use ReadCStringFromMemory?

2247

Seems this we are using "info.next" just because it is a linked list on linux. Can we remove "next" and just add an extra "next" reference parameter to ReadSharedLibraryInfo<T>(link_map, info, next);?

[aadsm]

@labath

Regarding the test, I am wondering whether requiring the /proc/%d/maps and the linker rendezvous structure to match isn't too strict of a requirement. Dynamic linkers (and particularly android dynamic linkers) do a lot of crazy stuff, and trying to assert this invariant exposes us to all kinds of "optimizations" that the linkers do or may do in the future. I'm wondering if it wouldn't be better to just build an executable with one or two dependent libraries, and then just assert that their entries are present in the library list. However, I'm not completely sure on this, so I'd like to hear what you think about that..

Yeah, that was actually my first idea for the test but then realized we already had that main.c all set up and ready to use so I decide to use proc maps instead. I was not aware that things like that could happen (although I had a suspicion this might be brittle) so let me revisit this.

lldb/include/lldb/Host/common/NativeProcessProtocol.h

37–39

Yes, that is a good point and yes this is the data the SVR4 returns. Given this structure it makes more sense to move this into the NativeProcessLinux instead and name it more specifically.

40

It is packet specific yes. And I just realized I'm not putting that info in the XML I'm returning, will update.

lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp

2191

ReadCStringFromMemory doesn't exist here yet. That's on the next diff of this stack of diffs.

2247

Yes, this is the only reason, sounds good.

[aadsm]

lldb/include/lldb/Host/common/NativeProcessProtocol.h

37–39

Now that I think more about this, SVR4 is really generic to all system v implementations (4.0) so it's not linux specific. Will just change the name to more accurately reflect what is means.

[aadsm]

Address comments except the one about a different test plan.
Also removed the main property, after searching on the internet I'm not confident with the way I was using to detect the main executable. Since the "lm-main" is an optional attribute I'm not going to implement it now.
However, I'm excluding from the list the libraries without name or that are at base addr == 0. They shouldn't be there by the spec.

[labath]

In D62502#1528382, @aadsm wrote:

@labath

Regarding the test, I am wondering whether requiring the /proc/%d/maps and the linker rendezvous structure to match isn't too strict of a requirement. Dynamic linkers (and particularly android dynamic linkers) do a lot of crazy stuff, and trying to assert this invariant exposes us to all kinds of "optimizations" that the linkers do or may do in the future. I'm wondering if it wouldn't be better to just build an executable with one or two dependent libraries, and then just assert that their entries are present in the library list. However, I'm not completely sure on this, so I'd like to hear what you think about that..

Yeah, that was actually my first idea for the test but then realized we already had that main.c all set up and ready to use so I decide to use proc maps instead. I was not aware that things like that could happen (although I had a suspicion this might be brittle) so let me revisit this.

I'm not sure whether it will be brittle, but I do know that the android linker does (or used to do?) some tricks where it does not really load libdl.so, but instead inserts a fake entry into the link map which pretends to implement that library (but in reality the entry points to the linker itself). That sounds like the kind of thing that could break if you try to correlate the linker data with /proc/%d/maps.

So, I think it would be better to create a separate test binary for this, particularly as it seems some tests with funny library names will be interesting too... Note that when you're creating a special-purpose executable, you don't have to do the whole wait-for-inferior-to-print-something-and-then-send-CTRL-C dance. You can just have the inferior dereference a null pointer (or something of the sort) to force a stop once it has loaded the necessary shared libraries.

lldb/include/lldb/Host/common/NativeProcessProtocol.h

98–101

This should return an Expected<std::vector<...>>

lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteLibrariesSvr4Support.py

52–53

Why are these all caps? TBH, you probably don't need to make these variables at all. You can just place them directly into the packet as strings.

lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp

2181

This too could return an llvm::Error. Expected<std::pair<SVR4LibraryInfo, addr_t>> is a bit of a mouthful, but I'd consider that instead of by-ref returns too..

2197

What if name_buffer is not null-terminated?

lldb/source/Plugins/Process/Linux/NativeProcessLinux.h

140–146

It looks like this doesn't need to be in a header. You could just define the struct inside ReadSVR4LibraryInfo

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp

2768

Now that we have removed ifdefs around the auxv, we should do that here too..

2778

You're completely ignoring escaping here, which is a pretty complex topic, and one of the reasons why constructing this via the DOM api is so complicated. There are a couple of considerations here:

• ", &, and other special xml characters: these will definitely need to be xml-escaped properly
• non-7-bit characters: how these will come out depends on whether the client&server agree on the encoding used. I'm not sure what's the best thing to do here
• low ascii (nonprintable) characters: it looks like these cannot be represented in xml (1.0) at all (?)

It might be good to check what gdb does in these situations

[aadsm]

lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteLibrariesSvr4Support.py

52–53

tbh I mostly copy pasted the auxv test :D but yeah it can be made simpler.

lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp

2197

Nicely spotted. I should add the size but this made me realize I'm not ensuring a \0 on my next diff where I implement ReadCStringFromMemory.

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp

2778

Oh yeah, this is a path so of course that will happen. (we probably should update ds2 for that as well).

[aadsm]

• Improved the tests by using a binary that is specificly linked to other shared libs.
• USe libxml2 to generate the name attribute (I've talked with Greg about this and he recommended to create a new class for this)
• Address other comments

[aadsm]

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp

2778

gdb manually escapes < > " and & into their respective &code; but doesn't seem to handle characters like \r, etc.

[labath]

Using the libxml function for the escaping is fine, but there are a couple of caveats. I believe people expect to be able to build lldb without libxml. At least that what all the existing xml-related code assumes (you'll see it has some #ifdefs and stuff). If we don't intend to change that, then we'll need to do something similar here. It's fine if some features (like this one) don't work without libxml, but they should degrade gracefully.

The svr reading support in the client depends on having libxml around, so depending on it here would be consistent. OTOH, lldb-server is used also in embedded(ish) environments where libxml is hard to come by (or just big), so it may make sense to try to avoid it here (particularly as you're still constructing the xml elements by hand).

So overall, it's up to you how you want to proceed here. However, if you do use libxml, I think you'll need to do something like:

• make sure the changes in XML.h compile without libxml (move stuff into an ifdef, provide a no-op implementation for the other case, and similar)
• only say we support the svr extension if XMLDocument::XMLEnabled() is true
• guard the tests with @skipIfXmlSupportMissing

[aadsm]

No longer depend on libxml2 to quote the attribute value

[aadsm]

@labath that's a really good point. I've talked with @clayborg and @xiaobai about this and we decided it would be fine to do it manually as well so I added a XMLEncodeAttributeValue function to make it happen. I'm not 100% sure about its implementation.. Should I use a StreamString instead?

[labath]

In D62502#1533490, @aadsm wrote:

@labath that's a really good point. I've talked with @clayborg and @xiaobai about this and we decided it would be fine to do it manually as well so I added a XMLEncodeAttributeValue function to make it happen. I'm not 100% sure about its implementation.. Should I use a StreamString instead?

The implementation is fine, just make it take a StringRef instead of a char pointer.

The thing I'm not sure about is the location, as now this is the only function in XML.h that actually works without libxml support. Given that this is something we don't want to advertise too broadly, maybe you could just make it a static function GDBRemoteCommunicationServerLLGS? If this trick stays limited to lldb-server (which I think it should), then that could even be the right place for it.

[aadsm]

Move XMLEncodeAttributeValue to GDBRemoteCommunicationServerLLGS.

[aadsm]

Sounds good, I put it there initially because the XML.cpp set of classes abstract the libxml2 specific away but I guess it is odd to have XMLDocument::XMLEnabled() returning false and still be able to call that new function.

[labath]

This looks mostly good. The thing I'm wondering about is whether this part of the code is really linux specific (in which case we should rename ELFLinkMap into LinuxLinkMap), or if it can be useful on other platforms (in which case this should go into the newly-created NativeProcessELF). @mgorny , @krytarowski, what do you think?

lldb/packages/Python/lldbsuite/test/tools/lldb-server/libraries-svr4/TestGdbRemoteLibrariesSvr4Support.py

21–29 ↗

(On Diff #203656)

This countinue-and-immediatelly-interrupt sequence seems very dodgy. What's the purpose of that? Given that the inferior forces a break with the null dereference, I would expect you don't need to send any interrupt packets here, just simply wait for the inferior to stop.

lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp

2181

What about that llvm::Error?

[krytarowski]

https://nxr.netbsd.org/xref/src/include/link_elf.h#9

In general this code should be close to functional on NetBSD (if not already compatible).

[aadsm]

It's the same for freebsd https://github.com/freebsd/freebsd/blob/master/sys/kern/link_elf.c#L291 although behind a GDB flag (which NetBSD doesn't seem to be: https://nxr.netbsd.org/xref/src/libexec/ld.elf_so/rtld.c#1040).

lldb/packages/Python/lldbsuite/test/tools/lldb-server/libraries-svr4/TestGdbRemoteLibrariesSvr4Support.py

21–29 ↗

(On Diff #203656)

ah yeah, it will stop already on the sigsev.

[aadsm]

lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp

2181

oops sorry, missed this one. I do my best to check if I addressed all the comments but sometimes I miss some :(.

[aadsm]

• Update test to just wait for the process to stop
• Change ReadSVR4LibraryInfo signature to return an Expected to the list of libraries and stop taking params by ref.

[labath]

Ok, so given that both NetBSD and FreeBSD implement this feature (and the current DynamicLoaderPOSIXDYLD plugin reads it), I think we should move this bit of code into NativeProcessELF -- after all, that's what we've created it for.

[aadsm]

Yeah, that makes sense. I was thinking about this yesterday after checking the freebsd code. I was concerned if there's something different that I'm not aware of but we do have tests and I guess we can also override these functions if needed in the future.

[aadsm]

• Move SVR4 reading to NativeProcessELF
• Made NetBSD and FreeBSD process implementations extend NativeProcessELF

I'm not 100% confident on this last one because I don't have a net and free bsd to test on, and I find it suspicious that the auxv packet is only enabled for linux and netbsd...

[labath]

LGTM, with the following comment taken into account.

The ProcessFreeBSD parts are definitely wrong, as ProcessFreeBSD does not use lldb-server yet (it uses local only path). Just revert that part.

As for NetBSD, doing that might be fine, but I'd also be fine with leaving it up to the netbsd maintainers to enable this feature (by inheriting from NativeProcessELF). In other words, my request was only to make it *possible* for free/netbsd to use this code (by putting it into NativeProcessELF). I didn't mean they have to start using it *right now*.

[krytarowski]

I would leave the NetBSD version as it is in this patch and let us to fix/test it later.

[aadsm]

Only extend support to NetBSD

[labath]

As I kind of expected, one of these tests was flaky because the names for the vdso pseudo-module were not adding up. When reading from /proc/%pid/maps, we got "[vdso]" (as that's how the kernel likes to call this page), but while reading the linker rendezvous structure, we got "linux-vdso.so.1" (I guess that's the SONAME of the module or something).

I "fixed" this in r363772, by restricting this test to only check the libraries that we ourselves have linked into the process.

[jankratochvil]

Even after @labath's rL363772 the testcase TestGdbRemoteLibrariesSvr4Support is still FAILing on Fedora 30 x86_64, I will check it more later.

lldb/include/lldb/Host/common/NativeProcessProtocol.h

 #include <mutex>
 #include <unordered_map>
 #include <vector>
 
 namespace lldb_private {
 class MemoryRegionInfo;
 class ResumeActionList;
 
+struct SharedLibraryInfo {
+  std::string name;
+  lldb::addr_t link_map;
+  lldb::addr_t base_addr;
+  lldb::addr_t ld_addr;
+  bool main;
+  lldb::addr_t next;
+};
+
 // NativeProcessProtocol
 class NativeProcessProtocol {
 public:
   virtual ~NativeProcessProtocol() {}
 
   virtual Status Resume(const ResumeActionList &resume_actions) = 0;
 
   virtual Status Halt() = 0;
public:
 
   virtual Status AllocateMemory(size_t size, uint32_t permissions,
                                 lldb::addr_t &addr) = 0;
 
   virtual Status DeallocateMemory(lldb::addr_t addr) = 0;
 
   virtual lldb::addr_t GetSharedLibraryInfoAddress() = 0;
 
+  virtual Status
+  GetLoadedSharedLibraries(std::vector<SharedLibraryInfo> &library_list) {
+    return Status("Not implemented");
+  }
+
   virtual bool IsAlive() const;
 
   virtual size_t UpdateThreads() = 0;
 
   virtual const ArchSpec &GetArchitecture() const = 0;
 
   // Breakpoint functions
   virtual Status SetBreakpoint(lldb::addr_t addr, uint32_t size,

lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteLibrariesSvr4Support.py

+import xml.etree.ElementTree as ET
+
+import gdbremote_testcase
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TestGdbRemoteLibrariesSvr4Support(gdbremote_testcase.GdbRemoteTestCaseBase):
+
+    mydir = TestBase.compute_mydir(__file__)
+
+    FEATURE_NAME = "qXfer:libraries-svr4:read"
+
+    def has_libraries_svr4_support(self):
+        inferior_args = ["message:main entered", "sleep:5"]
+        # inferior_args = [ "sleep:500"]
+        procs = self.prep_debug_monitor_and_inferior(inferior_args=inferior_args)
+
+        # Don't do anything until we match the launched inferior main entry output.
+        # Then immediately interrupt the process.
+        # This prevents libraries-svr4 data being asked for before it's ready and leaves
+        # us in a stopped state.
+        self.test_sequence.add_log_lines(
+            [
+                # Start the inferior...
+                "read packet: $c#63",
+                # ... match output....
+                {
+                    "type": "output_match",
+                    "regex": self.maybe_strict_output_regex(
+                        r"message:main entered\r\n"
+                    ),
+                },
+            ],
+            True,
+        )
+        # ... then interrupt.
+        self.add_interrupt_packets()
+        self.add_qSupported_packets()
+
+        context = self.expect_gdbremote_sequence()
+        self.assertIsNotNone(context)
+        features = self.parse_qSupported_response(context)
+        return self.FEATURE_NAME in features and features[self.FEATURE_NAME] == "+"
+
+    def get_libraries_svr4_data(self):
+        # Start up llgs and inferior, and check for libraries-svr4 support.
+        if not self.has_libraries_svr4_support():
+            self.skipTest("libraries-svr4 not supported")
+
+        OFFSET = 0
+        LENGTH = 0xFFFF
+
+        # Grab the libraries-svr4 data.
+        self.reset_test_sequence()
+        self.test_sequence.add_log_lines(
+            [
+                "read packet: $qXfer:libraries-svr4:read::{:x},{:x}:#00".format(
+                    OFFSET, LENGTH
+                ),
+                {
+                    "direction": "send",
+                    "regex": re.compile(
+                        r"^\$([^E])(.*)#[0-9a-fA-F]{2}$", re.MULTILINE | re.DOTALL
+                    ),
+                    "capture": {1: "response_type", 2: "content_raw"},
+                },
+            ],
+            True,
+        )
+
+        context = self.expect_gdbremote_sequence()
+        self.assertIsNotNone(context)
+
+        # Ensure we end up with all libraries-svr4 data in one packet.
+        self.assertEqual(context.get("response_type"), "l")
+
+        # Decode binary data.
+        content_raw = context.get("content_raw")
+        self.assertIsNotNone(content_raw)
+        return content_raw
+
+    def get_libraries_svr4_xml(self):
+        libraries_svr4 = self.get_libraries_svr4_data()
+        xml_root = None
+        try:
+            xml_root = ET.fromstring(libraries_svr4)
+        except xml.etree.ElementTree.ParseError:
+            pass
+        self.assertIsNotNone(xml_root, "Malformed libraries-svr4 XML")
+        return xml_root
+
+    def libraries_svr4_well_formed(self):
+        xml_root = self.get_libraries_svr4_xml()
+        self.assertEqual(xml_root.tag, "library-list-svr4")
+        for child in xml_root:
+            self.assertEqual(child.tag, "library")
+            self.assertItemsEqual(child.attrib.keys(), ["name", "lm", "l_addr", "l_ld"])
+
+    def libraries_svr4_has_correct_load_addr(self):
+        xml_root = self.get_libraries_svr4_xml()
+        for child in xml_root:
+            name = child.attrib.get("name")
+            if not name:
+                continue
+            load_addr = int(child.attrib.get("l_addr"), 16)
+            self.reset_test_sequence()
+            self.add_query_memory_region_packets(load_addr)
+            context = self.expect_gdbremote_sequence()
+            mem_region = self.parse_memory_region_packet(context)
+            self.assertEqual(load_addr, int(mem_region.get("start", 0), 16))
+            self.assertEqual(
+                os.path.realpath(name), os.path.realpath(mem_region.get("name", ""))
+            )
+
+    def get_pid(self):
+        self.reset_test_sequence()
+        self.add_process_info_collection_packets()
+        context = self.expect_gdbremote_sequence()
+        self.assertIsNotNone(context)
+        process_info = self.parse_process_info_response(context)
+        return int(process_info.get("pid"), 16)
+
+    def get_mapped_libs(self):
+        libs = []
+        exe_name = self.getBuildArtifact("a.out")
+        with open("/proc/{pid}/maps".format(pid=self.get_pid()), "r") as file:
+            for line in file:
+                lib = line.split()
+                if len(lib) < 6:
+                    continue
+                name = lib[5]
+                if exe_name == name or not os.path.exists(name) or name in libs:
+                    continue
+                libs.append(name)
+        return libs
+
+    def libraries_svr4_all_present(self):
+        xml_root = self.get_libraries_svr4_xml()
+        libraries_svr4_names = []
+        for child in xml_root:
+            name = child.attrib.get("name")
+            if not name:
+                continue
+            libraries_svr4_names.append(os.path.realpath(name))
+        libs = self.get_mapped_libs()
+        self.assertItemsEqual(libraries_svr4_names, libs)
+
+    @llgs_test
+    @skipUnlessPlatform(["linux", "android"])
+    def test_supports_libraries_svr4(self):
+        self.init_llgs_test()
+        self.build()
+        self.set_inferior_startup_launch()
+        self.assertTrue(self.has_libraries_svr4_support())
+
+    @llgs_test
+    @skipUnlessPlatform(["linux", "android"])
+    def test_libraries_svr4_well_formed(self):
+        self.init_llgs_test()
+        self.build()
+        self.set_inferior_startup_launch()
+        self.libraries_svr4_well_formed()
+
+    @llgs_test
+    @skipUnlessPlatform(["linux", "android"])
+    def test_libraries_svr4_load_addr(self):
+        self.init_llgs_test()
+        self.build()
+        self.set_inferior_startup_launch()
+        self.libraries_svr4_has_correct_load_addr()
+
+    @llgs_test
+    @skipUnlessPlatform(["linux", "android"])
+    def test_libraries_svr4_all_present(self):
+        self.init_llgs_test()
+        self.build()
+        self.set_inferior_startup_launch()
+        self.libraries_svr4_all_present()

lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py

def parse_memory_region_packet(self, context):
                 key in [
                     "start",
                     "size",
                     "permissions",
                     "name",
                     "error"])
             self.assertIsNotNone(val)
 
+        mem_region_dict["name"] = seven.unhexlify(mem_region_dict.get("name", ""))
         # Return the dictionary of key-value pairs for the memory region.
         return mem_region_dict
 
     def assert_address_within_memory_region(
             self, test_address, mem_region_dict):
         self.assertIsNotNone(mem_region_dict)
         self.assertTrue("start" in mem_region_dict)
         self.assertTrue("size" in mem_region_dict)

lldb/source/Plugins/Process/Linux/NativeProcessLinux.h

public:
 
   Status AllocateMemory(size_t size, uint32_t permissions,
                         lldb::addr_t &addr) override;
 
   Status DeallocateMemory(lldb::addr_t addr) override;
 
   lldb::addr_t GetSharedLibraryInfoAddress() override;
 
+  Status GetLoadedSharedLibraries(
+      std::vector<SharedLibraryInfo> &library_list) override;
+
   size_t UpdateThreads() override;
 
   const ArchSpec &GetArchitecture() const override { return m_arch; }
 
   Status SetBreakpoint(lldb::addr_t addr, uint32_t size,
                        bool hardware) override;
 
   Status RemoveBreakpoint(lldb::addr_t addr, bool hardware = false) override;
public:
   bool SupportHardwareSingleStepping() const;
 
 protected:
   llvm::Expected<llvm::ArrayRef<uint8_t>>
   GetSoftwareBreakpointTrapOpcode(size_t size_hint) override;
   template <typename ELF_EHDR, typename ELF_PHDR, typename ELF_DYN>
   lldb::addr_t GetELFImageInfoAddress();
 
+  template <typename T> struct ELFLinkMap {
+    T l_addr;
+    T l_name;
+    T l_ld;
+    T l_next;
+    T l_prev;
+  };
+  template <typename T>
+  Status ReadSharedLibraryInfo(lldb::addr_t link_map_addr,
+                               SharedLibraryInfo &info);
+
 private:
   MainLoop::SignalHandleUP m_sigchld_handle;
   ArchSpec m_arch;
   std::unique_ptr<AuxVector> m_aux_vector;
   lldb::addr_t m_elf_image_info_addr = LLDB_INVALID_ADDRESS;
 
   LazyBool m_supports_mem_region = eLazyBoolCalculate;
   std::vector<std::pair<MemoryRegionInfo, FileSpec>> m_mem_region_cache;

lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp

if (dynamic_entry.d_tag == llvm::ELF::DT_DEBUG) {
       m_elf_image_info_addr = dynamic_section_addr + i * sizeof(dynamic_entry) +
                               sizeof(dynamic_entry.d_tag);
       return m_elf_image_info_addr;
     }
   }
 
   return LLDB_INVALID_ADDRESS;
 }
+
+template <typename T>
+Status NativeProcessLinux::ReadSharedLibraryInfo(lldb::addr_t link_map_addr,
+                                                 SharedLibraryInfo &info) {
+  ELFLinkMap<T> link_map;
+  size_t bytes_read;
+  auto error =
+      ReadMemory(link_map_addr, &link_map, sizeof(link_map), bytes_read);
+  if (!error.Success())
+    return error;
+
+  char name_buffer[PATH_MAX];
+  error = ReadMemory(link_map.l_name, &name_buffer, sizeof(name_buffer),
+                     bytes_read);
+  if (!error.Success())
+    return error;
+
+  info.name = std::string(name_buffer);
+  info.link_map = link_map_addr;
+  info.base_addr = link_map.l_addr;
+  info.ld_addr = link_map.l_ld;
+  info.next = link_map.l_next;
+#if defined(__linux__) && !defined(__ANDROID__)
+  // On non-android linux systems, main executable has an empty path.
+  info.main = info.name.empty();
+#elif defined(__linux__) && defined(__ANDROID__)
+  // On android, the main executable has a load address of 0.
+  info.main = info.ld_addr == 0;
+#else
+  info.main = false;
+#endif
+
+  return Status();
+}
+
+Status NativeProcessLinux::GetLoadedSharedLibraries(
+    std::vector<SharedLibraryInfo> &library_list) {
+  // Address of DT_DEBUG.d_ptr which points to r_debug
+  lldb::addr_t info_address = GetSharedLibraryInfoAddress();
+  if (info_address == LLDB_INVALID_ADDRESS)
+    return Status("Invalid shared library info address");
+  // Address of r_debug
+  lldb::addr_t address = 0;
+  size_t bytes_read;
+  auto error =
+      ReadMemory(info_address, &address, GetAddressByteSize(), bytes_read);
+  if (!error.Success())
+    return error;
+  if (address == 0)
+    return Status("Invalid r_debug address");
+  // Read r_debug.r_map
+  lldb::addr_t link_map = 0;
+  error = ReadMemory(address + GetAddressByteSize(), &link_map,
+                     GetAddressByteSize(), bytes_read);
+  if (!error.Success())
+    return error;
+  if (address == 0)
+    return Status("Invalid link_map address");
+
+  while (link_map) {
+    SharedLibraryInfo info;
+    if (GetAddressByteSize() == 8)
+      error = ReadSharedLibraryInfo<uint64_t>(link_map, info);
+    else
+      error = ReadSharedLibraryInfo<uint32_t>(link_map, info);
+    if (!error.Success())
+      return error;
+    library_list.push_back(info);
+    link_map = info.next;
+  }
+
+  return Status();
+}

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerCommon.cpp

GDBRemoteCommunicationServerCommon::Handle_qSupported(
   response.PutCString(";QStartNoAckMode+");
   response.PutCString(";QThreadSuffixSupported+");
   response.PutCString(";QListThreadsInStopReply+");
   response.PutCString(";qEcho+");
 #if defined(__linux__) || defined(__NetBSD__)
   response.PutCString(";QPassSignals+");
   response.PutCString(";qXfer:auxv:read+");
 #endif
+#if defined(__linux__)
+  response.PutCString(";qXfer:libraries-svr4:read+");
+#endif
 
   return SendPacketNoLock(response.GetString());
 }
 
 GDBRemoteCommunication::PacketResult
 GDBRemoteCommunicationServerCommon::Handle_QThreadSuffixSupported(
     StringExtractorGDBRemote &packet) {
   m_thread_suffix_supported = true;

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp

if (object == "auxv") {
 
     // Grab the auxv data.
     auto buffer_or_error = m_debugged_process_up->GetAuxvData();
     if (!buffer_or_error)
       return llvm::errorCodeToError(buffer_or_error.getError());
     return std::move(*buffer_or_error);
   }
 
+#if defined(__linux__)
+  if (object == "libraries-svr4") {
+    std::vector<SharedLibraryInfo> library_list;
+    auto status = m_debugged_process_up->GetLoadedSharedLibraries(library_list);
+    if (!status.Success())
+      return status.ToError();
+
+    StreamString response;
+    response.Printf("<library-list-svr4 version=\"1.0\">");
+    for (auto const &library : library_list) {
+      response.Printf("<library name=\"%s\" ", library.name.c_str());
+      response.Printf("lm=\"0x%" PRIx64 "\" ", library.link_map);
+      response.Printf("l_addr=\"0x%" PRIx64 "\" ", library.base_addr);
+      response.Printf("l_ld=\"0x%" PRIx64 "\" />", library.ld_addr);
+    }
+    response.Printf("</library-list-svr4>");
+    return std::move(
+        MemoryBuffer::getMemBufferCopy(response.GetString(), __FUNCTION__));
+  }
+#endif
+
   return llvm::make_error<PacketUnimplementedError>(
       "Xfer object not supported");
 }
 
 GDBRemoteCommunication::PacketResult
 GDBRemoteCommunicationServerLLGS::Handle_qXfer(
     StringExtractorGDBRemote &packet) {
   SmallVector<StringRef, 5> fields;