[HEADS UP] Merging i386newframe into mailine

[HEADS UP] Merging i386newframe into mailine

[Mark Kettenis]

Folks,

Now that Elena en Michal have tested my i386newframe branch on amd64,
and found it to be in a much better state than mainline, I think I can
seriously consider bringing the new stuff over to mainline.

This will give us:

* Improvements to the prologue analyzer.
* Support for DWARF CFI on i386.

At the cost of:

* Possibly breaking a few unmaintained i386 targets.
* Possibly introducing bugs due to the DWARF CFI code.
* Possibly exposing bugs lurking in the new frame unwinder code.

This might lead to a delay in the GDB 6 release, or might force us to
make a bugfix release pretty soon after the initial 6.0 release.

I think it's worth running these risks, especially since recent
devlopments on Linux/i386 demand DWARF CFI support on the i386.
Therefore I'll do the merge from next Thursday onwards, unless someone
objects.

Mark

Re: [HEADS UP] Merging i386newframe into mailine

[Andrew Cagney]

> Folks,
> 
> Now that Elena en Michal have tested my i386newframe branch on amd64,
> and found it to be in a much better state than mainline, I think I can
> seriously consider bringing the new stuff over to mainline.
> 
> This will give us:
> 
> * Improvements to the prologue analyzer.
> * Support for DWARF CFI on i386.
> 
> At the cost of:
> 
> * Possibly breaking a few unmaintained i386 targets.
> * Possibly introducing bugs due to the DWARF CFI code.
> * Possibly exposing bugs lurking in the new frame unwinder code.
> 
> This might lead to a delay in the GDB 6 release, or might force us to
> make a bugfix release pretty soon after the initial 6.0 release.

Ah, such is life :-)

> I think it's worth running these risks, especially since recent
> devlopments on Linux/i386 demand DWARF CFI support on the i386.
> Therefore I'll do the merge from next Thursday onwards, unless someone
> objects.

It's all marketing :-)

Only the ``early adaptors'' are likely to try a new even release.  The 
more serious users anticipating either 6.0.1 or 6.1.

:-^

Andrew

Re: [HEADS UP] Merging i386newframe into mailine

[Eli Zaretskii]

> Date: Fri, 23 May 2003 18:52:54 +0200 (CEST)
> From: Mark Kettenis <kettenis@chello.nl>
> 
> * Possibly breaking a few unmaintained i386 targets.

Could the DJGPP (a.k.a. go32) target be one of those?

> I think it's worth running these risks, especially since recent
> devlopments on Linux/i386 demand DWARF CFI support on the i386.

OTOH, GDB 6 will have many valuable fixes, and it would be a pity to
deny those features from users of platforms that could be broken by
the merge.

So how about waiting for 6.1 with the merge?

Re: [HEADS UP] Merging i386newframe into mailine

[Mark Kettenis]

   Date: Sat, 24 May 2003 12:53:42 +0300
   From: "Eli Zaretskii" <eliz@elta.co.il>

   > Date: Fri, 23 May 2003 18:52:54 +0200 (CEST)
   > From: Mark Kettenis <kettenis@chello.nl>
   > 
   > * Possibly breaking a few unmaintained i386 targets.

   Could the DJGPP (a.k.a. go32) target be one of those?

AFAICT DJGPP should be fine.  The default debugging format for DJGPP
is still SDB isn't it?  In that case the new DWARF CFI unwinder
wouldn't be used, unless DWARF2 EH info is generated.

The GCC config files seems to suggest that DJGPP also supports DWARF2.
If that indeed works, compiling with -gdwarf-2 would make the DWARF
CFI support kick in.

   > I think it's worth running these risks, especially since recent
   > devlopments on Linux/i386 demand DWARF CFI support on the i386.

   OTOH, GDB 6 will have many valuable fixes, and it would be a pity to
   deny those features from users of platforms that could be broken by
   the merge.

But for some, DWARF CFI support will be a valuable fix :-).

   So how about waiting for 6.1 with the merge?

Hmm, having stuff slightly broken in 6.0 might be more acceptable to
our users than breaking things in 6.1.

Re: [HEADS UP] Merging i386newframe into mailine

[Eli Zaretskii]

> Date: Sat, 24 May 2003 13:27:06 +0200 (CEST)
> From: Mark Kettenis <kettenis@chello.nl>
> 
> AFAICT DJGPP should be fine.  The default debugging format for DJGPP
> is still SDB isn't it?

No, DJGPP uses DWARF2 by default these days.

