[RFA] Enhance stabs reader to better deal with forward references

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFA] Enhance stabs reader to better deal with forward references

Joel Brobecker
Hello,

Yep, you read right, some of us are still stuck with stabs. This is
still being used on pa32-hpux and ppc-aix. The case that concerns us,
this time, is on ppc-aix. Incidentally, we're trying to add support
for DWARF on AIX, and we actually managed to get a first prototype
going, but there are still many many details we need to iron out
before we declare success.

In the meantime, I had this curious failure. We hit this problem
only with an old testcase that uses some code that was given to
us by a customer, so I cannot send you the entire code. What's
interesting, however, is that we're dealing with procedure parameter
of type float. The debugging info looks like this:

        .stabx  "float:t243=r8;4;0;",0,140,0
        [...FOLLOWED by...]
        .stabx  "incomplete:p268=k243",100,130,0

However, the fun starts after the assembler (we use the native
assembler) actually swaps the two stabs. So we end up seeing
in the object file the stabs for incomplete BEFORE the stabs
for type float.

The current stabs reader is not really designed to handle this
case, and one could also argue that this is an assembler bug,
since we could argue that stabs assumes that the entries should
be ordered properly.

Nonetheless, it turned out that adding support for misordered
entries was relatively easy, at the cost of an extra table.

That's not where the fun stops, however. The code handling
const types looks like this:

    case 'k':                   /* Const qualifier on some type (Sun) */
      type = read_type (pp, objfile);
      type = make_cv_type (1, TYPE_VOLATILE (type), type,
                           dbx_lookup_type (typenums));
      break;

In our case, the "make_type" call ended up returning an undefined
type, and then we end up making a "const" copy of that undefined
type when calling "make_cv_type".

The problem is that type 268 (our const type) is "complete", and
no future stabs entry will ammend it. So even though I some handling
for forward references of the kind above, this was not sufficient
because the type attached to our parameter was still an undefined
type.

That's why I modified this part of the code to make the cv type
only when the target type was already defined. Otherwise, we give
up the "const" qualifier and reuse the target type instead. We
know that this target type will be fixed up later, so our parameter
will have a defined type, and we'll be able to print it. We end up
losing the "const" qualifier, but this is still way better than
not having any type at all.

2007-02-08  Joel Brobecker  <[hidden email]>

        * stabsread.c (add_undefined_type): Add extra parameter.
        Now handles nameless types separately.
        (struct nat): New type.
        (noname_undefs, noname_undefs_allocated, noname_undefs_length):
        New static variables.
        (read_type): Update calls to add_undefined_type.
        Do not create an equivalent cv type if the type referenced
        has not been defined yet.
        (add_undefined_type_noname): New function.
        (add_undefined_type_1): Renames from add_undefined_type.
        (cleanup_undefined_types_noname): New function.
        (cleanup_undefined_types_1): Renames cleanup_undefined_types.
        (cleanup_undefined_types): New handles nameless types separately.
        (_initialize_stabsread): Initialize our new static constants.

Tested on ppc-aix and x86-linux, no regression. Fixes the problem at
hand.  OK to apply?

Thanks,
--
Joel

stabs-public3.diff (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFA] Enhance stabs reader to better deal with forward references

Daniel Jacobowitz-2
On Fri, Feb 09, 2007 at 11:41:07AM -0800, Joel Brobecker wrote:

> That's not where the fun stops, however. The code handling
> const types looks like this:
>
>     case 'k':                   /* Const qualifier on some type (Sun) */
>       type = read_type (pp, objfile);
>       type = make_cv_type (1, TYPE_VOLATILE (type), type,
>                            dbx_lookup_type (typenums));
>       break;
>
> In our case, the "make_type" call ended up returning an undefined
> type, and then we end up making a "const" copy of that undefined
> type when calling "make_cv_type".
>
> The problem is that type 268 (our const type) is "complete", and
> no future stabs entry will ammend it. So even though I some handling
> for forward references of the kind above, this was not sufficient
> because the type attached to our parameter was still an undefined
> type.
>
> That's why I modified this part of the code to make the cv type
> only when the target type was already defined. Otherwise, we give
> up the "const" qualifier and reuse the target type instead. We
> know that this target type will be fixed up later, so our parameter
> will have a defined type, and we'll be able to print it. We end up
> losing the "const" qualifier, but this is still way better than
> not having any type at all.

