gdb: configure with stdenv.cc.cc.lib safe path #73574

tmplt · 2019-11-17T17:58:44Z

Motivation for this change

$ cat > main.cpp
#include <vector>
int main()
{
    std::vector<int> v{0, 1, 2, 3};
}
$ g++ -g -O0 main.cpp
$ gdb ./a.out
(gdb) print v

Before:

$1 = {<std::_Vector_base<int, std::allocator<int> >> = {_M_impl = {<std::allocator<int>> = {<__gnu_cxx::new_allocator<int>> = {<No data fields>}, <No data fields>}, _M_start = 0x416e70, _M_finish = 0x416e80,
      _M_end_of_storage = 0x416e80}}, <No data fields>}

After:

$1 = std::vector of length 4, capacity 4 = {0, 1, 2, 3}

Things done

Notify maintainers

cc @globin

pkgs/top-level/all-packages.nix

veprbl · 2019-11-17T20:42:33Z

@tmplt Could you please rebase to staging?

tmplt · 2019-11-17T22:40:15Z

@veprbl done.

Pardon the review requests; forgot to change target branch before I pushed the rebase.

Ericson2314 · 2019-11-18T01:00:45Z

This seems good, but in general what are these safe plugins and where do they come from? I ask because long term I want to always use separate derivations for libgcc, libstdc++, etc, just as we do for compiler-rt and libc++, etc (#26004).

tmplt · 2019-11-18T03:20:27Z

On 17-11-2019 17:00, John Ericson wrote: what are these safe plugins and where do they come from?

I'm afraid I don't know. This patch is merely for convenience.

FRidh · 2019-11-19T14:03:34Z

pkgs/development/tools/misc/gdb/wrapper.nix

+    name = gdb.name;
+    buildInputs = [ makeWrapper ];
+    propagatedBuildInputs = [ gdb ];
+    propagatedUserEnvPkgs = [ gdb ];


Please avoid propagatedUserEnvPkgs. It's not needed either.

If removed the man-page for gdb is not available. Is there an alternative?

The wrapper could become part of the package itself.

So I should apply my changes in gdb/default.nix instead?

For sake of simplicity I would actually prefer gdb not being a script.
Instead I would suggest to compile stdenv.cc.cc.lib as default safe path into gcc: https://sourceware.org/gdb/onlinedocs/gdb/Auto_002dloading-safe-path.html using --with-auto-load-safe-path. Since libgcc is a dependency of gdb this would not increase closure size. There might be other packages that could be of interests such as go in safe-path. However I would rather put this into a nixos/homemanager module since not everybody uses those.

Personally I just have the whole /nix/store in my safe path, since I trust the programs that I am debugging in general.

--with-auto-load-safe-path

Ah, so there is a configure-time option for this; I'll try it out.

I just have the whole /nix/store

Does this not require you to trust your whole store? I don't, so I have ad-hoc white-listed the libstd++ plugin every update before this patch.

@tmplt right, however I personally don't consider this a problem, since I don't attach GDB to random processes and it depends on the libraries to linked to a process what plugins gdb would load. Also I don't quite share the threat model of GDB. If I execute a malicious program the system would be screwed anyway. An malicious gdb plugin does not add much. It would be only a problem if GDB would attach to an untrusted process, which is not what most people do.

Latest commit adds a configuration flag and scaps the wrapper.

pkgs/development/tools/misc/gdb/wrapper.nix

FRidh · 2019-11-19T14:05:08Z

pkgs/development/tools/misc/gdb/wrapper.nix

+    buildInputs = [ makeWrapper ];
+    propagatedBuildInputs = [ gdb ];
+    propagatedUserEnvPkgs = [ gdb ];
+    phases = "installPhase fixupPhase";


Avoid setting phases. Instead, pass e.g. dontBuild = true;

Ditto: using something like buildCommand instead doesn't make the man-page available.

Mic92 · 2019-11-19T14:37:36Z

This seems good, but in general what are these safe plugins and where do they come from? I ask because long term I want to always use separate derivations for libgcc, libstdc++, etc, just as we do for compiler-rt and libc++, etc (#26004).

They are provided by the packages itself. i.e.:

$ file $(nix-build --no-out-link '<nixpkgs>' -A stdenv.cc.cc.lib)/lib/libstdc++.so.*-gdb.py

Gdb looks for them next to the library and load them if their path is white-listed.

pkgs/development/tools/misc/gdb/default.nix

Ericson2314 · 2019-11-25T04:01:45Z

~~@Mic92 if this looks good to you, it looks good to me.~~

Actually wait, I am not sure about with-auto-load-safe-path because it makes our previously target-agnostic gdb target sensitive.

Mic92 · 2019-11-25T11:14:12Z

@Ericson2314 can you elaborate on what you mean with target sensitive? With this PR GDB marks its own libgcc as a safe path. A binary that has a different libgcc needs an additional whitelisting - however we can not solve this here.

pkgs/development/tools/misc/gdb/default.nix

Co-Authored-By: Jörg Thalheim <Mic92@users.noreply.github.com>

Ericson2314 · 2019-11-28T17:09:03Z

Is the intent that you are whitlisiting the libgcc that built gdb, or the libgcc that's probably used in the executable being debugged?

tmplt · 2019-11-28T21:49:18Z

On 28-11-2019 09:09, John Ericson wrote: Is the intent that you are whitlisiting the libgcc that built gdb, or the libgcc that's probably used in the executable being debugged?

The latter, but in my use-case it has always been the same libgcc that built gdb. I haven't considered version mismatch between gdb and executable before; thanks for pointing that out.

Ericson2314 · 2019-11-28T23:25:13Z

So this makes it definitionally the one that built gdb, while targetPackages.stdenv.cc.cc.libc would definitionally be the latter. The former is not what is wanted, thought at least not target sensative. The latter is what we want, but is sadly target sensitive.

I would rather revert this and have a db-wrapper, like cc-wrapper and bintools-wrapper, for gdb and lldb that injected the right flag for targetPackages.stdenv.cc.cc.lib without rebuilding gdb and lldb.

CC @matthewbauer

Mic92 · 2019-11-29T10:31:27Z

@Ericson2314 is stdenv.cc.cc.lib not the libgcc that is used at runtime? Because it is used everywhere in nixpkgs.

Ericson2314 · 2019-12-01T01:32:46Z

@Mic92 It is, but each stage has it's own (potentially different) stdenv.cc.cc.lib. Tools are gotten from buildPackages, and so we have buildPackages.targetPackages.stdenv.cc.cc.lib and so the buildPackages.targetPackages cancels out and we get back to stdenv.cc.cc.lib.

Ericson2314 · 2019-12-01T22:15:42Z

Ah i was totally wrong, gdb is not currently target agnostic, so the fix is very minimal: #74806

gdb: wrap, making libstdc++ plugin safe to load

800f280

tmplt mentioned this pull request Nov 17, 2019

add a wrapper to gdb which adds gcc (or other paths) as safe path #11139

Closed

tmplt commented Nov 17, 2019

View reviewed changes

pkgs/top-level/all-packages.nix Outdated Show resolved Hide resolved

ofborg bot added the 8.has: package (new) label Nov 17, 2019

ofborg bot requested a review from lovek323 November 17, 2019 18:17

ofborg bot added 10.rebuild-darwin: 501+ 10.rebuild-darwin: 5001+ 10.rebuild-linux: 501+ 10.rebuild-linux: 5001+ labels Nov 17, 2019

Merge remote-tracking branch 'upstream/staging' into wrap-gdb

9569273

tmplt requested review from alyssais, Ericson2314, FRidh, jonringer, LnL7, matthewbauer, Mic92, ttuegel and zimbatm as code owners November 17, 2019 22:37

tmplt changed the base branch from master to staging November 17, 2019 22:38

ofborg bot added 6.topic: emacs 6.topic: GNOME 6.topic: lua 6.topic: nixos 6.topic: python 6.topic: qt/kde 6.topic: ruby 6.topic: rust labels Nov 17, 2019

ofborg bot removed 6.topic: vim 8.has: changelog 8.has: documentation 8.has: module (update) 2.status: merge conflict labels Nov 18, 2019

ofborg bot requested a review from lovek323 November 18, 2019 01:06

FRidh requested changes Nov 19, 2019

View reviewed changes

tmplt added 2 commits November 19, 2019 16:48

gdb: don't propagate unwrapped gdb

6cff4ce

gdb: configure a safe path instead of wrapping

a3e0084

tmplt commented Nov 19, 2019

View reviewed changes

pkgs/development/tools/misc/gdb/default.nix Outdated Show resolved Hide resolved

ofborg bot requested review from globin and nbp November 19, 2019 20:55

gdb: use a safePaths parameter instead

75348fa

tmplt changed the title ~~gdb: wrap, making libstdc++ plugin safe to load~~ gdb: configure with stdenv.cc.cc.lib safe path Nov 21, 2019

tmplt requested review from Mic92 and FRidh November 21, 2019 17:06

Mic92 reviewed Nov 25, 2019

View reviewed changes

pkgs/development/tools/misc/gdb/default.nix Outdated Show resolved Hide resolved

gdb: prepend default safe paths

2c50bd3

Co-Authored-By: Jörg Thalheim <Mic92@users.noreply.github.com>

Mic92 merged commit 3ebebaf into NixOS:staging Nov 27, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gdb: configure with stdenv.cc.cc.lib safe path #73574

gdb: configure with stdenv.cc.cc.lib safe path #73574

tmplt commented Nov 17, 2019 •

edited

Loading

veprbl commented Nov 17, 2019

tmplt commented Nov 17, 2019 •

edited

Loading

Ericson2314 commented Nov 18, 2019 •

edited

Loading

tmplt commented Nov 18, 2019 via email

FRidh Nov 19, 2019

tmplt Nov 19, 2019

Mic92 Nov 19, 2019

tmplt Nov 19, 2019

Mic92 Nov 19, 2019

Mic92 Nov 19, 2019

tmplt Nov 19, 2019

Mic92 Nov 19, 2019 •

edited

Loading

tmplt Nov 19, 2019

FRidh Nov 19, 2019

tmplt Nov 19, 2019

Mic92 commented Nov 19, 2019

Ericson2314 commented Nov 25, 2019 •

edited

Loading

Mic92 commented Nov 25, 2019 •

edited

Loading

Ericson2314 commented Nov 28, 2019

tmplt commented Nov 28, 2019 via email

Ericson2314 commented Nov 28, 2019 •

edited

Loading

Mic92 commented Nov 29, 2019 •

edited

Loading

Ericson2314 commented Dec 1, 2019

Ericson2314 commented Dec 1, 2019

gdb: configure with stdenv.cc.cc.lib safe path #73574

gdb: configure with stdenv.cc.cc.lib safe path #73574

Conversation

tmplt commented Nov 17, 2019 • edited Loading

Motivation for this change

Things done

Notify maintainers

veprbl commented Nov 17, 2019

tmplt commented Nov 17, 2019 • edited Loading

Ericson2314 commented Nov 18, 2019 • edited Loading

tmplt commented Nov 18, 2019 via email

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mic92 Nov 19, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Mic92 commented Nov 19, 2019

Ericson2314 commented Nov 25, 2019 • edited Loading

Mic92 commented Nov 25, 2019 • edited Loading

Ericson2314 commented Nov 28, 2019

tmplt commented Nov 28, 2019 via email

Ericson2314 commented Nov 28, 2019 • edited Loading

Mic92 commented Nov 29, 2019 • edited Loading

Ericson2314 commented Dec 1, 2019

Ericson2314 commented Dec 1, 2019

tmplt commented Nov 17, 2019 •

edited

Loading

tmplt commented Nov 17, 2019 •

edited

Loading

Ericson2314 commented Nov 18, 2019 •

edited

Loading

Mic92 Nov 19, 2019 •

edited

Loading

Ericson2314 commented Nov 25, 2019 •

edited

Loading

Mic92 commented Nov 25, 2019 •

edited

Loading

Ericson2314 commented Nov 28, 2019 •

edited

Loading

Mic92 commented Nov 29, 2019 •

edited

Loading