|
From: James M. D. <mdu...@ya...> - 2002-12-31 09:07:11
|
Thank you very much for the detailed explaination.
Yes, I should have included the file with me,
or even a -x copy of it.
On that note, do you have a way to -save-temps like gcc does, like +x
so that you can capture the fully post-preprocessed files?
I am cvs updating and will tell you how I fare.
it is funny, but i had a feeling that those long indentifiers were
created out of some hashing scheme, I encountered similar longs ids
using hashes in shell before, just concatinating the symbols into
one...
Happy new year!
mike
--- "R. Bernstein" <ro...@pa...> wrote:
> A guess is the problem is that you have a plus (or some other
> character that isn't usually part of a BASH identifier) in the
> filename.
>
> +2D0M2D0D6Slibtool
> ^here
>
> Some background. For the debugger, it is very useful to have a hash
> table data structure. Hash tables are not part of bash (yet). The way
> these are implemented is to convert what in Perl would be $file{key}
> into a single identifier "file_key" making use of BASH's hashed
> symbol
> table.
>
> But in order to do this "key" can't have any non-identifer symbols,
> like "+", "/", "." and so on. So these must either be stripped or
> replaced. We in fact, replace them to make it easier to recontruct
> the
> original name. Right now I don't list all the weird symbols that
> might
> appear in a filename. In particular, I don't have "+" listed.
>
> Doing a reverse translation of +2D0M2D0D6Slibtool the original
> filename with a path probably contained something like
> "+2.0-2-0.6/libtool", possibly with other stuff in front. If this is
> the case, then a simple fix is to make sure we tranlate the "+" in
> _bashdb_file2var. That is, change this line 22 of bashdb-file.inc:
>
> local varname=`builtin echo $filename | tr '* .?/"[]-' 'ABDQSqLRM'`
>
> into this:
>
> local varname=`builtin echo $filename | tr '+* .?/"[]-'
> 'PABDQSqLRM'`
>
> Actually, I've already made the change in CVS.
>
> If that works, let me know. If not, it would be helpful to understand
> not just what the error message you encountered given below, but some
> short example giving *input* that you typed to get that output.
> Better, is a short test case that causes the debugger to fail.
>
> Thanks.
>
>
> James Michael DuPont writes:
> >
> > --- "R. Bernstein" <ro...@pa...> wrote:
> > > Hi there, Ho there,
> > >
> > > Okay. Thanks for the information and looking into bashdb. If you
> have
> > > questions, comments, or problems with bashdb let us know.
> > >
> > I am running this on libtool
> >
> > /usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
> > +2D0M2D0D6Slibtool: value too great for base (error token is
> > "2D0M2D0D6Slibtool")
> > /usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
> > +2D0M2D0D6Slibtool: value too great for base (error token is
> > "2D0M2D0D6Slibtool")
> >
> > # the line is
> > local -i max_line=`_bashdb_get_assoc_scalar_entry "_maxline_"
> > $filevar`
> > # echo "debug: -- max_line: $max_line --"
> >
> > bash -x ../libtool --mode=link i586-mingw32msvc-gcc
> > -DGLIB_STATIC_COMPILATION -mms-bitfields -Wall -D_REENTRANT
> > -I/usr/local/win32/include -I/usr/local/win32/include/glib-2.0/
> > -mms-bitfields -L/usr/local/win32/lib -o test-gdk-pixbuf.exe
> > test-gdk-pixbuf.o libgdk_pixbuf-2.0.la -L/usr/local/win32/lib/
> -lgdi32
> > -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv
> >
> > It has something to do with the size of the identfiers,
> > i will gdb it.
> >
> > mike
> >
> > =====
> > James Michael DuPont
> > http://introspector.sourceforge.net/
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> > http://mailplus.yahoo.com
=====
James Michael DuPont
http://introspector.sourceforge.net/
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
|