proc: fix path to separate debug info

[uber42]

trafficstars

An incorrect path to separate files with debug information is generated: /usr/lib/debug/.build-id/.build-id/%s/%s.debug -> /usr/lib/debug/.build-id/%s/%s.debug

[aarzilli]

I think it's correct how it is. This is what gdb's documentation says:

For the “build ID” method, GDB looks in the .build-id subdirectory of each one of the global debug directories for a file named nn/nnnnnnnn.debug, where nn are the first 2 hex characters of the build ID bit string, and nnnnnnnn are the rest of the bit string.

We used to do this wrong but the backwards compatibility method is tried later, I think that's the one you want to change maybe:

	if debugFilePath == "" && len(bi.BuildID) > 2 {
		// Previous verrsions of delve looked for the build id in every debug info
		// directory that contained the build-id substring. This behavior deviates
		// from the ones specified by GDB but we keep it for backwards compatibility.
		find(func(dir string) bool { return strings.Contains(dir, "build-id") }, fmt.Sprintf(".build-id/%s/%s.debug", bi.BuildID[:2], bi.BuildID[2:]))
	}

[uber42]

But by default debugInfoDirectories contains (pkg/config/config.go:169):

c.DebugInfoDirectories = []string{"/usr/lib/debug/.build-id"}

Or are you suggesting that each user personally specifies the path in config.yml?

looks like in the pkg/proc/bininfo.go:1223.check() function we get the concatenation of /usr/lib/debug/.build-id and .build-id/%s/%s anyway?

Then potentialDebugFilePath == /usr/lib/debug/.build-id/.build-id/%s/%s ?

[aarzilli]

looks like in the pkg/proc/bininfo.go:1223.check() function we get the concatenation of /usr/lib/debug/.build-id and .build-id/%s/%s anyway?

Yes, I think the backwards compatibility path is wrong. We should probably also change the default value for the configuration.

[derekparker]

I think changing the default value (as @aarzilli ) mentioned is the better way to go. Only one change and we remove the stutter bug.

[aarzilli]

The backwards compatibility path needs to be changed either way, the change to the default value won't apply to already existing configuration files.

[derekparker]

The backwards compatibility path needs to be changed either way, the change to the default value won't apply to already existing configuration files.

Ack, that's right, we have to update that either way.

[derekparker]

Any updates on this?