This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: print_symbol_info patch for source code not current language
- To: Michael Snyder <msnyder at cygnus dot com>
- Subject: Re: print_symbol_info patch for source code not current language
- From: muller at cerbere dot u-strasbg dot fr
- Date: Fri, 29 Oct 1999 23:28:56 +0200
- Cc: Jim Blandy <jimb at cygnus dot com>, gdb-patches at sourceware dot cygnus dot com
- References: <381824BF.BCE63370@cygnus.com><5mogdjbkr2.fsf@jtc.redbacknetworks.com><199910291101.NAA00678@cerbere.u-strasbg.fr><npzox2klaw.fsf@zwingli.cygnus.com>
At 13:08 29/10/99 -0700, you wrote:
>Jim Blandy wrote:
>>
>> > Shouldn't we use the language of source if known at least if
>> > the current language mode is auto ??
>> >
>> > This short patch to symtab.c solve this problem
>>
>> This looks good!
>>
>> However, saving, setting, and restoring the current language is
>> somewhat messy. Note that the definition of type_print just calls
>> LA_PRINT_TYPE, which calls current_language->la_print_type. Your code
>> could simply determine the appropriate language, L, and then call
>> L->la_print_type directly, instead of print_type.
>
>Sounds like a good idea.
That was my first try but its not a good solution
because then you get the args output in current_language
different from the function layout itself !!!
>> I don't know if it is possible for symbols to have language_auto as
>> their language. It is probably best to handle that case somehow, even
>> if it never arises.
>
>How about if "language_auto" symbols default
>to current_language (as all symbols currently do)?
Thats what my code already does,
as it does not change current_language if
SYMBOL_LANGUAGE(sym) is language_auto !!
I thought of another possibility which would be to
store the current_language in the two functions (there are only
two calling print_symbol_info)
So this would avoid setting back and for for each symbol.
Looking into rbreak_command function
I understand now why I have problems with that function under
pascal :
- pascal allows overloading i.e. functions with the same
name but different arguments, but this is not handled correctly by
rbreak_command as it calls break with
break_command("file_name:'FUNC_NAME'",from_tty);
if I define
procedure Halt;
and later
procedure Halt(i : integer);
in the same file
then
gdb > rbreak HALT
sets two breakpoints on the same function
(with some warning !)
A better way would be to set the break at file_name:line if the line is
known (at least for pascal)
but I don't know all subtilities between a function break and
a file:line break !