public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* Re: macros/2564: 'p siginfo->si_addr' doesn't work anymore
@ 2008-12-10 21:18 Pedro Alves
0 siblings, 0 replies; 6+ messages in thread
From: Pedro Alves @ 2008-12-10 21:18 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
The following reply was made to PR macros/2564; it has been noted by GNATS.
From: Pedro Alves <pedro@codesourcery.com>
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-gnats@sources.redhat.com,
nobody@sources.redhat.com,
gdb-prs@sources.redhat.com
Subject: Re: macros/2564: 'p siginfo->si_addr' doesn't work anymore
Date: Wed, 10 Dec 2008 21:13:57 +0000
Hmmm, weird. I'm trying on pristine sources from today.
(gdb) set debug expression 1
(gdb) p siginfo.si_addr
Dump of expression @ 0xdd0520'
Language c, 19 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 44 ,...............
1 OP_NULL 0 ................
2 <unknown 12531280> 12531280 P6..............
3 OP_VAR_VALUE 44 ,...............
4 STRUCTOP_STRUCT 87 W...............
5 BINOP_LOGICAL_AND 9 ................
6 <unknown 1718186847> 7236270204641702751 _sifields.......
7 BINOP_LOGICAL_AND 9 ................
8 STRUCTOP_STRUCT 87 W...............
9 STRUCTOP_STRUCT 87 W...............
10 BINOP_LOGICAL_AND 9 ................
11 <unknown 1734964063> 7815259820820886367 _sigfault.......
12 BINOP_LOGICAL_AND 9 ................
13 STRUCTOP_STRUCT 87 W...............
14 STRUCTOP_STRUCT 87 W...............
15 BINOP_LSH 7 ................
16 OP_NULL 25263822268792832 ....P.Y.........
17 BINOP_LSH 7 ................
18 STRUCTOP_STRUCT 87 W...............
Dump of expression @ 0xdd0520, after conversion to prefix form:
Expression: `siginfo._sifields._sigfault.'
Language c, 19 elements, 16 bytes each.
0 STRUCTOP_STRUCT Element name: `'
5 STRUCTOP_STRUCT Element name: `_sigfault'
10 STRUCTOP_STRUCT Element name: `_sifields'
15 OP_VAR_VALUE Block @0x0, symbol @0xbf3650 (siginfo)
There is no member named .
(gdb)
Hmmm, I just noticed that if I try enough times, it sometimes
succeeds, which brings us to Valgrind:
(gdb) p siginfo_p->si_addr
==18963==
==18963== Invalid read of size 1
==18963== at 0x4C250A8: memcpy (mc_replace_strmem.c:402)
==18963== by 0x546B36: write_exp_string (parse.c:349)
==18963== by 0x5E2F94: c_parse_internal (c-exp.y:338)
==18963== by 0x5E62FD: c_parse (c-exp.y:1908)
==18963== by 0x5951C4: c_preprocess_and_parse (c-lang.c:286)
==18963== by 0x547B4B: parse_exp_in_context (parse.c:1034)
==18963== by 0x547993: parse_exp_1 (parse.c:972)
==18963== by 0x547C82: parse_expression (parse.c:1084)
==18963== by 0x4EFE36: print_command_1 (printcmd.c:871)
==18963== by 0x4EFFCB: print_command (printcmd.c:921)
==18963== by 0x49DA8B: do_cfunc (cli-decode.c:63)
==18963== by 0x4A06F6: cmd_func (cli-decode.c:1700)
==18963== Address 0x7c583f2 is 26 bytes inside a block of size 36 free'd
==18963== at 0x4C22B2E: free (vg_replace_malloc.c:323)
==18963== by 0x45BC31: xfree (utils.c:1151)
==18963== by 0x595098: finished_macro_expansion (c-lang.c:246)
==18963== by 0x5E5379: c_lex (c-exp.y:1475)
==18963== by 0x5E2B2A: c_parse_internal (c-exp.c.tmp:1785)
==18963== by 0x5E62FD: c_parse (c-exp.y:1908)
==18963== by 0x5951C4: c_preprocess_and_parse (c-lang.c:286)
==18963== by 0x547B4B: parse_exp_in_context (parse.c:1034)
==18963== by 0x547993: parse_exp_1 (parse.c:972)
==18963== by 0x547C82: parse_expression (parse.c:1084)
==18963== by 0x4EFE36: print_command_1 (printcmd.c:871)
==18963== by 0x4EFFCB: print_command (printcmd.c:921)
==18963==
==18963== Invalid read of size 1
==18963== at 0x4C250B1: memcpy (mc_replace_strmem.c:402)
==18963== by 0x546B36: write_exp_string (parse.c:349)
==18963== by 0x5E2F94: c_parse_internal (c-exp.y:338)
==18963== by 0x5E62FD: c_parse (c-exp.y:1908)
==18963== by 0x5951C4: c_preprocess_and_parse (c-lang.c:286)
==18963== by 0x547B4B: parse_exp_in_context (parse.c:1034)
==18963== by 0x547993: parse_exp_1 (parse.c:972)
==18963== by 0x547C82: parse_expression (parse.c:1084)
==18963== by 0x4EFE36: print_command_1 (printcmd.c:871)
==18963== by 0x4EFFCB: print_command (printcmd.c:921)
==18963== by 0x49DA8B: do_cfunc (cli-decode.c:63)
==18963== by 0x4A06F6: cmd_func (cli-decode.c:1700)
==18963== Address 0x7c583f1 is 25 bytes inside a block of size 36 free'd
==18963== at 0x4C22B2E: free (vg_replace_malloc.c:323)
==18963== by 0x45BC31: xfree (utils.c:1151)
==18963== by 0x595098: finished_macro_expansion (c-lang.c:246)
==18963== by 0x5E5379: c_lex (c-exp.y:1475)
==18963== by 0x5E2B2A: c_parse_internal (c-exp.c.tmp:1785)
==18963== by 0x5E62FD: c_parse (c-exp.y:1908)
==18963== by 0x5951C4: c_preprocess_and_parse (c-lang.c:286)
==18963== by 0x547B4B: parse_exp_in_context (parse.c:1034)
==18963== by 0x547993: parse_exp_1 (parse.c:972)
==18963== by 0x547C82: parse_expression (parse.c:1084)
==18963== by 0x4EFE36: print_command_1 (printcmd.c:871)
==18963== by 0x4EFFCB: print_command (printcmd.c:921)
==18963==
==18963== Invalid read of size 1
==18963== at 0x4C250B8: memcpy (mc_replace_strmem.c:402)
==18963== by 0x546B36: write_exp_string (parse.c:349)
==18963== by 0x5E2F94: c_parse_internal (c-exp.y:338)
==18963== by 0x5E62FD: c_parse (c-exp.y:1908)
==18963== by 0x5951C4: c_preprocess_and_parse (c-lang.c:286)
==18963== by 0x547B4B: parse_exp_in_context (parse.c:1034)
==18963== by 0x547993: parse_exp_1 (parse.c:972)
==18963== by 0x547C82: parse_expression (parse.c:1084)
==18963== by 0x4EFE36: print_command_1 (printcmd.c:871)
==18963== by 0x4EFFCB: print_command (printcmd.c:921)
==18963== by 0x49DA8B: do_cfunc (cli-decode.c:63)
==18963== by 0x4A06F6: cmd_func (cli-decode.c:1700)
==18963== Address 0x7c583f0 is 24 bytes inside a block of size 36 free'd
==18963== at 0x4C22B2E: free (vg_replace_malloc.c:323)
==18963== by 0x45BC31: xfree (utils.c:1151)
==18963== by 0x595098: finished_macro_expansion (c-lang.c:246)
==18963== by 0x5E5379: c_lex (c-exp.y:1475)
==18963== by 0x5E2B2A: c_parse_internal (c-exp.c.tmp:1785)
==18963== by 0x5E62FD: c_parse (c-exp.y:1908)
==18963== by 0x5951C4: c_preprocess_and_parse (c-lang.c:286)
==18963== by 0x547B4B: parse_exp_in_context (parse.c:1034)
==18963== by 0x547993: parse_exp_1 (parse.c:972)
==18963== by 0x547C82: parse_expression (parse.c:1084)
==18963== by 0x4EFE36: print_command_1 (printcmd.c:871)
==18963== by 0x4EFFCB: print_command (printcmd.c:921)
==18963==
==18963== Invalid read of size 1
==18963== at 0x4C250BF: memcpy (mc_replace_strmem.c:402)
==18963== by 0x546B36: write_exp_string (parse.c:349)
==18963== by 0x5E2F94: c_parse_internal (c-exp.y:338)
==18963== by 0x5E62FD: c_parse (c-exp.y:1908)
==18963== by 0x5951C4: c_preprocess_and_parse (c-lang.c:286)
==18963== by 0x547B4B: parse_exp_in_context (parse.c:1034)
==18963== by 0x547993: parse_exp_1 (parse.c:972)
==18963== by 0x547C82: parse_expression (parse.c:1084)
==18963== by 0x4EFE36: print_command_1 (printcmd.c:871)
==18963== by 0x4EFFCB: print_command (printcmd.c:921)
==18963== by 0x49DA8B: do_cfunc (cli-decode.c:63)
==18963== by 0x4A06F6: cmd_func (cli-decode.c:1700)
==18963== Address 0x7c583ef is 23 bytes inside a block of size 36 free'd
==18963== at 0x4C22B2E: free (vg_replace_malloc.c:323)
==18963== by 0x45BC31: xfree (utils.c:1151)
==18963== by 0x595098: finished_macro_expansion (c-lang.c:246)
==18963== by 0x5E5379: c_lex (c-exp.y:1475)
==18963== by 0x5E2B2A: c_parse_internal (c-exp.c.tmp:1785)
==18963== by 0x5E62FD: c_parse (c-exp.y:1908)
==18963== by 0x5951C4: c_preprocess_and_parse (c-lang.c:286)
==18963== by 0x547B4B: parse_exp_in_context (parse.c:1034)
==18963== by 0x547993: parse_exp_1 (parse.c:972)
==18963== by 0x547C82: parse_expression (parse.c:1084)
==18963== by 0x4EFE36: print_command_1 (printcmd.c:871)
==18963== by 0x4EFFCB: print_command (printcmd.c:921)
==18963==
==18963== Invalid read of size 1
==18963== at 0x4C250E0: memcpy (mc_replace_strmem.c:402)
==18963== by 0x546B36: write_exp_string (parse.c:349)
==18963== by 0x5E2F94: c_parse_internal (c-exp.y:338)
==18963== by 0x5E62FD: c_parse (c-exp.y:1908)
==18963== by 0x5951C4: c_preprocess_and_parse (c-lang.c:286)
==18963== by 0x547B4B: parse_exp_in_context (parse.c:1034)
==18963== by 0x547993: parse_exp_1 (parse.c:972)
==18963== by 0x547C82: parse_expression (parse.c:1084)
==18963== by 0x4EFE36: print_command_1 (printcmd.c:871)
==18963== by 0x4EFFCB: print_command (printcmd.c:921)
==18963== by 0x49DA8B: do_cfunc (cli-decode.c:63)
==18963== by 0x4A06F6: cmd_func (cli-decode.c:1700)
==18963== Address 0x7c583ee is 22 bytes inside a block of size 36 free'd
==18963== at 0x4C22B2E: free (vg_replace_malloc.c:323)
==18963== by 0x45BC31: xfree (utils.c:1151)
==18963== by 0x595098: finished_macro_expansion (c-lang.c:246)
==18963== by 0x5E5379: c_lex (c-exp.y:1475)
==18963== by 0x5E2B2A: c_parse_internal (c-exp.c.tmp:1785)
==18963== by 0x5E62FD: c_parse (c-exp.y:1908)
==18963== by 0x5951C4: c_preprocess_and_parse (c-lang.c:286)
==18963== by 0x547B4B: parse_exp_in_context (parse.c:1034)
==18963== by 0x547993: parse_exp_1 (parse.c:972)
==18963== by 0x547C82: parse_expression (parse.c:1084)
==18963== by 0x4EFE36: print_command_1 (printcmd.c:871)
==18963== by 0x4EFFCB: print_command (printcmd.c:921)
==18963==
==18963== Invalid read of size 1
==18963== at 0x4C250F0: memcpy (mc_replace_strmem.c:402)
==18963== by 0x546B36: write_exp_string (parse.c:349)
==18963== by 0x5E2F94: c_parse_internal (c-exp.y:338)
==18963== by 0x5E62FD: c_parse (c-exp.y:1908)
==18963== by 0x5951C4: c_preprocess_and_parse (c-lang.c:286)
==18963== by 0x547B4B: parse_exp_in_context (parse.c:1034)
==18963== by 0x547993: parse_exp_1 (parse.c:972)
==18963== by 0x547C82: parse_expression (parse.c:1084)
==18963== by 0x4EFE36: print_command_1 (printcmd.c:871)
==18963== by 0x4EFFCB: print_command (printcmd.c:921)
==18963== by 0x49DA8B: do_cfunc (cli-decode.c:63)
==18963== by 0x4A06F6: cmd_func (cli-decode.c:1700)
==18963== Address 0x7c583ec is 20 bytes inside a block of size 36 free'd
==18963== at 0x4C22B2E: free (vg_replace_malloc.c:323)
==18963== by 0x45BC31: xfree (utils.c:1151)
==18963== by 0x595098: finished_macro_expansion (c-lang.c:246)
==18963== by 0x5E5379: c_lex (c-exp.y:1475)
==18963== by 0x5E2B2A: c_parse_internal (c-exp.c.tmp:1785)
==18963== by 0x5E62FD: c_parse (c-exp.y:1908)
==18963== by 0x5951C4: c_preprocess_and_parse (c-lang.c:286)
==18963== by 0x547B4B: parse_exp_in_context (parse.c:1034)
==18963== by 0x547993: parse_exp_1 (parse.c:972)
==18963== by 0x547C82: parse_expression (parse.c:1084)
==18963== by 0x4EFE36: print_command_1 (printcmd.c:871)
==18963== by 0x4EFFCB: print_command (printcmd.c:921)
$1 = (void *) 0x1
(gdb)
--
Pedro Alves
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: macros/2564: 'p siginfo->si_addr' doesn't work anymore
@ 2008-12-11 18:31 tromey
0 siblings, 0 replies; 6+ messages in thread
From: tromey @ 2008-12-11 18:31 UTC (permalink / raw)
To: gdb-prs, pedro, tromey
Synopsis: 'p siginfo->si_addr' doesn't work anymore
State-Changed-From-To: analyzed->closed
State-Changed-By: tromey
State-Changed-When: Thu Dec 11 18:31:25 2008
State-Changed-Why:
Fix checked in.
http://sourceware.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=2564
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: macros/2564: 'p siginfo->si_addr' doesn't work anymore
@ 2008-12-11 1:14 tromey
0 siblings, 0 replies; 6+ messages in thread
From: tromey @ 2008-12-11 1:14 UTC (permalink / raw)
To: gdb-prs, nobody, pedro, tromey
Synopsis: 'p siginfo->si_addr' doesn't work anymore
Responsible-Changed-From-To: unassigned->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Thu Dec 11 01:14:13 2008
Responsible-Changed-Why:
I'll fix this.
State-Changed-From-To: open->analyzed
State-Changed-By: tromey
State-Changed-When: Thu Dec 11 01:14:13 2008
State-Changed-Why:
Thanks for the valgrind trace.
I've looked into it a bit more. I believe the problem
is due to yacc lookahead. In particular, while expanding
"si_addr", the lexer returns a NAME token for the final
"si_addr". Then the lexer calls finished_macro_expansion,
which frees the expansion string; then it returns an EOF
token. This causes the parser to reduce the final rule,
resulting in a call to write_exp_string, which reads
from the freed memory.
My first thought is that the simplest thing to do would
be to make an obstack during parsing, and simply push
all the intermediate macro expansions onto it.
I suspect this is a latent bug in 6.8, but I don't know
how to trigger it. This example does not work, perhaps
because the parser decides to reduce at different times
(I didn't check that theory).
http://sourceware.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=2564
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: macros/2564: 'p siginfo->si_addr' doesn't work anymore
@ 2008-12-10 19:28 Tom Tromey
0 siblings, 0 replies; 6+ messages in thread
From: Tom Tromey @ 2008-12-10 19:28 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
The following reply was made to PR macros/2564; it has been noted by GNATS.
From: Tom Tromey <tromey@redhat.com>
To: gdb-gnats@sources.redhat.com, nobody@sources.redhat.com,
pedro@codesourcery.com, gdb-prs@sources.redhat.com
Cc:
Subject: Re: macros/2564: 'p siginfo->si_addr' doesn't work anymore
Date: Wed, 10 Dec 2008 12:22:34 -0700
I tried with a recent gdb (updated just now) and I couldn't reproduce:
(gdb) p siginfo.si_addr
$1 = (void *) 0x0
(gdb) p siginfo_p.si_addr
$2 = (void *) 0x0
(gdb) p siginfo->si_addr
$3 = (void *) 0x0
(gdb) p siginfo_p->si_addr
$4 = (void *) 0x0
I used gcc 4.4 for this. gdb did not seem to understand the macro
info emitted by the Fedora 9 system gcc :(
Right now I don't have a theory to explain why it works me but not for
you. It doesn't seem like it could be a compiler difference, since
"info macro" works for you.
Tom
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: macros/2564: 'p siginfo->si_addr' doesn't work anymore
@ 2008-12-10 16:58 Pedro Alves
0 siblings, 0 replies; 6+ messages in thread
From: Pedro Alves @ 2008-12-10 16:58 UTC (permalink / raw)
To: nobody; +Cc: gdb-prs
The following reply was made to PR macros/2564; it has been noted by GNATS.
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-gnats@sources.redhat.com
Cc:
Subject: Re: macros/2564: 'p siginfo->si_addr' doesn't work anymore
Date: Wed, 10 Dec 2008 16:47:10 +0000
Test inline:
#include <signal.h>
#include <string.h>
int
main (int argc, char **argv)
{
struct siginfo info; /* make sure it's not related to var name equal type name. */
struct siginfo siginfo; /* var vs ... */
struct siginfo *siginfo_p = &siginfo; /* ... pointer */
return 0;
}
Some more info:
(gdb) info macro si_addr
Defined at /usr/include/bits/siginfo.h:122
included at /usr/include/signal.h:212
included at /home/pedro/gdb/tests/siginfo_exp.c:1
#define si_addr _sifields._sigfault.si_addr
(gdb)
>/home/pedro/gdb/baseline/build/gdb/gdb ./siginfo_exp
GNU gdb (GDB) 6.8.50.20081210-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".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) start
Temporary breakpoint 1 at 0x400460: file siginfo_exp.c, line 9.
Starting program: /home/pedro/gdb/tests/siginfo_exp
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffe408) at siginfo_exp.c:9
9 struct siginfo *siginfo_p = &siginfo; /* ... pointer */
(gdb) p siginfo
$1 = {si_signo = 1, si_errno = 0, si_code = 0, _sifields = {_pad = {1, 0, 0, 0, 0, 0, 0, 0, 0, 1, -134241448, 32767,
-7296, 32767, -134242304, 32767, 4195034, 0, 0, 0, 1, 0, -139464905, 32767, 0, 0, 134090501, 191}, _kill = {
si_pid = 1, si_uid = 0}, _timer = {si_tid = 1, si_overrun = 0, si_sigval = {sival_int = 0, sival_ptr = 0x0}},
_rt = {si_pid = 1, si_uid = 0, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _sigchld = {si_pid = 1,
si_uid = 0, si_status = 0, si_utime = 0, si_stime = 0}, _sigfault = {si_addr = 0x1}, _sigpoll = {si_band = 1,
si_fd = 0}}}
(gdb) p siginfo_p->si_addr
There is no member named .
(gdb) macro expand siginfo_p->si_addr
expands to: siginfo_p->_sifields._sigfault.si_addr
Manual expansion succeeds, but, (guessing) it seems that when evaluating, GDB is trying to further re-expand the si_addr member of _sigfault, as a macro.
Trying the manually expanded form is no help, since GDB tries to expand si_addr, and doesn't fallback to a real member:
(gdb) p siginfo_p->_sifields._sigfault.si_addr
There is no member named _sifields.
Interestingly, macro expansion when using the '.' operator
instead of the '->' operator behaves differently:
(gdb) p siginfo.si_addr
There is no member named .
(gdb) macro expand siginfo.si_addr
expands to: siginfo.si_addr
Making sure it's not related to var named siginfo and type named siginfo; printing through a variable, with '.' operator:
(gdb) p info.si_addr
There is no member named .
(gdb) macro expand info.si_addr
expands to: info.si_addr
Evaluation seems to have expanded, and hit the same bug as before, but manual expansion fails to even expand the first si_addr.
Making sure its not related to the var type, but to the operator used:
(gdb) p siginfo_p.si_addr
There is no member named .
(gdb) macro expand siginfo_p.si_addr
expands to: siginfo_p.si_addr
This is a regression against 6.8:
(gdb) p siginfo.si_addr
$1 = (void *) 0x1
(gdb) macro expand siginfo_p->si_addr
expands to: siginfo_p->_sifields._sigfault.si_addr
(gdb) p siginfo_p->si_addr
$2 = (void *) 0x1
(gdb)
Although macro expanding with the '.' operator was broken already:
(gdb) macro expand siginfo.si_addr
expands to: siginfo.si_addr
--
Pedro Alves
^ permalink raw reply [flat|nested] 6+ messages in thread
* macros/2564: 'p siginfo->si_addr' doesn't work anymore
@ 2008-12-10 15:48 pedro
0 siblings, 0 replies; 6+ messages in thread
From: pedro @ 2008-12-10 15:48 UTC (permalink / raw)
To: gdb-gnats; +Cc: pedro
>Number: 2564
>Category: macros
>Synopsis: 'p siginfo->si_addr' doesn't work anymore
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Wed Dec 10 15:48:04 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: pedro@codesourcery.com
>Release: gdb HEAD 20081210
>Organization:
>Environment:
Linux orlando 2.6.24-21-generic #1 SMP Tue Oct 21 23:09:30 UTC 2008 x86_64 GNU/Linux
>Description:
Trying to 'print siginfo_p->si_addr' in the attached test fails with:
(gdb) p siginfo_p->si_addr
There is no member named .
Although si_addr is a macro defined as:
#define si_addr _sifields._sigfault.si_addr
This worked on 6.8.
And struct siginfo does have those members.
>How-To-Repeat:
Build with gcc -g3 for the extra macro info.
b main; run; next;
(gdb) p siginfo_p->si_addr
There is no member named .
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/x-csrc; name="siginfo_exp.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="siginfo_exp.c"
I2luY2x1ZGUgPHNpZ25hbC5oPgojaW5jbHVkZSA8c3RyaW5nLmg+CgppbnQKbWFpbiAoaW50IGFy
Z2MsIGNoYXIgKiphcmd2KQp7CiAgc3RydWN0IHNpZ2luZm8gaW5mbzsgLyogbWFrZSBzdXJlIGl0
J3Mgbm90IHJlbGF0ZWQgdG8gdmFyIG5hbWUgZXF1YWwgdHlwZSBuYW1lLiAgKi8KICBzdHJ1Y3Qg
c2lnaW5mbyBzaWdpbmZvOyAvKiB2YXIgdnMgLi4uICovCiAgc3RydWN0IHNpZ2luZm8gKnNpZ2lu
Zm9fcCA9ICZzaWdpbmZvOyAvKiAuLi4gcG9pbnRlciAqLwoKICByZXR1cm4gMDsKfQo=
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-12-11 18:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-12-10 21:18 macros/2564: 'p siginfo->si_addr' doesn't work anymore Pedro Alves
-- strict thread matches above, loose matches on Subject: below --
2008-12-11 18:31 tromey
2008-12-11 1:14 tromey
2008-12-10 19:28 Tom Tromey
2008-12-10 16:58 Pedro Alves
2008-12-10 15:48 pedro
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).