This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch to fix PR9861


On 9/26/05, Andrew Haley <aph@redhat.com> wrote:
> TJ Laurenzo writes:
>  > On 9/26/05, Andrew Haley <aph@redhat.com> wrote:
>  > > I tried your patch, and while it correctly demangles, it doesn't allow
>  > > me to put a breakpoint on 'f.main(java.lang.String[])' However,
>  > > putting a breakpoint on 'void f.main(java.lang.String[])' does work,
>  > > as you might expect.
>  > >
>  > > This has the rather nasty effect of breaking tab completion in gdb.
>  > > For example, you can't type "break 'f<tab>" and get a nice list of the
>  > > methods in f to choose from.
>  > >
>  > > It ought to be possible to fix this in gdb, though.  I'll investigate
>  > > some more.
>  >
>  > That just occurred to me about 10 seconds before your email hit my
>  > mailbox.  There are some C++ cases where this can happen too (function
>  > templates and operators, if I recall).  They are probably corner cases
>  > that GDB doesn't handle specially, though.
>  >
>  > What if the return type demangling didn't print the return type first
>  > (the return type could be in parentheses or something after the
>  > argument list or it could end with " returns void")?  That would also
>  > be a way to solve the problem.
>
> It would.  Nice idea.
>
Would you agree with changing the display for Java formatted names to
print it more like a Pascal declaration:
    f.main(String[]):void
I don't think we would need to touch the existing C++ format, even
though it sounds like it could benefit from the same things for C++
templates, et al.

TJ


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]