I really don't like this part.  I don't understand it, either.  Why is
the CV type complete?  When the non-qualified type is filled in, that
should automatically fill this in, because of the CV ring.  See the
implementation of replace_type.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: [RFA] Enhance stabs reader to better deal with forward references

Joel Brobecker
> On Fri, Feb 09, 2007 at 11:41:07AM -0800, Joel Brobecker wrote:
> > That's not where the fun stops, however. The code handling
> > const types looks like this:
> >
> >     case 'k':                   /* Const qualifier on some type (Sun) */
> >       type = read_type (pp, objfile);
> >       type = make_cv_type (1, TYPE_VOLATILE (type), type,
> >                            dbx_lookup_type (typenums));
> >       break;
> >
> > In our case, the "make_type" call ended up returning an undefined
> > type, and then we end up making a "const" copy of that undefined
> > type when calling "make_cv_type".
> >
> > The problem is that type 268 (our const type) is "complete", and
> > no future stabs entry will ammend it. So even though I some handling
> > for forward references of the kind above, this was not sufficient
> > because the type attached to our parameter was still an undefined
> > type.
> >
> > That's why I modified this part of the code to make the cv type
> > only when the target type was already defined. Otherwise, we give
> > up the "const" qualifier and reuse the target type instead. We
> > know that this target type will be fixed up later, so our parameter
> > will have a defined type, and we'll be able to print it. We end up
> > losing the "const" qualifier, but this is still way better than
> > not having any type at all.
>
> I really don't like this part.  I don't understand it, either.  Why is
> the CV type complete?  When the non-qualified type is filled in, that
> should automatically fill this in, because of the CV ring.  See the
> implementation of replace_type.

Thanks for the carefule review, Daniel.

I need to get back into this again. I am not familiar with the TYPE_CHAIN
ring so I didn't realize that replace_type should do the work. Looking
at the code in replace_type, there is something I don't understand:

      /* The type length is not a part of the main type.  Update it for each
         type on the variant chain.  */
      chain = ntype;
      do {
        /* Assert that this element of the chain has no address-class bits
           set in its flags.  Such type variants might have type lengths
           which are supposed to be different from the non-address-class
           variants.  This assertion shouldn't ever be triggered because
           symbol readers which do construct address-class variants don't
           call replace_type().  */
        gdb_assert (TYPE_ADDRESS_CLASS_ALL (chain) == 0);
   
 -->    TYPE_LENGTH (ntype) = TYPE_LENGTH (type);
        chain = TYPE_CHAIN (chain);
      } while (ntype != chain);

Shouldn't it be "chain" instead of "ntype" here?

--
Joel
Reply | Threaded
Open this post in threaded view
|

Re: [RFA] Enhance stabs reader to better deal with forward references

Daniel Jacobowitz-2
On Tue, Feb 27, 2007 at 09:48:42PM -0800, Joel Brobecker wrote:
> Shouldn't it be "chain" instead of "ntype" here?

Yes, looks so.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: [RFA] Enhance stabs reader to better deal with forward references

Joel Brobecker
In reply to this post by Daniel Jacobowitz-2
> > That's why I modified this part of the code to make the cv type

