On Mon, 04 Aug 2008, Phil Barnett wrote:
Hi Phil and Viktor,
> > Probably, but there are few things, first of all
> > we'd need to think of this on the global level and
> > there are quite some more places where stack trace
> > is dumped. The other thing is that I'd rather like
> > to fully exclude source filenames from my final
> > executables (which is not possible since some time),
> > than even displaying them. Also function names should
> > always be enough to identify a program location
> > without doubts, IMO it would just mess up the
> > current simple dump layout.
Function names are not enough when you have binaries with
big number of static functions with the same names written
by different programmers so I can imagine situations when
such information can greatly help to locate the problem.
I can even imagine situations when it will be vital
to diagnose the reason of some errors, f.e. problem maybe
caused by overload functions or wrongly linked functions
with the same name coming from different libraries.
If information about file name can help in resolving the
problem then I do not see anything wrong in adding it.
For all .prg functions we have this information so it's
enough to change:
while( hb_procinfo( iLevel++, buffer, &uiLine, NULL ) )
{
snprintf( ptr, sizeof( msg ) - ( ptr - msg ),
HB_I_("Called from %s(%hu)\n"), buffer, uiLine );
if( hLog )
fwrite( ptr, sizeof( *ptr ), strlen( ptr ), hLog );
ptr += strlen( ptr );
}
to:
char file[ _POSIX_PATH_MAX + 1 ];
[...]
while( hb_procinfo( iLevel++, buffer, &uiLine, file ) )
{
snprintf( ptr, sizeof( msg ) - ( ptr - msg ),
HB_I_("Called from %s(%hu)%s%s\n"), buffer, uiLine,
*file ? " in " : "", file );
if( hLog )
fwrite( ptr, sizeof( *ptr ), strlen( ptr ), hLog );
ptr += strlen( ptr );
}
We can also update other procedures which shows call stack:
hb_procinfo() is used only in four places.
> I'm sure that it's not appropriate to include it into the compiler, but my
> source code reformatting program, Click!, would resolve this problem to the
> correct file name by analyzing all of the .lib file headers and parsing all
> of the function names out of them into a database. Then, at the point where I
> documented where the objects came from, I would use the link file to
> determine which order the libraries were linked and therefore which lib (and
> therefore file name) functions by the same name must have come from.
All such tools will be great additions but it's not trivial to detect
dependences list in some compilers/linkers. F.e. GCC/MinGW LD uses much
more different rules then most of other Windows/DOS linkers which are
additionally changed by library grouping options.
> So, if we need that code, it's in the Click! source code. We would have to
> expand it to index .dll files as well as .lib files to really have good
> coverage.
I can try to help in adding support for Linux and other *nixes.
> When we release 1.0.0, I'll probably remake Click! to handle all of this
> external documentation and code function header insertion.
:-)
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
