Re: RFC: DWARF Extensions for Separate Debug Info Files ("Fission")

2011-09-23 Thread Jason Molenda
On Sep 23, 2011, at 10:58 AM, Cary Coutant wrote: >> The compiler puts DWARF in the .o file, the linker adds some records in the >> executable which help us to understand where files/function/symbols landed >> in the final executable[1]. > > Did you intend to add a footnote? Yeah, I realized

Re: RFC: DWARF Extensions for Separate Debug Info Files ("Fission")

2011-09-22 Thread Jason Molenda
Hi Cary, just one quick clarification - On Sep 22, 2011, at 5:21 PM, Cary Coutant wrote: > Previous Implementations of Separate Debug Information > == > > In the Sun and HP implementations, the debug information in the > relocatable objects sti

Re: Severe problems with vectorizing stuff in 4.0.3 HEAD

2005-10-14 Thread Jason Molenda
On Fri, Oct 14, 2005 at 01:43:03PM -0700, Kean Johnston wrote: > Also, when you say "stack going into main is 16 byte aligned", > what specifically do you mean? that its 16-byte aligned before > the call to main() itself? That at the first insn in main, most > likely a push %ebp, its 16-byte align

Re: Reducing debug info for C++ ctors/dtors

2005-07-11 Thread Jason Molenda
On Mon, Jul 11, 2005 at 09:18:22PM -0400, Daniel Jacobowitz wrote: > Thanks for the explanation. That makes more sense. Personally, if > you're going to do this, I don't see why you're keeping debug info for > methods; either ditch all artificial methods (including defaulted > constructors but n

Re: Reducing debug info for C++ ctors/dtors

2005-07-11 Thread Jason Molenda
On Mon, Jul 11, 2005 at 08:56:36PM -0400, Daniel Jacobowitz wrote: > > However, it is good enough to have > > > > .stabs "Base1:Tt(0,41)=s4x:(0,9),0,32;getx::(0,44)=#(0,41), > > (0,9),(0,43)=*(0,41),(0,36);:_ZN5Base14getxEv;2A.;;",128,0,1,0 > Eh, no. You have just lost any information