[RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Paul Pluzhnikov]

Greetings,

Gdb currently refuses to set a breakpoint on versioned symbols.
Consider:

$ cat t.c
#include <pthread.h>

void *fn(void *p) { return 0; }
int main()
{
    pthread_t tid;
    pthread_create(&tid, 0, fn, 0);
    pthread_join(tid, 0);
    return 0;
}

$ gcc -g -pthread -o t t.c && gdb --version && gdb -q ./t
GNU gdb 6.8.50.20080512-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
(gdb) b main
Breakpoint 1 at 0x8048412: file t.c, line 7.
(gdb) r
[Thread debugging using libthread_db enabled]

Breakpoint 1, main () at t.c:7
7           pthread_create(&tid, 0, fn, 0);
(gdb) b 'pthread_create@       << Hit TAB twice
pthread_create@@GLIBC_2.1  pthread_create@GLIBC_2.0
pthread_create@plt
(gdb) b 'pthread_create@@GLIBC_2.1'
Can't find member of namespace, class, struct, or union named
"pthread_create@@GLIBC_2.1"
Hint: try 'pthread_create@@GLIBC_2.1'<TAB> or 'pthread_create@@GLIBC_2.1'<ESC-?>
(Note leading single quote.)
(gdb) q


Attached patch fixes that problem, by stripping version info before
deciding whether the breakpoint location contains any components.

Thanks,
-- 
Paul Pluzhnikov

2008-05-13  Paul Pluzhnikov  <ppluzhnikov@google.com>

	* linespec.c (locate_first_half): Rename to...
	(locate_first_half_1): ... this.
	(locate_first_half): New fn.

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Daniel Jacobowitz]

On Tue, May 13, 2008 at 11:35:53AM -0700, Paul Pluzhnikov wrote:
> 2008-05-13  Paul Pluzhnikov  <ppluzhnikov@google.com>
> 
> 	* linespec.c (locate_first_half): Rename to...
> 	(locate_first_half_1): ... this.
> 	(locate_first_half): New fn.
> 

Patch missing?

Rather than making versions special, can we suppress looking for
fields inside quoted strings?  GCC names static variables "foo.1" and
it's hard to get GDB to display that.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Michael Snyder]

On Tue, 2008-05-13 at 14:44 -0400, Daniel Jacobowitz wrote:
> On Tue, May 13, 2008 at 11:35:53AM -0700, Paul Pluzhnikov wrote:
> > 2008-05-13  Paul Pluzhnikov  <ppluzhnikov@google.com>
> > 
> > 	* linespec.c (locate_first_half): Rename to...
> > 	(locate_first_half_1): ... this.
> > 	(locate_first_half): New fn.
> > 
> 
> Patch missing?
> 
> Rather than making versions special, can we suppress looking for
> fields inside quoted strings?  GCC names static variables "foo.1" and
> it's hard to get GDB to display that.

FYI, there's a sort-of work-around...

(gdb) rb pthread_create
Function "pthread_create" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

<function, no debug info> pthread_create@plt;
Breakpoint 2 at 0xc746a6
<function, no debug info> __pthread_create_2_1;
Can't find member of namespace, class, struct, or union named
"pthread_create@@GLIBC_2.1"
Hint: try 'pthread_create@@GLIBC_2.1<TAB> or
'pthread_create@@GLIBC_2.1<ESC-?>
(Note leading single quote.)
<function, no debug info> pthread_create@@GLIBC_2.1;
Breakpoint 3 at 0xc75145
<function, no debug info> __pthread_create_2_0;
Can't find member of namespace, class, struct, or union named
"pthread_create@GLIBC_2.0"
Hint: try 'pthread_create@GLIBC_2.0<TAB> or
'pthread_create@GLIBC_2.0<ESC-?>
(Note leading single quote.)
<function, no debug info> pthread_create@GLIBC_2.0;
(gdb) i b
Num Type           Disp Enb Address    What
1   breakpoint     keep y   0x0804846f in main at t.c:7
        breakpoint already hit 1 time