> The GCC config files seems to suggest that DJGPP also supports DWARF2.
> If that indeed works, compiling with -gdwarf-2 would make the DWARF
> CFI support kick in.

That's good to know, thanks.

Re: [HEADS UP] Merging i386newframe into mailine

[Andrew Cagney]

>> Date: Fri, 23 May 2003 18:52:54 +0200 (CEST)
>> From: Mark Kettenis <kettenis@chello.nl>
>> 
>> * Possibly breaking a few unmaintained i386 targets.
> 
> 
> Could the DJGPP (a.k.a. go32) target be one of those?
> 
> 
>> I think it's worth running these risks, especially since recent
>> devlopments on Linux/i386 demand DWARF CFI support on the i386.
> 
> 
> OTOH, GDB 6 will have many valuable fixes, and it would be a pity to
> deny those features from users of platforms that could be broken by
> the merge.
> 
> So how about waiting for 6.1 with the merge?

(mark, correct?)
I believe any potential i386 problems should be confined to things like 
signal handlers (unwinding through, or from them).

Basic break-main;run functionality should be fine (in fact slightly 
better because the non CFI unwinder was also improved).

Andrw

Re: [HEADS UP] Merging i386newframe into mailine

[Mark Kettenis]

   Date: Mon, 26 May 2003 11:28:33 -0400
   From: Andrew Cagney <ac131313@redhat.com>

   >> Date: Fri, 23 May 2003 18:52:54 +0200 (CEST)
   >> From: Mark Kettenis <kettenis@chello.nl>
   >> 
   >> * Possibly breaking a few unmaintained i386 targets.
   > 
   > 
   > Could the DJGPP (a.k.a. go32) target be one of those?
   > 
   > 
   >> I think it's worth running these risks, especially since recent
   >> devlopments on Linux/i386 demand DWARF CFI support on the i386.
   > 
   > 
   > OTOH, GDB 6 will have many valuable fixes, and it would be a pity to
   > deny those features from users of platforms that could be broken by
   > the merge.
   > 
   > So how about waiting for 6.1 with the merge?

   (mark, correct?)
   I believe any potential i386 problems should be confined to things like 
   signal handlers (unwinding through, or from them).

In general, signal handlers won't have DWARF CFI, at least not yet.
So this should work just as before.

   Basic break-main;run functionality should be fine (in fact slightly 
   better because the non CFI unwinder was also improved).

Yup.  My major concern is that there is CFI out there that triggers
bugs in the CFI unwinder or that's simoly ourtight wrong.
Unfortunately the only way to find out seems to release the code.

So my intention is to bring the code over to newline.  It is a step
forward.  We can always disable the CFI unwinder before the release if
it causes too many problems.

Mark

Re: [HEADS UP] Merging i386newframe into mailine

[Andrew Cagney]

> Yup.  My major concern is that there is CFI out there that triggers
> bugs in the CFI unwinder or that's simoly ourtight wrong.
> Unfortunately the only way to find out seems to release the code.
> 
> So my intention is to bring the code over to newline.  It is a step
> forward.  We can always disable the CFI unwinder before the release if
> it causes too many problems.

A ``set frame cfi [on|off|auto?] would be very helpful.  I think there 
are other ``set frame'' commands but I don't remember what they are.

Andrew

Re: [HEADS UP] Merging i386newframe into mailine

[Mark Kettenis]

   From: Dan Nicolaescu <dann@ics.uci.edu>
   Date: Fri, 23 May 2003 10:45:00 -0700

   Hi!

   First of all thanks for all the great work you have been doing on x86
   debugging!

   Would you mind posting something on the mailing list statement about
   what does this imply WRT debugging frameless code.
   Would this allow GCC to enable -momit-leaf-frame-pointer by default?
   How about -fomit-frame-pointer ?
   Any of this would be great, and probably nobody would mind delaying a
   release if this was going to happen...

Assuming that GCC generates the correct debug info, yes this would
allow GDB to debug -fomit-frame-pointer code.  So this would only work
with -gdwarf-2, or when DWARF2 is the default debug info (which I
think is true for most ELF targets since GCC 3.2).

AFAICT GCC 3.2.2 generates the corredt DWARF CFI info, so backtraces
should work.  However, I'm not sure whether GCC generates the correct
debug info for function arguments and local variables.  Running the
testsuite with -fomit-frame-pointer produces many failures.  However,
this appears to be caused by GDB not finding the correct first line of
a function.

We're not quite there yet :-(.

Mark