This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


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

Re: print_symbol_info patch for source code not current language


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 !


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