This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: New feature "source-id"
- From: Doug Evans <dje at google dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: Gerhard Gappmeier <gerhard dot gappmeier at ascolab dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Sun, 16 Mar 2014 09:22:17 -0700
- Subject: Re: New feature "source-id"
- Authentication-results: sourceware.org; auth=none
- References: <7365721 dot BnaR1nHazz at lt-gergap> <CADPb22RsRdFvr09HC_zj_tvBVLEScC6UzgNs=UCjpf3zWCt_gQ at mail dot gmail dot com> <83siqjb50u dot fsf at gnu dot org> <CADPb22RX30L=95ST8H+PfWKzEj3Erw1_9HXa1a+7-G0iGDC_kw at mail dot gmail dot com>
On Sat, Mar 15, 2014 at 7:34 PM, Doug Evans <dje@google.com> wrote:
>
> Note that one concern I have is that it may be that some sites will
> want to have some of gdb's state updated when source files are
> automagically fetched. E.g., maybe one would want to update the
> source search path. Maybe not, but at any rate I don't want this
> feature to preclude doing things like that, and one can't do that if
> the feature works by running an external program via popen.
As a data point,
another way to go is to just have a convention for some global
variables in the binary.
With the debug info gdb can access them, and they could contain
everything that would be in the .note section.
I don't have a preference, per se.
I just mention it as a possibility, and if one went that route then
doing this in Python/Guile would be while perhaps not required
certainly easy.