In the middle of the night I woke up realizing how to address the problem
of allowing function breakpoints referring to files that we hadn't
previously read in -- "read in" in the sense of the debugger, not in the
sense of the bash interpreter.
The changes and a regression test are in CVS now.
Basically we'll trust the file information coming back from bash when the
user asks about a particular function. And although this would solve the
problem when requesting a break at a function name, it will not solve the
problem where a file/line is specified and that file has been sourced but
we haven't stepped inside of it (so the debugger is not aware of its
existence).
Therefore there should probably be a command as well to force reading in a
particular file. GDB has "load" and "symbol-file" commands which are
roughly analogous. Although the "symbol-file' is closer in semantics,
"load" seems simpler and more natural here.
Earlier I had tried redefining the "source" command which does have some
advantages, but that opens up a whole other can of worms which I won't go
into.
Whenever I look at bashdb I'm reminded of a comment made by Paul Vixie
regarding BIND 8 - the amazing thing is not that it is flawed, but that it
does anything useful at all!
> On Mon, Dec 18, 2006 at 05:50:01PM -0700, Oleksandr Moskalenko wrote:
>> * Lionel Elie Mamane <[EMAIL PROTECTED]> [2006-12-16 06:15:02 +0100]:
>
>>> Here is an example session:
>
>>> bashdb<21>
>>> (/usr/sbin/mkinitramfs:81):
>>> 81: . /usr/share/initramfs-tools/hook-functions
>>> bashdb<22>
>>> (/usr/sbin/mkinitramfs:83):
>>> 83: . "${CONFDIR}/initramfs.conf"
>>> bashdb<23> break copy_exec
>>> File /usr/share/initramfs-tools/hook-functions not found in read-in
>>> files.
>>> See 'info files' for a list of known files.
>>> bashdb<24> break /usr/share/initramfs-tools/hook-functions:61
>>> File /usr/share/initramfs-tools/hook-functions not found in read-in
>>> files.
>>> See 'info files' for a list of known files.
>>> bashdb<25> info files
>>> Source files for which have been read in:
>
>>> The said file has just been loaded, the debugger even recognises the
>>> function name from it, but doesn't know the file.
>
>> The file has not been sourced since you stepped over that line. If
>> you'd like to source it you can get bash to know about that file by
>> stepping into the file, and using "finish" to get back out. I will
>> add a README to the package to make sure people see this point. This
>> behavior may be changed upstream in a future release.
>
>> Below is the information from the upstream author for your
>> reference.
>
>>> I'm not sure the user's analysis is correct. He thinks the file is
>>> loaded in because merely because he sees a line like this
>>> 81: . /usr/share/initramfs-tools/hook-functions
>
> No, I think the file is loaded because fact is that bash sourced it;
> because I didn't only "see" the
> 81: . /usr/share/initramfs-tools/hook-functions
> line, but I had it *executed*/run. That the debugger didn't notice is
> an imperfection in the debugger and/or the interface between bash and
> the debugger and/or bash. I understand Rocky puts it in the "probably
> too hard to fix" category, that's unfortunate but not deadly. If this
> doesn't get fixed, the next best thing is to document it, as Oleksandr
> said he would.
>
>>> For now, the person can get bash to know about that file by
>>> stepping into the file, and using "finish" to get back out.
>
> OK, thanks for that information.
>
>>> One possibility for fixing <snip> might be to see if I can redefine
>>> the "source" command to track filenames and read them in.
>
> . () { echo I am being called; builtin . "$@"; }
>
> and
>
> source () { echo I am being called; builtin source "$@"; }
>
> seem to function as expected, so there is hope for this solution; you
> can put your "track filename" actions in place of my echo?
>
> --
> Lionel
>
>