2   breakpoint     keep y   0x00c746a6 <pthread_create@@GLIBC_2.1+6>
3   breakpoint     keep y   0x00c75145 <pthread_create@GLIBC_2.0+5>

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Paul Pluzhnikov]

[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]

On Tue, May 13, 2008 at 11:44 AM, Daniel Jacobowitz <drow@false.org> wrote:
> On Tue, May 13, 2008 at 11:35:53AM -0700, Paul Pluzhnikov wrote:
>  > 2008-05-13  Paul Pluzhnikov  <ppluzhnikov@google.com>
>  >
>  >       * linespec.c (locate_first_half): Rename to...
>  >       (locate_first_half_1): ... this.
>  >       (locate_first_half): New fn.
>  >
>
>  Patch missing?

Sorry 'bout that. It's attached now.

>  Rather than making versions special, can we suppress looking for
>  fields inside quoted strings?  GCC names static variables "foo.1" and
>  it's hard to get GDB to display that.

Actually, that appears to already work:

$ cat t.c
#include <pthread.h>

void *fn(void *p)
{
  static int zzyx = 24;
  return 0;
}
int main()
{
    static int zzyx = 42;
    pthread_t tid;
    pthread_create(&tid, 0, fn, 0);
    pthread_join(tid, 0);
    return 0;
}

$ gcc -g -o t t.c -pthread
$ gdb/gdb -q ./t
(gdb) b main
Breakpoint 1 at 0x8048412: file t.c, line 12.
(gdb) r
[Thread debugging using libthread_db enabled]

Breakpoint 1, main () at t.c:12
12          pthread_create(&tid, 0, fn, 0);
(gdb) inf var zzyx
All variables matching regular expression "zzyx":

Non-debugging symbols:
0x08049650  zzyx.1565
0x08049654  zzyx.1570
(gdb) p 'zzyx.1565'
$1 = 24
(gdb) p 'zzyx.1570'
$2 = 42
(gdb) q

On Tue, May 13, 2008 at 1:23 PM, Michael Snyder <msnyder@specifix.com> wrote:
>
>  FYI, there's a sort-of work-around...

That only sort-of-works because there is a matching non-versioned
symbol. In addition, it's quite annoying for TAB-completion to
complete the symbol, but the result of completion to then not work.

Yes, I could also set breakpoints by address, etc.
But I'd like to make it easy for non-gdb-experts to be able to
set breakpoints.

Thanks,
-- 
Paul Pluzhnikov

2008-05-13  Paul Pluzhnikov  <ppluzhnikov@google.com>

	* linespec.c (locate_first_half): Rename to...
	(locate_first_half_1): ... this.
	(locate_first_half): New fn.

