Attached is slight improvement on the patch posted before - it adds
source files to be put in functrace.

I'm not sure how functrace strings get freed; an explicit free() doesn't work

However see my next post regarding trap DEBUG.

On Mon, Jul 28, 2008 at 8:46 AM, Rocky Bernstein
<rocky.bernstein@gmail.com> wrote:
> Patch should be added. It's not the only way to do this and it changes
> the functrace (which could easily be addressed, so there might be some
> discussion.
>
> Comments about how the patch works are below. For the little that I've
> tried, it seems to work. Of course there are other line number
> weirdnesses I haven't worked out yet.
>
> One thing  more easily addressed is the fact that sourcing a file
> doesn't show in functrace and I think it should. I think sourcing is
> in fact like a function call. In fact one can write "source" as a
> function which does a read/eval of the file name.
>
> In looking at the code in surrounding the patch one question I have is
> how the strings allocated for  funcstack->name and funcstack->caller
> get freed? This is relevant if one extends source to do the same
> thing.
>
> Thanks.
>
>
> On Mon, Jul 28, 2008 at 4:34 AM, Peter Stephenson <pws@csr.com> wrote:
>> "Rocky Bernstein" wrote:
>>> I see that zsh has now has array variables functrace and
>>> funcstack. Functrace stack gives a function name and a line offset
>>> from the function. But for many things involving location reporting,
>>> it would more be desirable to have a filename and absolute line
>>> location.
>>>
>>> Alternatively, if there were a way to get the filename and line number
>>> of the beginning of a given function, one can do some arithmetic to
>>> get the absolute position.
>>>
>>> Is there currently a way to get this information. Should I try at
>>> submitting a patch?
>>
>> It would be useful to have information referred to the autoload file,
>> and I've wondered about how to do it, but I don't think it's trivial
>> with the current way line numbers work.  We would probably need to add
>> an extra internal variable for file line numbers, and present another
>> variable (or array, if in the funcstack style) to users to distinguish
>> the two.
>
> This is more or less the approach I tried. There is a variable called
> scriptname which I think is a little misleading. It is the name of the
> file when not in a function but gets set to a function name when that
> is run. So I added a variable called scriptfilename which mirrors
> scriptname but doesn't get changed when a function is run.
>
> When functions are defined, I save the current file, scriptfilename,
> and line number, lineno, in the shfunc structure. As for the C
> funcstack list, rather than remove any of the existing information, I
> added two more fields for the filename and absolute line number. Right
> now I changed the functrace routine in Src/Modules/parameter.c to use
> these new fields rather than the old ones. If one wants the function
> name rather than the file name, one can always use funcstack which has
> that. So right now you can't easily get the line number relative to
> the beginning of the function, although it's there.
>
> bash can show the new information, file name and starting line number using
>
> declare -F *fn*
>
> (Actually, shopt extdebug also has to be set.) It might be helpful to
> add that, and this would be one way to get the old function offset
> information. Another way would be to turn functrace into a builtin
> function and pass (an optional?) parameter indicating what flavor of
> information you want. Or a 3rd routine/variable could be used.
>
>>
>> --
>> Peter Stephenson <pws@csr.com>                  Software Engineer
>> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
>> Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070
>>
>