From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jackie Smith Cashion To: GDB Patches Subject: RFA: "show user" output Date: Thu, 06 Sep 2001 14:58:00 -0000 Message-id: <3B97F051.7D3E36C2@redhat.com> X-SW-Source: 2001-09/msg00080.html I recently noticed that the "show user" output is messed up. The "if", "else", "while", and "end" keywords are printed twice on the line. I have attached a patch that fixes this. This is the first RFA I've submitted. I'll probably need some pointers on the approval and check in process. -- Jackie Smith Cashion email: jsmith@redhat.com phone: 931 438 2432 Index: ChangeLog =================================================================== RCS file: /cvs/src/src/gdb/ChangeLog,v retrieving revision 1.1590 diff -c -3 -p -r1.1590 ChangeLog *** ChangeLog 2001/09/05 23:44:43 1.1590 --- ChangeLog 2001/09/06 21:36:28 *************** *** 1,3 **** --- 1,8 ---- + 2001-09-06 Jackie Smith Cashion + + * cli/cli-script.c (print_command_lines): Remove extra + "if", "else", "while", and "end" from show user output. + 2001-09-05 Elena Zannoni * gdbarch.sh: Move include of dis-asm.h so it is generated earlier Index: cli/cli-script.c =================================================================== RCS file: /cvs/src/src/gdb/cli/cli-script.c,v retrieving revision 1.7 diff -c -3 -p -r1.7 cli-script.c *** cli-script.c 2001/06/17 15:16:12 1.7 --- cli-script.c 2001/09/06 21:36:32 *************** print_command_lines (struct ui_out *uiou *** 171,181 **** /* A while command. Recursively print its subcommands and continue. */ if (list->control_type == while_control) { - ui_out_text (uiout, "while "); ui_out_field_fmt (uiout, NULL, "while %s", list->line); ui_out_text (uiout, "\n"); print_command_lines (uiout, *list->body_list, depth + 1); - ui_out_field_string (uiout, NULL, "end"); if (depth) ui_out_spaces (uiout, 2 * depth); ui_out_text (uiout, "end\n"); --- 171,179 ---- *************** print_command_lines (struct ui_out *uiou *** 186,192 **** /* An if command. Recursively print both arms before continueing. */ if (list->control_type == if_control) { - ui_out_text (uiout, "if "); ui_out_field_fmt (uiout, NULL, "if %s", list->line); ui_out_text (uiout, "\n"); /* The true arm. */ --- 184,189 ---- *************** print_command_lines (struct ui_out *uiou *** 197,208 **** { if (depth) ui_out_spaces (uiout, 2 * depth); - ui_out_field_string (uiout, NULL, "else"); ui_out_text (uiout, "else\n"); print_command_lines (uiout, list->body_list[1], depth + 1); } - ui_out_field_string (uiout, NULL, "end"); if (depth) ui_out_spaces (uiout, 2 * depth); ui_out_text (uiout, "end\n"); --- 194,203 ---- >From kevinb@cygnus.com Thu Sep 06 16:21:00 2001 From: Kevin Buettner To: gdb-patches@sources.redhat.com Cc: "H . J . Lu" Subject: Re: [PATCH RFA] partial-stab.h patch amendment Date: Thu, 06 Sep 2001 16:21:00 -0000 Message-id: <1010906232048.ZM8395@ocotillo.lan> References: <1010905224331.ZM6026@ocotillo.lan> <1010906205537.ZM8109@ocotillo.lan> X-SW-Source: 2001-09/msg00081.html Content-length: 5795 I recently committed the following changes: > * dbxread.c (process_one_symbol): Don't use error result from > find_stab_function_addr(). > * partial-stab.h (case 'F'): Likewise. > > * partial-stab.h (case 'f'): Make SOFUN_ADDRESS_MAYBE_MISSING > code match that used for case 'F'. This fixes the divergence > that was introduced by my 1999-09-14 changes to partial-stab.h. Those of you who've been following this thread should also be aware of some additional analysis from H.J. Lu: http://sources.redhat.com/ml/gdb/2001-09/msg00046.html I have dumped GDB's minimal symbol table and the partial symbol table and have found that __strtol_internal appears once in the minimal symbol table: [413] T 0x40062634 __strtol_internal section .text frame-dwarf2.c But it appears twice in the partial symbol table: Partial symtab for source file eval.c (object 0x828cb74) Read from object file /lib/libdl.so.2 (0x8270ff8) Relocate symbols by 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x4002d000, 0x0, 0x4002d000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 Symbols cover text addresses 0x4002eb20-0x4002f10a Depends on 2 other partial symtabs. 0 0x8283714 dlopen.c 1 0x82844b8 dlerror.c Global partial symbols: `__strtol_internal', function, 0x4002d000 ... Partial symtab for source file ../sysdeps/generic/strtol.c (object 0x837860c) Read from object file /lib/i686/libc.so.6 (0x828d130) Full symtab was read (at 0x852f800 by function at 0x80f805c) Relocate symbols by 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x40031000, 0x0, 0x40031000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 Symbols cover text addresses 0x40062630-0x40062d3f Depends on 12 other partial symtabs. 0 0x402fb3cc soinit.c 1 0x83558d8 iconv_open.c 2 0x82a08bc ../sysdeps/unix/sysv/linux/init-first.c 3 0x8355284 ../sysdeps/generic/check_fds.c 4 0x8357534 gconv.c 5 0x8353024 ../sysdeps/generic/libc-start.c 6 0x8362750 setlocale.c 7 0x835be40 gconv_trans.c 8 0x8357a18 gconv_db.c 9 0x8364744 mb_cur_max.c 10 0x83650bc lc-time.c 11 0x835b220 gconv_simple.c Global partial symbols: `__strtol_internal', function, 0x40062634 ... The first of the psymtab entries for __strtol_internal is wrong. When I disassemble at the address in question, I see: (gdb) x/8i 0x4002d000 0x4002d000: jg 0x4002d047 0x4002d002: dec %esp 0x4002d003: inc %esi 0x4002d004: add %eax,(%ecx) 0x4002d006: add %eax,(%eax) 0x4002d008: add %al,(%eax) 0x4002d00a: add %al,(%eax) 0x4002d00c: add %al,(%eax) ...which doesn't look like a function prologue to me. (I've disassembled the second one and it *does* look like a function prologue.) So, how did this happen? If you read H.J.'s message, you'll see that __strtol_internal appears in libdl.so.2 as a weak undefined symbol. It got that way presumably through a bug somewhere else in the toolchain (linker perhaps?) which converted it from a weak defined symbol to a weak undefined symbol. Yet, in the process, the stabs entries related to this symbol weren't removed. Thus we end up having stabs entries which describe an undefined symbol. Prior to my patch, when gdb read such an entry (N_FUN, descriptor 'F', with zero value), it would (assuming that the SOFUN_ADDRESS_MAYBE_MISSING code is enabled): 1) Notice that the value is zero. 2) Due to the zero value, it would attempt to look up the value using the minimal symbols. 3) Set pst->textlow to this value if it hadn't already been set. For the particular case involving __strtol_internal, this symbol appeared first and that caused the symbol's value to be set to zero AND it caused pst->textlow to also be set to zero. (It was this last bit which caused disasterous consequences when looking up other symbols.) Now, with my patch applied, gdb no longer attempts to use a zero value from the result of looking up the minimal symbol since this (usually) represents an error condition. Instead, the original value is used which will be zero plus the offset of the .text section. This at least causes pst->textlow to be set correctly - or at least closer to where it ought to be. Either with or without my recent patch, a symbol ends up getting defined which shouldn't be. I'm not sure that this is of any great concern because GDB gets its symbol information from several sources and if one of these sources is inconsistent with another, it is not unreasonable to expect GDB to become somewhat confused. Also, it does seem reasonable to expect there to be times when a symbol will be defined by the debug info, but not by the linkage info. So, it doesn't seem like a good idea to refuse to add symbols to the partial symbol table just because they don't exist in the minimal symbol table. I don't really expect any comments on this message, but I wanted write down what I know of the matter before moving on to something else... Kevin