[-- Attachment #2: gdb-20080513-patch.txt --]
[-- Type: text/plain, Size: 1266 bytes --]

2008-05-13  Paul Pluzhnikov  <ppluzhnikov@google.com>

	* linespec.c (locate_first_half): Rename to...
	(locate_first_half_1): ... this.
	(locate_first_half): New fn.

Index: linespec.c
===================================================================
RCS file: /cvs/src/src/gdb/linespec.c,v
retrieving revision 1.77
diff -u -p -u -r1.77 linespec.c
--- linespec.c	3 May 2008 00:37:34 -0000	1.77
+++ linespec.c	13 May 2008 18:26:58 -0000
@@ -1002,7 +1002,7 @@ decode_indirect (char **argptr)
    at the end.  */
 
 static char *
-locate_first_half (char **argptr, int *is_quote_enclosed)
+locate_first_half_1 (char **argptr, int *is_quote_enclosed)
 {
   char *ii;
   char *p, *p1;
@@ -1094,6 +1094,25 @@ locate_first_half (char **argptr, int *i
   return p;
 }
 
+static char *
+locate_first_half (char **argptr, int *is_quote_enclosed)
+{
+  char *p;
+  char *at = strrchr(*argptr, '@');
+  if (at)
+    {
+      /* Could be "pthread_create@GLIBC_2.0", or
+         "pthread_create@@GLIBC_2.1".  */
+      if (*argptr < at - 1 && at[-1] == '@')
+        --at;
+      *at = '\0';
+    }
+  p = locate_first_half_1 (argptr, is_quote_enclosed);
+  if (at)
+    *at = '@';
+  return p;
+}
+
 \f
 
 /* Here's where we recognise an Objective-C Selector.  An Objective C

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Daniel Jacobowitz]

On Tue, May 13, 2008 at 01:51:57PM -0700, Paul Pluzhnikov wrote:
> Actually, that appears to already work:

Then I don't understand.  If we're not looking for a field because of
the ".1" then why are we looking for a field?

The @ is not inherently special in ELF; there's other strange
characters that are valid in symbol names (minsyms).  So inside quotes
we shouldn't be trying to interpret it as anything.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Paul Pluzhnikov]

On Tue, May 13, 2008 at 1:59 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Tue, May 13, 2008 at 01:51:57PM -0700, Paul Pluzhnikov wrote:
>  > Actually, that appears to already work:
>
>  Then I don't understand.  If we're not looking for a field because of
>  the ".1" then why are we looking for a field?

I'll investigate and report back ...

>  The @ is not inherently special in ELF; there's other strange
>  characters that are valid in symbol names (minsyms).  So inside quotes
>  we shouldn't be trying to interpret it as anything.

Ok, I'll try to rewrite the patch to do just that.

Thanks,
-- 
Paul Pluzhnikov

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Paul Pluzhnikov]

[-- Attachment #1: Type: text/plain, Size: 6783 bytes --]

On Tue, May 13, 2008 at 2:11 PM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> On Tue, May 13, 2008 at 1:59 PM, Daniel Jacobowitz <drow@false.org> wrote:
>  > On Tue, May 13, 2008 at 01:51:57PM -0700, Paul Pluzhnikov wrote:
>  >  > Actually, that appears to already work:
>  >
>  >  Then I don't understand.  If we're not looking for a field because of
>  >  the ".1" then why are we looking for a field?
>
>  I'll investigate and report back ...

So the expression evaluation and the breakpoint evaluation go
completely separate routes:

  p 'zzyx.1565'

reaches lookup_minimal_symbol() this way:

  #0  lookup_minimal_symbol (name=0x930ca0 "zzyx.1565", sfile=0x0,
objf=0x0) at ../../src/gdb/minsyms.c:178
  #1  0x0000000000527f0a in c_parse () at c-exp.y:724
  #2  0x00000000004eff0e in c_preprocess_and_parse () at
../../src/gdb/c-lang.c:298
  #3  0x00000000004ba3fc in parse_exp_1 (stringptr=0x7fffffffe0d0,
block=0x0, comma=<value optimized out>) at ../../src/gdb/parse.c:991
  #4  0x00000000004ba534 in parse_expression (string=0x7d61c2
"'zzyx.1565'") at ../../src/gdb/parse.c:1030
  #5  0x000000000047a635 in print_command_1 (exp=0x7d61c2
"'zzyx.1565'", inspect=0, voidprint=1) at ../../src/gdb/printcmd.c:877
  #6  0x0000000000406ec5 in execute_command (p=0x7d61cc "'",
from_tty=0) at ../../src/gdb/top.c:466
  #7  0x00000000004a13eb in command_handler (command=0x7d61c0 "p
'zzyx.1565'") at ../../src/gdb/event-top.c:514
  #8  0x00000000004a1f90 in command_line_handler (rl=<value optimized
out>) at ../../src/gdb/event-top.c:745
  #9  0x000000000054e903 in rl_callback_read_char () at
../../src/readline/callback.c:205
  #10 0x00000000004a1579 in rl_callback_read_char_wrapper
(client_data=0x930ca0) at ../../src/gdb/event-top.c:177
  #11 0x00000000004a0153 in process_event () at ../../src/gdb/event-loop.c:341
  #12 0x00000000004a0a68 in gdb_do_one_event (data=<value optimized
out>) at ../../src/gdb/event-loop.c:378
  #13 0x000000000049d83b in catch_errors (func=0x4a08b0
<gdb_do_one_event>, func_args=0x0, errstring=0x6034b6 "", mask=<value
optimized out>)
      at ../../src/gdb/exceptions.c:509
  #14 0x000000000044a416 in tui_command_loop (data=<value optimized
out>) at ../../src/gdb/tui/tui-interp.c:153
  #15 0x0000000000400359 in captured_command_loop (data=0x930ca0) at
../../src/gdb/main.c:99
  #16 0x000000000049d83b in catch_errors (func=0x400350
<captured_command_loop>, func_args=0x0, errstring=0x6034b6 "",
mask=<value optimized out>)
      at ../../src/gdb/exceptions.c:509
  #17 0x0000000000400afe in captured_main (data=<value optimized out>)
at ../../src/gdb/main.c:882
  #18 0x000000000049d83b in catch_errors (func=0x400390
<captured_main>, func_args=0x7fffffffe630, errstring=0x6034b6 "",
mask=<value optimized out>)
      at ../../src/gdb/exceptions.c:509
  #19 0x0000000000400344 in gdb_main (args=0x0) at ../../src/gdb/main.c:891
  #20 0x0000000000400316 in main (argc=<value optimized out>,
argv=0x0) at ../../src/gdb/gdb.c:33

but the "break 'pthread_create@@GLIBC_2.1'" reaches it like this
(after my original patch; without it we don't reach
lookup_minimal_symbol at all):

  #0  lookup_minimal_symbol (name=0x7fffffffdce1
"pthread_create@@GLIBC_2.1", sfile=0x0, objf=0x0) at
../../src/gdb/minsyms.c:178
  #1  0x000000000048a94a in decode_line_1 (argptr=0x7fffffffe008,
funfirstline=1, default_symtab=0x86ed38, default_line=1,
canonical=0x7fffffffe0c8,
      not_found_ptr=0x7fffffffe0dc) at ../../src/gdb/linespec.c:1785
  #2  0x0000000000457615 in do_captured_parse_breakpoint (ui=<value
optimized out>, data=<value optimized out>) at
../../src/gdb/breakpoint.c:5325
  #3  0x000000000049da70 in catch_exception (uiout=0x8299b0,
func=0x457560 <do_captured_parse_breakpoint>,
func_args=0x7fffffffe070, mask=<value optimized out>)
      at ../../src/gdb/exceptions.c:463
  #4  0x000000000045d905 in break_command_really (arg=0x7d61dd "",
cond_string=0x0, thread=0, parse_condition_and_thread=1, tempflag=0,
hardwareflag=774778414,
      ignore_count=0, pending_break_support=AUTO_BOOLEAN_AUTO,
ops=0x0, from_tty=0) at ../../src/gdb/breakpoint.c:5460
  #5  0x000000000045e13e in break_command_1 (arg=0x7fffffffdce1
"pthread_create@@GLIBC_2.1", flag=<value optimized out>,
from_tty=<value optimized out>)
      at ../../src/gdb/breakpoint.c:5617
  #6  0x0000000000406ec5 in execute_command (p=0x7d61dc "'",
from_tty=0) at ../../src/gdb/top.c:466
  #7  0x00000000004a143b in command_handler (command=0x7d61c0 "b
'pthread_create@@GLIBC_2.1'") at ../../src/gdb/event-top.c:514
  #8  0x00000000004a1fe0 in command_line_handler (rl=<value optimized
out>) at ../../src/gdb/event-top.c:745
  #9  0x000000000054e953 in rl_callback_read_char () at
../../src/readline/callback.c:205
  #10 0x00000000004a15c9 in rl_callback_read_char_wrapper
(client_data=0x7fffffffdce1) at ../../src/gdb/event-top.c:177
  #11 0x00000000004a01a3 in process_event () at ../../src/gdb/event-loop.c:341
  #12 0x00000000004a0ab8 in gdb_do_one_event (data=<value optimized
out>) at ../../src/gdb/event-loop.c:378
  #13 0x000000000049d88b in catch_errors (func=0x4a0900
<gdb_do_one_event>, func_args=0x0, errstring=0x603516 "", mask=<value
optimized out>)
      at ../../src/gdb/exceptions.c:509
  #14 0x000000000044a416 in tui_command_loop (data=<value optimized
out>) at ../../src/gdb/tui/tui-interp.c:153
  #15 0x0000000000400359 in captured_command_loop
(data=0x7fffffffdce1) at ../../src/gdb/main.c:99
  #16 0x000000000049d88b in catch_errors (func=0x400350
<captured_command_loop>, func_args=0x0, errstring=0x603516 "",
mask=<value optimized out>)
      at ../../src/gdb/exceptions.c:509
  #17 0x0000000000400afe in captured_main (data=<value optimized out>)
at ../../src/gdb/main.c:882
  #18 0x000000000049d88b in catch_errors (func=0x400390
<captured_main>, func_args=0x7fffffffe640, errstring=0x603516 "",
mask=<value optimized out>)
      at ../../src/gdb/exceptions.c:509
  #19 0x0000000000400344 in gdb_main (args=0x0) at ../../src/gdb/main.c:891
  #20 0x0000000000400316 in main (argc=<value optimized out>,
argv=0x0) at ../../src/gdb/gdb.c:33

The reason locate_first_half() is looking for '.' is perhaps
explained by this comment:

       if (p[0] == '.' && strchr (p, ':') == NULL)
        {
          /* Java qualified method.  Find the *last* '.', since the
             others are package qualifiers.  */


>  >  The @ is not inherently special in ELF; there's other strange
>  >  characters that are valid in symbol names (minsyms).  So inside quotes
>  >  we shouldn't be trying to interpret it as anything.
>
>  Ok, I'll try to rewrite the patch to do just that.

Attached.

-- 
Paul Pluzhnikov

2008-05-13  Paul Pluzhnikov  <ppluzhnikov@google.com>

        * linespec.c (decode_line_1): Don't try to interpret
        single-quoted text as linespec.

[-- Attachment #2: gdb-20080513-patch2.txt --]
[-- Type: text/plain, Size: 1958 bytes --]

2008-05-13  Paul Pluzhnikov  <ppluzhnikov@google.com>

	* linespec.c (decode_line_1): Don't try to interpret
	single-quoted text as linespec.

Index: linespec.c
===================================================================
RCS file: /cvs/src/src/gdb/linespec.c,v
retrieving revision 1.77
diff -u -p -u -6 -r1.77 linespec.c
--- linespec.c	3 May 2008 00:37:34 -0000	1.77
+++ linespec.c	14 May 2008 00:47:41 -0000
@@ -721,22 +721,31 @@ decode_line_1 (char **argptr, int funfir
      checking, where we allow things like:
         (gdb) break c::f(int)
   */
 
   set_flags (*argptr, &is_quoted, &paren_pointer);
 
-  /* Check to see if it's a multipart linespec (with colons or
-     periods).  */
+  if ((*argptr)[0] == '\'')
+    {
+      /* Don't try to interpret anything in single quotes.  */
+      p = "";
+      is_quote_enclosed = 0;
+    }
+  else
+    {
+      /* Check to see if it's a multipart linespec (with colons or
+         periods).  */
 
-  /* Locate the end of the first half of the linespec.
-     After the call, for instance, if the argptr string is "foo.c:123"
-     p will point at "123".  If there is only one part, like "foo", p
-     will point to "". If this is a C++ name, like "A::B::foo", p will
-     point to "::B::foo". Argptr is not changed by this call.  */
+      /* Locate the end of the first half of the linespec.
+         After the call, for instance, if the argptr string is "foo.c:123"
+         p will point at "123".  If there is only one part, like "foo", p
+         will point to "". If this is a C++ name, like "A::B::foo", p will
+         point to "::B::foo". Argptr is not changed by this call.  */
 
-  p = locate_first_half (argptr, &is_quote_enclosed);
+      p = locate_first_half (argptr, &is_quote_enclosed);
+    }
 
   /* Check if this is an Objective-C method (anything that starts with
      a '+' or '-' and a '[').  */
   if (is_objc_method_format (p))
     {
       is_objc_method = 1;

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Daniel Jacobowitz]

On Tue, May 13, 2008 at 06:05:05PM -0700, Paul Pluzhnikov wrote:
> So the expression evaluation and the breakpoint evaluation go
> completely separate routes:

Ah, right.  I tried nested functions in GCC, which have the same
problem.

(gdb) b 'bar.18<tab>
bar.1873  bar.1888
(gdb) b 'bar.1888'
Can't find member of namespace, class, struct, or union named "bar.1888"

>    set_flags (*argptr, &is_quoted, &paren_pointer);
>  
> -  /* Check to see if it's a multipart linespec (with colons or
> -     periods).  */
> +  if ((*argptr)[0] == '\'')

I believe this is the same as is_quoted.  If I'm right, that implies
that this breaks:

(gdb) break 'foo.c':13

We need to call locate_first_half to separate the filename from the
line number.  There's also the 'foo.c'::staticvar form to worry about.
I think locate_first_half is going to have to know whether is_quoted,
and if so, only look for the matching quote.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Paul Pluzhnikov]

On Thu, Jun 5, 2008 at 12:13 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Tue, May 13, 2008 at 06:05:05PM -0700, Paul Pluzhnikov wrote:
>> So the expression evaluation and the breakpoint evaluation go
>> completely separate routes:
>
> Ah, right.  I tried nested functions in GCC, which have the same
> problem.

Yes, and the same fix should fix that as well :)

>>    set_flags (*argptr, &is_quoted, &paren_pointer);
>>
>> -  /* Check to see if it's a multipart linespec (with colons or
>> -     periods).  */
>> +  if ((*argptr)[0] == '\'')
>
> I believe this is the same as is_quoted.

You are correct.

> If I'm right, that implies that this breaks:
>
> (gdb) break 'foo.c':13

But that is *already* broken:

(gdb) b t.c:8
Breakpoint 1 at 0x400308: file t.c, line 8.
(gdb) b "t.c":8
Breakpoint 2 at 0x400308: file t.c, line 8.
(gdb) b 't.c':8
No source file named t.c'.
(gdb)

I can fix that (and I believe it should be fixed), but it appears
that single and double quotes are treated quite differently in
linespec.c

Is there maybe a reason for this?

> We need to call locate_first_half to separate the filename from the
> line number.  There's also the 'foo.c'::staticvar form to worry about.

That case already works correctly (remember -- variables go through
totally different path).

> I think locate_first_half is going to have to know whether is_quoted,
> and if so, only look for the matching quote.

Something like this:

@@ -1003,7 +1003,9 @@ locate_first_half (char **argptr, int *i

   /* Maybe arg is FILE : LINENUM or FILE : FUNCTION.  May also be
      CLASS::MEMBER, or NAMESPACE::NAME.  Look for ':', but ignore
-     inside of <>.  */
+     inside of <>.
+     May also be 'FILE' : LINENUM, or 'symbol@VERSION'. Ignore
+     any ':' or '.' inside single qoutes.  */

   p = *argptr;
   if (p[0] == '"')
@@ -1014,6 +1016,17 @@ locate_first_half (char **argptr, int *i
     }
   else
     *is_quote_enclosed = 0;
+
+  if (p[0] == '\'')
+    {
+      char *q = p + 1;
+      for (; *q && q[0] != '\''; q++) { }
+      if (q[0] == '\'')
+        q++;
+      else
+        error (_("missing closing quote in command"));
+      p = q;
+    }
   for (; *p; p++)
     {
       if (p[0] == '<')



-- 
Paul Pluzhnikov

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Daniel Jacobowitz]

On Thu, Jun 05, 2008 at 07:14:25PM -0700, Paul Pluzhnikov wrote:
> > If I'm right, that implies that this breaks:
> >
> > (gdb) break 'foo.c':13
> 
> But that is *already* broken:
> 
> (gdb) b t.c:8
> Breakpoint 1 at 0x400308: file t.c, line 8.
> (gdb) b "t.c":8
> Breakpoint 2 at 0x400308: file t.c, line 8.
> (gdb) b 't.c':8
> No source file named t.c'.
> (gdb)

Hmm, how peculiar.

> I can fix that (and I believe it should be fixed), but it appears
> that single and double quotes are treated quite differently in
> linespec.c
> 
> Is there maybe a reason for this?

Hysterical raisins?  This code has a long and messy history.  If you
think it's bad now, you should go find a version before David
Carlton's heroic untangling of it.

> > We need to call locate_first_half to separate the filename from the
> > line number.  There's also the 'foo.c'::staticvar form to worry about.
> 
> That case already works correctly (remember -- variables go through
> totally different path).

So I suppose break 'foo.c'::staticfunc is broken too.

> +
> +  if (p[0] == '\'')
> +    {
> +      char *q = p + 1;
> +      for (; *q && q[0] != '\''; q++) { }
> +      if (q[0] == '\'')
> +        q++;
> +      else
> +        error (_("missing closing quote in command"));
> +      p = q;
> +    }
>    for (; *p; p++)
>      {
>        if (p[0] == '<')
> 

Except, do we really want to keep searching past the single quote?
(I'm not saying you're wrong... too tired to straighten this out
conclusively tonight.)

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[David Miller]

From: "Paul Pluzhnikov" <ppluzhnikov@google.com>
Date: Tue, 13 May 2008 13:51:57 -0700

> On Tue, May 13, 2008 at 1:23 PM, Michael Snyder <msnyder@specifix.com> wrote:
> >
> >  FYI, there's a sort-of work-around...
> 
> That only sort-of-works because there is a matching non-versioned
> symbol. In addition, it's quite annoying for TAB-completion to
> complete the symbol, but the result of completion to then not work.

Right.

I have a related problem right now in that the annota1 and annota3
testcases fail on my machine because all of the printf symbols in
libc are versioned and the one you get with a simple "b printf" is
random and determined by the order in which the symbols get added to
the minsym hashes:

0005b260 T printf@@GLIBC_2.4
001425c0 T printf@GLIBC_2.0

GDB's support for symbol versioning could definitely be improved :-)

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Daniel Jacobowitz]

On Tue, May 13, 2008 at 03:16:26PM -0700, David Miller wrote:
> I have a related problem right now in that the annota1 and annota3
> testcases fail on my machine because all of the printf symbols in
> libc are versioned and the one you get with a simple "b printf" is
> random and determined by the order in which the symbols get added to
> the minsym hashes:
> 
> 0005b260 T printf@@GLIBC_2.4
> 001425c0 T printf@GLIBC_2.0
> 
> GDB's support for symbol versioning could definitely be improved :-)

What's different for SPARC in this regard from other targets?  Is it
lack of a PLT entry (or BFD synthetic symbol for said PLT entry)?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[David Miller]

From: Daniel Jacobowitz <drow@false.org>
Date: Tue, 13 May 2008 19:02:20 -0400

> On Tue, May 13, 2008 at 03:16:26PM -0700, David Miller wrote:
> > I have a related problem right now in that the annota1 and annota3
> > testcases fail on my machine because all of the printf symbols in
> > libc are versioned and the one you get with a simple "b printf" is
> > random and determined by the order in which the symbols get added to
> > the minsym hashes:
> > 
> > 0005b260 T printf@@GLIBC_2.4
> > 001425c0 T printf@GLIBC_2.0
> > 
> > GDB's support for symbol versioning could definitely be improved :-)
> 
> What's different for SPARC in this regard from other targets?  Is it
> lack of a PLT entry (or BFD synthetic symbol for said PLT entry)?

There is a PLT entry, and when I disassemble it it looks like
"printf@plt".

But when I set a breakpoint it gets set on printf@GLIBC_2.0
instead of the correct printf@@GLIBC_2.4

All of my other systems have one non-versioned printf symbol,
so either that is the different or the ordering of the symbols.

Regardless, where does GDB try to generate the correct version
postfix string for a symbol during symbol lookup? :-)

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Daniel Jacobowitz]

On Tue, May 13, 2008 at 06:10:50PM -0700, David Miller wrote:
> > What's different for SPARC in this regard from other targets?  Is it
> > lack of a PLT entry (or BFD synthetic symbol for said PLT entry)?
> 
> There is a PLT entry, and when I disassemble it it looks like
> "printf@plt".
> 
> But when I set a breakpoint it gets set on printf@GLIBC_2.0
> instead of the correct printf@@GLIBC_2.4
> 
> All of my other systems have one non-versioned printf symbol,
> so either that is the different or the ordering of the symbols.

Yes, this is probably an impact of the 128-bit long double transition.
GDB knows how to set multiple breakpoints on functions with debug
info, but not without debug info (a known issue).

> Regardless, where does GDB try to generate the correct version
> postfix string for a symbol during symbol lookup? :-)

