This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Hi, Stan. > From: Robert Lipe <robertl@sco.com> > Hi, long time no hear - are you working for SCO now? Yep. After nearly ten years at Digi it was time to go play with different toys. SCO has a Really Nice debugger, but I have too many cerebral macros that emit GDB keystrokes. [ Old dogs, new tricks. ] I'm wagering (hoping!) that I can fix GDB faster than I can learn a new debugger. :-) > How well does it work when you interact with it normally? The list of Poorly, though I just discovered that within the last 20 minutes. > failures suggest that inferior processes aren't actually under much > control. Yes, it does look like the procfs stuff is failing in some non-obvious way. > phenomenon. :-) This is a elf+dwarf1 (currently) target. > > The "1" part in "dwarf1" isn't going to help with C++ results much, > and I'm not sure how much attention it's getting in egcs. Jason and Jim have made their opinion of dwarf1 in EGCS very clear. :-) As of last Friday, I could make this a dwarf-2 target without a lot of bloodshed. OTOH, I could drop in GAS and make this a stabs/dwarf-1/dwarf-2 target with probably even less effort. If I thought that the problem was the debugging info was invalid, I'd probably go that way immediately. > There's a loop near the top of corefile.exp that tries several corefile > name possibilities, this seems worthy of tweaking: I'll investigate. Thanx. > If anyone can offer me hints on where to start looking (Would you guess > these to be dwarf-specific? X86-specific? Unixware-specific? Test > > Probably Unixware, since Linux GDB runs fine (modulo threads and hw > watchpoints :-) ), Ehich, other than GDB interface, are exactly the two features that inspired this exercise. :-) The snapshot I'm using from 970817 doesn't support either of those. > and dwarf errors tend not to cause massive failure, > unless the debug info is entirely missing. I just spun a build on a RH5.2 system. It fared better on a 'make check' with "only" 182 unexpected failures. Details available upon request. Since the procfs looks completely different, this may not be the ideal reference target, but it does boost my confidence that it's not just generic x86 wierdness. > I suppose that wiring in GAS and telling the tests to be built with > '-gstabs' might be the easiest way to [dis]prove that first datapoint. > What's the syntax for doing that in the GDB testsuite? > > To experiment, try a make CFLAGS_FOR_TARGET=-gstabs. A more permanent Thanx for the tip. I have a feeling that focusing on the procfs wierdness is the first order of business. Unfortunately, I come from the land of ptrace and embedded systems so this is all new to me. RJL