- User Since
- Jun 4 2013, 6:02 AM (220 w, 5 h)
Wed, Aug 16
Tue, Aug 8
Fri, Jul 28
I looked at this briefly last week but I could not find a good fix in the amount of time I had left. This fixes the current test failure, but it does not fix the underlying bug, which is that we (sometimes?) set the compile unit offset for non-dwo, non-dsym DIEs as 0. This works fine if all compile units are regular dwarf as we have logic to locate the containing CU if the offset is zero. However, it can fail in case of mixed dwarf and dwo compile units. My guess is you could still reproduce this bug with a so file that has a dwo compile unit at offset zero.
I am not able to test this right now. Eugene, can you take a look?
Jul 21 2017
Jul 20 2017
In this case, neither of the files has a build id/UUID. However, the tricky part here is that in this case we "invent" a UUID by doing a checksum of the whole file. This is done to support the .gnu_debuglink https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html method of finding symbols. It works like this:
- if a file has a gnu_debuglink section, we set the UUID to the crc inside that section
- if a file does not have a gnu_debuglink section, we *assume* it will be used as a gnu_debuglink target, and also set the UUID to the crc we compute from the whole file contents.
This works fine for the gnu_debuglink case, as then the rest of the machinery will match the files based on their UUIDs. However, it does not work for the general case without the debug link, as then the files will end up with two different "UUID"s (because they are based on the file content), and everything will consider them as different.
Jul 19 2017
@beanz: It looks like you're doing some debugserver work. :) Any thoughts on this?
Btw, will this work correctly if we are cross-debugging from a mac? (because then we will use the fancy DownloadObjectAndSymbolFile implementation)
I definitely agree we shouldn't crash if we see things we don't recognize, but I have no idea if it should be done this way. Greg should review this, as he's more familiar with the code.
The test looks well written. I've added a couple of suggestions you can consider including.
I think Jim (or maybe Greg?) should take a look at this.
Jul 18 2017
This is completely wrong. The --pipe argument is used to write the port that lldb-server listens on. Making --fd an alias to that will not help.
Jul 14 2017
I've tried that, and eventually decided against it, as it would create an uncomfortable mutual recursion between SetArchitecture and SetExecutableModule.
The version with a container object for ArchSpec+Plugin combo
Jul 13 2017
Moving the plugin to Target and other minor fixups.
Jul 12 2017
Have you tried that this actually works? (It doesn't work for me)
Looks great, thanks for catching this.
The architecture plugin idea
It looks like this has ground to a halt, but it seems the consensus was to try the Architecture plugin idea. I'm going to hijack this revision to maintain context, and upload a new version implementing that.
Jul 11 2017
Use csignal instead of signal.h
Adding ed as freebsd owner.
Jul 10 2017
Jul 9 2017
Jul 7 2017
Remove unused include from auxvector.h
I would prefer the unique_lock idea also. Lamdas make the code look ugly.
Jul 6 2017
I am generally happy with this, just a couple of things I noticed below:
Jul 5 2017
Jul 4 2017
Jul 3 2017
remove extra pid check
Address review comments
+ed as freebsd owner
Adding eugene, as he wrote that piece of code. Seems reasonable at a first glance though.