Hi,
On Sat, Jun 27, 2009 at 09:23:29AM +0300, Modestas Vainius wrote:
> While it is a good idea worth consideration but I think demangled symbol
> names are somewhat too ambiguous to be used in general. See below:
[Examples]
Not a problem IMO -- we need a new package name anyway if gcc's ABI
ch
Hello,
On 2009 m. June 26 d., Friday 23:01:54 Florian Weimer wrote:
> * Modestas Vainius:
> > While apparently, VT can't be implemented differently (except \d+),
> > what about size_t etc. then? They all can be implemented as regexps
> > too the most simple being 'any character'. However, in my op
* Modestas Vainius:
> While apparently, VT can't be implemented differently (except \d+),
> what about size_t etc. then? They all can be implemented as regexps
> too the most simple being 'any character'. However, in my opinion,
> exact string matching is worthwhile to keep whenever possible.
Can
Hello,
On 2009 m. June 26 d., Friday 19:43:13 Ben Hutchings wrote:
>
> Would it be possible to implement expansion to a regexp instead of to a
> string that must exactly match?
I think yes if there is no other way (and according to your answers, there
really isn't). Symbol files have two usage s
On Fri, Jun 26, 2009 at 04:34:00PM +0300, Modestas Vainius wrote:
[...]
> 2b) Still 2a is not enough if the base class contains such data members like
> (s)size_t (on s390) or qreal (on armel). To support such cases, vt can only
> be
> a complex expression with recursive subst expansion like
>
Hello,
On 2009 m. June 26 d., Friday 02:02:48 Ben Hutchings wrote:
> > - it's probably impossible to have substitutions to cover all cases
> > for C++ symbol mangling... do you believe that it is possible
> > to have enough (stable) substitutions to cover most common cases?
> >
> > (in the
On Thu, 2009-06-25 at 22:40 +0200, Raphael Hertzog wrote:
> Hello,
>
> it is well known that C++ symbol mangling result in different symbol
> names from one architecture to the other. It means that libraries that
> want to provide symbol files have to maintain one symbol file for each
> architectu
Hello,
it is well known that C++ symbol mangling result in different symbol
names from one architecture to the other. It means that libraries that
want to provide symbol files have to maintain one symbol file for each
architecture. To avoid this problem Modestas Vainius has written a patch
that le
8 matches
Mail list logo
