Alessandro Arzilli

That code is pretty complicated, if you need help ask. > in theory one could do a similar hack as to load the GAddr on amd64 by allocating some memory...

The problem with this is that some program will behave differently if their stdout/stderr is not a tty. It is unfortunate that DAP was designed like this.

It isn't impossible but it requires extensive changes to the linker and so it probably won't happen anytime soon, if ever.

> How should I proceed with these issues from DeepSource? Ignore them if it's not something you added. > Is there a way to re-trigger the Travis CI tests? No,...

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...

> 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 backwards compatibility path needs to be changed either way, the change to the default value won't apply to already existing configuration files.

Reproducer: ``` $ ulimit -v 1000000 $ dlv version ``` This is because of https://github.com/google/starlark-go/blob/master/starlark/int_posix64.go

I agree that the disassembler could and should be split, and also that 'pkg/proc' is a bad name for what's going on inside 'pkg/proc'. I'd also suggest that the loclist...

> think your assessment is spot on and I think this discussion has lead to the idea that maybe instead of moving logic to service/debugger perhaps we have a new...