True, this would be useful for calling functions.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[David Miller]

From: Daniel Jacobowitz <drow@false.org>
Date: Tue, 13 May 2008 22:46:40 -0400

> On Tue, May 13, 2008 at 06:10:50PM -0700, David Miller wrote:
> > > What's different for SPARC in this regard from other targets?  Is it
> > > lack of a PLT entry (or BFD synthetic symbol for said PLT entry)?
> > 
> > There is a PLT entry, and when I disassemble it it looks like
> > "printf@plt".
> > 
> > But when I set a breakpoint it gets set on printf@GLIBC_2.0
> > instead of the correct printf@@GLIBC_2.4
> > 
> > All of my other systems have one non-versioned printf symbol,
> > so either that is the different or the ordering of the symbols.
> 
> Yes, this is probably an impact of the 128-bit long double transition.
> GDB knows how to set multiple breakpoints on functions with debug
> info, but not without debug info (a known issue).

My case has full debugging information, or at least it should, via
/usr/lib/debug/lib/ultra3/libc-2.6.1.so which is where I got those
above symbols above from.

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[Andreas Schwab]

David Miller <davem@davemloft.net> writes:

> From: Daniel Jacobowitz <drow@false.org>
> Date: Tue, 13 May 2008 22:46:40 -0400
>
>> On Tue, May 13, 2008 at 06:10:50PM -0700, David Miller wrote:
>> > > What's different for SPARC in this regard from other targets?  Is it
>> > > lack of a PLT entry (or BFD synthetic symbol for said PLT entry)?
>> > 
>> > There is a PLT entry, and when I disassemble it it looks like
>> > "printf@plt".
>> > 
>> > But when I set a breakpoint it gets set on printf@GLIBC_2.0
>> > instead of the correct printf@@GLIBC_2.4
>> > 
>> > All of my other systems have one non-versioned printf symbol,
>> > so either that is the different or the ordering of the symbols.
>> 
>> Yes, this is probably an impact of the 128-bit long double transition.
>> GDB knows how to set multiple breakpoints on functions with debug
>> info, but not without debug info (a known issue).
>
> My case has full debugging information, or at least it should, via
> /usr/lib/debug/lib/ultra3/libc-2.6.1.so which is where I got those
> above symbols above from.

There is probably no symbol matching printf in the debugging
information.  That's how it looks like on ppc, where the two versions of
printf are just aliases of the internal names __printf and
__ndbl_printf.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [RFC] Fix for mishandling of "break 'pthread_create@GLIBC_2.2.5'"

[David Miller]

From: Andreas Schwab <schwab@suse.de>
Date: Wed, 14 May 2008 10:07:23 +0200

> There is probably no symbol matching printf in the debugging
> information.  That's how it looks like on ppc, where the two versions of
> printf are just aliases of the internal names __printf and
> __ndbl_printf.

Indeed, that's what causes this.

Thanks for pointing that oout.