> > only when the target type was already defined. Otherwise, we give
> > up the "const" qualifier and reuse the target type instead. We
> > know that this target type will be fixed up later, so our parameter
> > will have a defined type, and we'll be able to print it. We end up
> > losing the "const" qualifier, but this is still way better than
> > not having any type at all.
>
> I really don't like this part.  I don't understand it, either.  Why is
> the CV type complete?  When the non-qualified type is filled in, that
> should automatically fill this in, because of the CV ring.  See the
> implementation of replace_type.
You were right. This is unnecessary. Once I applied the fix to replace_type
(see http://www.sourceware.org/ml/gdb-patches/2007-02/msg00384.html),
I was able to remove this change and still get the proper result.

So here is a new submission of the rest of the changes, left untouched
since the last submission.

2007-02-08  Joel Brobecker  <[hidden email]>

        * stabsread.c (add_undefined_type): Add extra parameter.
        Now handles nameless types separately.
        (struct nat): New type.
        (noname_undefs, noname_undefs_allocated, noname_undefs_length):
        New static variables.
        (read_type): Update calls to add_undefined_type.
        (add_undefined_type_noname): New function.
        (add_undefined_type_1): Renames from add_undefined_type.
        (cleanup_undefined_types_noname): New function.
        (cleanup_undefined_types_1): Renames cleanup_undefined_types.
        (cleanup_undefined_types): New handles nameless types separately.
        (_initialize_stabsread): Initialize our new static constants.

The following patch has been tested on x86-linux with -gstabs+.
OK to apply?

Thanks,
--
Joel

stabsread.c.diff (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFA] Enhance stabs reader to better deal with forward references

Daniel Jacobowitz-2
On Wed, Feb 28, 2007 at 12:12:01PM -0800, Joel Brobecker wrote:

> 2007-02-08  Joel Brobecker  <[hidden email]>
>
>         * stabsread.c (add_undefined_type): Add extra parameter.
>         Now handles nameless types separately.
>         (struct nat): New type.
>         (noname_undefs, noname_undefs_allocated, noname_undefs_length):
>         New static variables.
>         (read_type): Update calls to add_undefined_type.
>         (add_undefined_type_noname): New function.
>         (add_undefined_type_1): Renames from add_undefined_type.
>         (cleanup_undefined_types_noname): New function.
>         (cleanup_undefined_types_1): Renames cleanup_undefined_types.
>         (cleanup_undefined_types): New handles nameless types separately.
>         (_initialize_stabsread): Initialize our new static constants.
>
> The following patch has been tested on x86-linux with -gstabs+.
> OK to apply?

This is OK.

> +/* Make a list of nameless type that are undefined.

"types"

> +   In practice, we actually maintain two such list: The first list

"lists"

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: [RFA] Enhance stabs reader to better deal with forward references

Joel Brobecker
> > 2007-02-08  Joel Brobecker  <[hidden email]>
> >
> >         * stabsread.c (add_undefined_type): Add extra parameter.
> >         Now handles nameless types separately.
> >         (struct nat): New type.
> >         (noname_undefs, noname_undefs_allocated, noname_undefs_length):
> >         New static variables.
> >         (read_type): Update calls to add_undefined_type.
> >         (add_undefined_type_noname): New function.
> >         (add_undefined_type_1): Renames from add_undefined_type.
> >         (cleanup_undefined_types_noname): New function.
> >         (cleanup_undefined_types_1): Renames cleanup_undefined_types.
> >         (cleanup_undefined_types): New handles nameless types separately.
> >         (_initialize_stabsread): Initialize our new static constants.
> >
> > The following patch has been tested on x86-linux with -gstabs+.
> > OK to apply?
>
> This is OK.

Thanks, Daniel. Now checked in after fixing the errors you pointed out.

--
Joel
Reply | Threaded
Open this post in threaded view
|

Re: [RFA] Enhance stabs reader to better deal with forward references

pedro_alves (Bugzilla)
Hi,

Joel Brobecker wrote:

>>> 2007-02-08  Joel Brobecker  <[hidden email]>
>>>
>>>         * stabsread.c (add_undefined_type): Add extra parameter.
>>>         Now handles nameless types separately.
>>>         (struct nat): New type.
>>>         (noname_undefs, noname_undefs_allocated, noname_undefs_length):
>>>         New static variables.
>>>         (read_type): Update calls to add_undefined_type.
>>>         (add_undefined_type_noname): New function.
>>>         (add_undefined_type_1): Renames from add_undefined_type.
>>>         (cleanup_undefined_types_noname): New function.
>>>         (cleanup_undefined_types_1): Renames cleanup_undefined_types.
>>>         (cleanup_undefined_types): New handles nameless types separately.
>>>         (_initialize_stabsread): Initialize our new static constants.
>>>
>>>      

Unfortunatelly, this patch broke Cygwin, which still uses stabs by default.

I am getting a SIGSEGV while issuing a breakpoint.
Here is a backtrace showing the problem.

(current_objfile is NULL on the SIGSEGV)

(I love these gdb in gdb in gdb in gdb thingies :) )

 >/usr/bin/gdb --args /usr/local/bin/gdb --args /usr/local/bin/gdb
./main.exe 5404
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) r
Starting program: /usr/local/bin/gdb.exe --args /usr/local/bin/gdb
./main.exe 5404
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/bin/cygexpat-0.dll
Loaded symbols for /usr/bin/cygiconv-2.dll
Loaded symbols for /usr/bin/cygintl-8.dll
Loaded symbols for /usr/bin/cygncurses-8.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/user32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/gdi32.dll
GNU gdb 6.6.50.20070329-cvs
Copyright (C) 2007 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) b win32_attach

Program received signal SIGSEGV, Segmentation fault.
0x004e003f in dbx_lookup_type (typenums=0x22c110) at
../../gdb-server_submit/src/gdb/stabsread.c:293
293           if (real_filenum >= N_HEADER_FILES (current_objfile))
(gdb)
#0  0x004e003f in dbx_lookup_type (typenums=0x22c110) at
../../gdb-server_submit/src/gdb/stabsread.c:293
#1  0x004e7769 in cleanup_undefined_types_noname () at
../../gdb-server_submit/src/gdb/stabsread.c:4259
#2  0x004e7933 in cleanup_undefined_types () at
../../gdb-server_submit/src/gdb/stabsread.c:4346
#3  0x00539e5b in end_symtab (end_addr=4269324, objfile=0x10075fe0,
section=0)
    at ../../gdb-server_submit/src/gdb/buildsym.c:896
#4  0x00502334 in read_ofile_symtab (pst=0x1014e258) at
../../gdb-server_submit/src/gdb/dbxread.c:2625
#5  0x00501ceb in dbx_psymtab_to_symtab_1 (pst=0x1014e258) at
../../gdb-server_submit/src/gdb/dbxread.c:2380
#6  0x00501c62 in dbx_psymtab_to_symtab_1 (pst=0x100f0058) at
../../gdb-server_submit/src/gdb/dbxread.c:2366
#7  0x00501e0e in dbx_psymtab_to_symtab (pst=0x100f0058) at
../../gdb-server_submit/src/gdb/dbxread.c:2431
#8  0x004044fe in psymtab_to_symtab (pst=0x100f0058) at
../../gdb-server_submit/src/gdb/symfile.c:287
#9  0x004667a5 in lookup_symbol_aux_psymtabs (block_index=1,
name=0x22c400 "win32_attach", linkage_name=0x0,
    domain=VAR_DOMAIN, symtab=0x0) at
../../gdb-server_submit/src/gdb/symtab.c:1368
#10 0x004664c7 in lookup_symbol_aux (name=0x22c400 "win32_attach",
linkage_name=0x0, block=0x0,
    domain=VAR_DOMAIN, language=language_c, is_a_field_of_this=0x0,
symtab=0x0)
    at ../../gdb-server_submit/src/gdb/symtab.c:1227
#11 0x004662fe in lookup_symbol_in_language (name=0x22c400
"win32_attach", block=0x0, domain=VAR_DOMAIN,
    lang=language_c, is_a_field_of_this=0x0, symtab=0x0) at
../../gdb-server_submit/src/gdb/symtab.c:1133
#12 0x00466367 in lookup_symbol (name=0x22c400 "win32_attach",
block=0x0, domain=VAR_DOMAIN,
    is_a_field_of_this=0x0, symtab=0x0) at
../../gdb-server_submit/src/gdb/symtab.c:1154
#13 0x004c6579 in find_imps (symtab=0x0, block=0x0, method=0x10033f3a
"win32_attach", syms=0x0, nsym=0x22c49c,
    ndebug=0x22c498) at ../../gdb-server_submit/src/gdb/objc-lang.c:1438
#14 0x0048fb17 in decode_objc (argptr=0x22c750, funfirstline=1,
file_symtab=0x0, canonical=0x22c6dc,
    saved_arg=0x10033f3a "win32_attach") at
../../gdb-server_submit/src/gdb/linespec.c:1103
#15 0x0048f377 in decode_line_1 (argptr=0x22c750, funfirstline=1,
default_symtab=0x0, default_line=0,
    canonical=0x22c6dc, not_found_ptr=0x22c6ac) at
../../gdb-server_submit/src/gdb/linespec.c:728
#16 0x0044118e in parse_breakpoint_sals (address=0x22c750,
sals=0x22c720, addr_string=0x22c6dc,
    not_found_ptr=0x22c6ac) at
../../gdb-server_submit/src/gdb/breakpoint.c:5185
#17 0x0044129e in do_captured_parse_breakpoint (ui=0x100696e0,
data=0x22c6c0)
    at ../../gdb-server_submit/src/gdb/breakpoint.c:5247
#18 0x00412d7c in catch_exception (uiout=0x100696e0, func=0x441267
<do_captured_parse_breakpoint>,
    func_args=0x22c6c0, mask=6) at
../../gdb-server_submit/src/gdb/exceptions.c:469
#19 0x00441362 in break_command_1 (arg=0x10033f3a "win32_attach",
flag=0, from_tty=1, pending_bp=0x0)
    at ../../gdb-server_submit/src/gdb/breakpoint.c:5292
#20 0x00441fb5 in break_command (arg=0x10033f3a "win32_attach", from_tty=1)
    at ../../gdb-server_submit/src/gdb/breakpoint.c:5660
#21 0x0042ca8b in do_cfunc (c=0x10049ca8, args=0x10033f3a
"win32_attach", from_tty=1)
    at ../../gdb-server_submit/src/gdb/cli/cli-decode.c:62
#22 0x0042ef7d in cmd_func (cmd=0x10049ca8, args=0x10033f3a
"win32_attach", from_tty=1)
    at ../../gdb-server_submit/src/gdb/cli/cli-decode.c:1666
#23 0x004025b8 in execute_command (p=0x10033f45 "h", from_tty=1) at
../../gdb-server_submit/src/gdb/top.c:451
#24 0x00424422 in command_handler (command=0x10033f38 "b win32_attach")
    at ../../gdb-server_submit/src/gdb/event-top.c:519
#25 0x00424be4 in command_line_handler (rl=0x1012e3d0 "") at
../../gdb-server_submit/src/gdb/event-top.c:804
#26 0x00424d38 in gdb_readline2 (client_data=0x0) at
../../gdb-server_submit/src/gdb/event-top.c:884
#27 0x004242cc in stdin_event_handler (error=0, client_data=0x0)
    at ../../gdb-server_submit/src/gdb/event-top.c:432
#28 0x004394be in handle_file_event (event_file_desc=0) at
../../gdb-server_submit/src/gdb/event-loop.c:730
#29 0x00438d42 in process_event () at
../../gdb-server_submit/src/gdb/event-loop.c:343
#30 0x00438d8b in gdb_do_one_event (data=0x0) at
../../gdb-server_submit/src/gdb/event-loop.c:380
#31 0x00412f9b in catch_errors (func=0x438d57 <gdb_do_one_event>,
func_args=0x0, errstring=0x649101 "", mask=6)
    at ../../gdb-server_submit/src/gdb/exceptions.c:515
#32 0x004a2f2b in tui_command_loop (data=0x0) at
../../gdb-server_submit/src/gdb/tui/tui-interp.c:151
#33 0x0041c96a in current_interp_command_loop () at
../../gdb-server_submit/src/gdb/interps.c:278
#34 0x004010cb in captured_command_loop (data=0x0) at
../../gdb-server_submit/src/gdb/main.c:101
#35 0x00412f9b in catch_errors (func=0x4010c0 <captured_command_loop>,
func_args=0x0, errstring=0x61a139 "",
    mask=6) at ../../gdb-server_submit/src/gdb/exceptions.c:515
#36 0x00402110 in captured_main (data=0x22cc70) at
../../gdb-server_submit/src/gdb/main.c:867
#37 0x00412f9b in catch_errors (func=0x401102 <captured_main>,
func_args=0x22cc70, errstring=0x61a139 "",
    mask=6) at ../../gdb-server_submit/src/gdb/exceptions.c:515
#38 0x00402146 in gdb_main (args=0x22cc70) at
../../gdb-server_submit/src/gdb/main.c:876
#39 0x004010ba in main (argc=5, argv=0x10033c40) at
../../gdb-server_submit/src/gdb/gdb.c:35

I didn't look much into the code, but the attached works for me.

Cheers,
Pedro Alves


2007-03-31  Pedro Alves  <[hidden email]>

        * dbxread.c (read_ofile_symtab): Move current_objfile
        clearing to after end_stabs.
---
 gdb/dbxread.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: src/gdb/dbxread.c
===================================================================
--- src.orig/gdb/dbxread.c 2005-12-17 21:34:00.000000000 +0000
+++ src/gdb/dbxread.c 2007-03-31 21:31:42.000000000 +0100
@@ -2608,8 +2608,6 @@ read_ofile_symtab (struct partial_symtab
  }
     }
 
-  current_objfile = NULL;
-
   /* In a Solaris elf file, this variable, which comes from the
      value of the N_SO symbol, will still be 0.  Luckily, text_offset,
      which comes from pst->textlow is correct. */
@@ -2625,6 +2623,8 @@ read_ofile_symtab (struct partial_symtab
   pst->symtab = end_symtab (text_offset + text_size, objfile, SECT_OFF_TEXT (objfile));
 
   end_stabs ();
+
+  current_objfile = NULL;
 }
 
 
Reply | Threaded
Open this post in threaded view
|

Re: [RFA] Enhance stabs reader to better deal with forward references

Joel Brobecker
Pedro,

> Unfortunatelly, this patch broke Cygwin, which still uses stabs by default.
>
> I am getting a SIGSEGV while issuing a breakpoint.

Thanks for the report, and sorry about that. Unfortunately, I won't have
much time in the next two or three days - I might be able to understand
what is actually from the backtrace and your patch, but it might not be
sufficient. And if you have an opportunity to investigate a bit more,
that would be very much appreciated.  In the meantime, feel free to back
the patch out if necessary.

--
Joel
Reply | Threaded
Open this post in threaded view
|

RE: [RFA] Enhance stabs reader to better deal with forward references

Pierre Muller (IMAP)
  I made the same change to my local repository,
due to the same problem, on the same target.

  The problem is that in the CVS tree, end_symtab function
is called from within the read_ofile_symtab function
after current_objfile is reset to nil.
  But due to your change, current_objfile is still
accessed inside dbx_lookup_type (stabsread.c)
called by cleanup_undefined_types_noname (stabsread.c)
called by cleanup_undefined_types (stabsread.c)
called by end_symtab (buildsym.c).


Hope this helps,

Pierre

-----Message d'origine-----
De : [hidden email]
[mailto:[hidden email]] De la part de Joel Brobecker
Envoyé : Monday, April 02, 2007 9:00 AM
À : Pedro Alves
Cc : [hidden email]
Objet : Re: [RFA] Enhance stabs reader to better deal with forward
references

Pedro,

> Unfortunatelly, this patch broke Cygwin, which still uses stabs by
default.
>
> I am getting a SIGSEGV while issuing a breakpoint.

Thanks for the report, and sorry about that. Unfortunately, I won't have
much time in the next two or three days - I might be able to understand
what is actually from the backtrace and your patch, but it might not be
sufficient. And if you have an opportunity to investigate a bit more,
that would be very much appreciated.  In the meantime, feel free to back
the patch out if necessary.

--
Joel



Reply | Threaded
Open this post in threaded view
|

Re: [RFA] Enhance stabs reader to better deal with forward references

Daniel Jacobowitz-2
In reply to this post by pedro_alves (Bugzilla)
On Sat, Mar 31, 2007 at 09:41:56PM +0100, Pedro Alves wrote:
> 2007-03-31  Pedro Alves  <[hidden email]>
>
> * dbxread.c (read_ofile_symtab): Move current_objfile
> clearing to after end_stabs.

This is OK.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: [RFA] Enhance stabs reader to better deal with forward references

pedro_alves (Bugzilla)
Daniel Jacobowitz wrote:

> On Sat, Mar 31, 2007 at 09:41:56PM +0100, Pedro Alves wrote:
>  
>> 2007-03-31  Pedro Alves  <[hidden email]>
>>
>> * dbxread.c (read_ofile_symtab): Move current_objfile
>> clearing to after end_stabs.
>>    
>
> This is OK.
>  

Committed after making sure no there are no regressions on
head, on Cygwin, compared to a checkout from just before
Joel's patch was applied.

Cheers,
Pedro Alves



Reply | Threaded
Open this post in threaded view
|

Re: [RFA] Enhance stabs reader to better deal with forward references

Christopher Faylor-9
On Tue, Apr 03, 2007 at 01:13:32AM +0100, Pedro Alves wrote:

>Daniel Jacobowitz wrote:
>>On Sat, Mar 31, 2007 at 09:41:56PM +0100, Pedro Alves wrote:
>>  
>>>2007-03-31  Pedro Alves  <[hidden email]>
>>>
>>> * dbxread.c (read_ofile_symtab): Move current_objfile
>>> clearing to after end_stabs.
>>>    
>>
>>This is OK.
>
>Committed after making sure no there are no regressions on
>head, on Cygwin, compared to a checkout from just before
>Joel's patch was applied.

Cygwin thanks you, Pedro.

cgf