From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Tromey To: gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Sat, 10 Jul 1999 11:00:00 -0000 Message-id: <87pv20bd2o.fsf@cygnus.com> References: <000d01bec9c2$06f4fdb0$3404010a@metrowerks.com> <4220.931496340@upchuck.cygnus.com> <19990709100431.A4568@tiktok.cygnus.com> X-SW-Source: 1999-q3/msg00042.html >>>>> "Michael" == Michael Meissner writes: Michael> This is actually a symptom of a much deeper problem that I Michael> would like to see addressed in the compiler at some point, Michael> namely tracking variables being reloaded, etc. For example, Michael> if the compiler determines that a variable is on the stack, Michael> but needs to load up a variable into a register to work on it Michael> (reload in gcc speak), we currently don't track this, so if Michael> you put a breakpoint after the load has been done, but before Michael> it is used, you won't be able to change the value to affect Michael> the running of the program. FWIW this is the also sort of information you need to build tables for a precise garbage collector. A precise GC needs to know when a pointer (even a disguised one) has been loaded into a register, or spilled to the stack. Tom >From malachai@iname.com Sat Jul 10 14:36:00 1999 From: Shawn Halpenny To: gdb@sourceware.cygnus.com Subject: XCOFF support Date: Sat, 10 Jul 1999 14:36:00 -0000 Message-id: <19990710173405.A23094@cs163.humb.nt.com> X-SW-Source: 1999-q3/msg00043.html Content-length: 1133 Since a preliminary search of the mail archives hasn't turned up anything conclusive, I was wondering if anyone has done any work with XCOFF (I'm using xlC 3.1.4 on an AIX 4.2.1 box) to _fully_ support the .stabx symbol table entries. If someone has patches or at least some work in that area I'd be interested in hearing from you. Failing that, some direction on where I should start to add this sort of thing will do. Best of all, of course, would be to be told that "gdb 4.18 (which I'm using) supports that already and you just didn't build it correctly". Specifically, my problem is that all of my attempts to read class/struct data in a C++ object file all come back with "". For the curious, XCOFF is fully described at http://www.rs6000.ibm.com/doc_link/en_US/a_doc_lib/files/aixfiles/XCOFF.htm -- Shawn Halpenny | Maniacal@I Ache, Ohm | "Universal Danger!" +- - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - \ | vi:G3kfM~lxfAPXh~l~2x2FirllpfcxlrifaprmfOX~Xp2hr.lrcelyl2p - - - - - - - -| fU~X~refsPprnlxppri2lxlpr,pFrpprrfaPlpfiprgllxp~3Xlp3l4x >From law@cygnus.com Sat Jul 10 20:07:00 1999 From: Jeffrey A Law To: Jim Blandy Cc: "Ben Combee" , egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Sat, 10 Jul 1999 20:07:00 -0000 Message-id: <546.931649446@upchuck.cygnus.com> References: X-SW-Source: 1999-q3/msg00045.html Content-length: 716 In message < np3dyxu2ua.fsf@zwingli.cygnus.com >you write: > I don't have an MMX manual handy, but it seems like a much easier case > than the FPU, since the registers don't shift around every time you do > an operation. Correct. While the MMX registers are overloaded on the FPU registers, they do not stack like FP operations do. > Well, the reason this problem seems hard to me is exactly because the > position of items relative to the top of the stack *will* change, > whenever you execute instructions like FILD, FDIVP, etc. If they were > a constant distance, then we could simply assign register numbers to > ST(0) -- ST(7) in the usual way, and everything would work. Precisely. jeff >From law@cygnus.com Sat Jul 10 20:07:00 1999 From: Jeffrey A Law To: Jim Blandy Cc: "Ben Combee" , egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Sat, 10 Jul 1999 20:07:00 -0000 Message-id: <430.931648506@upchuck.cygnus.com> References: X-SW-Source: 1999-q3/msg00044.html Content-length: 570 In message < npbtdlsg2i.fsf@zwingli.cygnus.com >you write: > In code generated by your compiler, is the value of TOP (the three-bit > FPU stack pointer) at function entry known at compile time? Or does > its value depend on the caller, and the caller's caller, etc.? Aren't all the FP registers on the x86 considered call-clobbered? If so, then there should be no FP regs live across a function call. With that in mind, the state of the FP stack ought to be empty at the start of each function. Or am I missing something? I'm not really an ia32 guru. jeff >From law@cygnus.com Sat Jul 10 20:08:00 1999 From: Jeffrey A Law To: Jim Blandy Cc: Joern Rennecke , egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Sat, 10 Jul 1999 20:08:00 -0000 Message-id: <400.931648196@upchuck.cygnus.com> References: X-SW-Source: 1999-q3/msg00046.html Content-length: 975 In message < np908psfqu.fsf@zwingli.cygnus.com >you write: > Okay, but do you really want to emit up to eight stabs at every FP > instruction that changes the stack? If that's what it takes to get access to FP variables, yes. Another option would be to set up a stack in the debug symbols and push/pop the debug symbol stack in a manner similar to what we do with the actual FP regstack. There's some serious issues with how we do this portably, but it's worth thinking about. > I dunno --- maybe it's not a big deal. It may not be worth creating a > whole new form of debugging info to save that space. It is certainly > a problem the various LRS representations handle. I'd certainly agree > we should try it first. Compactness of debug symbols hasn't ever been a serious concern. At some point it will need to be addressed though. However, we need to keep in mind this is only an issue for the x86. No other port has this kind of braindamage. jeff >From law@cygnus.com Sat Jul 10 20:09:00 1999 From: Jeffrey A Law To: Jim Blandy Cc: Michael Meissner , Ben Combee , egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Sat, 10 Jul 1999 20:09:00 -0000 Message-id: <383.931648016@upchuck.cygnus.com> References: X-SW-Source: 1999-q3/msg00047.html Content-length: 2146 In message < np673tsfcd.fsf@zwingli.cygnus.com >you write: > > > Also when I first did the LRS changes, I thought that you could do > > LRS debug information in any debug format, including crippled ones > > like COFF, if you were willing to create a new block for every state > > change (ie, variable moving from stack to register). > > I wonder if it's a good idea to abuse blocks this way. If the user > has a function like this: > > foo () > { > { > int a; > ... > } > { > int a; > ... > } > } > > and, while control is in the first inner block, asks the debugger to > monitor the value of 'a' as he steps, it would be nice if the debugger > could tell that the 'a' in the second block is actually a different > variable, and is not the one the user asked about. Yes. This is the only design issue I remember anyone raising for debugging LRS code via block scopes. It's an issue I'm willing to punt on for now if we could get the block scope stuff to work though -- the block scope LRS stuff is very portable if we could deal with the technical issues in the compiler. One possibility might be to try and use the dwarf2 LRS stuff as the first option, then the stabs LRS stuff as a secondary option, then fall back on block scopes for any remaining cases (or if we're trying to avoid using any stabs extensions). > If you use blocks the way you suggest, I'm not sure how GDB could tell > the difference between two separate variables with the same name, and > a single variable which exists in two blocks created to capture > different life ranges. Without some kind of annotation I do not see a way to deal with this problem either. > The STABS LRS stuff, while quirky, doesn't have this problem. If you had the opportunity to redesign the stabs LRS stuff, what would you recommend? One possibility would be to try and model it strictly like ELF works. I do not know how feasible that would be. It would be nice to finally hash through these issues as I'd like to contribute Cygnus's LRS code to egcs in the near future. jeff >From jtc@redback.com Mon Jul 12 10:54:00 1999 From: jtc@redback.com (J.T. Conklin) To: gdb@sourceware.cygnus.com Subject: IA32 FP Date: Mon, 12 Jul 1999 10:54:00 -0000 Message-id: <5m3dyt3gbw.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q3/msg00048.html Content-length: 968 I haven't jumped in on running thread on IA32 FP until now. Although most of the IA32 systems in common use today support FP, only a handful have FP support in GDB. IMO, one of the reasons for this is that the base header, tm-i386.h, has little support for FP registers (NUM_FREGS is 0, no REGISTER_CONVERT_TO_{RAW,VIRTUAL} macros, etc. This may be a good opportunity to address this. At the possible expense of some of the older targets that really don't have any FP support, the target headers for more today's popular systems (*BSD, GNU/Linux, GNU/Hurd, cygwin, embedded, etc.) would be greatly simplified. Plus any breakage would be quite obvious and easy to fix when someone attempts to build those configs. We could try to build cross debuggers for all the IA32 targets, but we might not be successful. I've encountered problems in the past where target headers require native headers, etc. and fail to build. --jtc -- J.T. Conklin RedBack Networks >From jimb@cygnus.com Mon Jul 12 12:29:00 1999 From: Jim Blandy To: Andi Kleen Cc: gdb@sourceware.cygnus.com Subject: Re: Linux changes for GDB Date: Mon, 12 Jul 1999 12:29:00 -0000 Message-id: References: <199907090232.VAA01308@zwingli.cygnus.com> X-SW-Source: 1999-q3/msg00049.html Content-length: 751 > > Then there are some bug fixes: > > - GDB can step into functions in shared libraries correctly. On > > Redhat 5.2, at least, you sometimes end up in `strcmp'. (I need to > > write a test for this one.) > > The main problem on RH5.2 and RH6 seems to be that libc is not > stripped You know, there do exist shared libraries other than libc. And some people even have to debug them! :) I don't think stripping shared libraries is really the way to resolve this problem. > so once you enter a libc function by mistake with 's' you get hundreds > of error messages because of the missing source file. Is there a elegant > fix for that? (e.g. some way to specify to gdb to never look for some > sources) No, I don't have any fix for that. >From jimb@cygnus.com Mon Jul 12 12:44:00 1999 From: Jim Blandy To: jtc@redback.com Cc: gdb@sourceware.cygnus.com Subject: Re: IA32 FP Date: Mon, 12 Jul 1999 12:44:00 -0000 Message-id: References: <5m3dyt3gbw.fsf@jtc.redbacknetworks.com> X-SW-Source: 1999-q3/msg00050.html Content-length: 546 > Although most of the IA32 systems in common use today support FP, > only a handful have FP support in GDB. [...] This may be a good > opportunity to address this. That's exactly what I'm trying to do. My immediate interest is making Linux work, but if we IA32 maintainers talk about it a bit, we can all use the same solution. There's a lot of gratuitous duplication among the gdb/config/i386 headers. (For fun, diff nm-i386v.h and nm-i386sco.h.) So I don't think there's any technical reason we couldn't do a great deal of unification. >From jimb@cygnus.com Mon Jul 12 15:50:00 1999 From: Jim Blandy To: law@cygnus.com Cc: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: LRS in STABS Date: Mon, 12 Jul 1999 15:50:00 -0000 Message-id: References: <383.931648016@upchuck.cygnus.com> X-SW-Source: 1999-q3/msg00051.html Content-length: 2134 > > The STABS LRS stuff, while quirky, doesn't have this problem. > If you had the opportunity to redesign the stabs LRS stuff, what would you > recommend? One possibility would be to try and model it strictly like > ELF works. I do not know how feasible that would be. > > It would be nice to finally hash through these issues as I'd like to > contribute Cygnus's LRS code to egcs in the near future. Tired of doing the merge every month? :) Is there a reason not to merge what we have now into EGCS, aside from its quirkiness? It seems to me like it carries the right information. I would create a new stab type, N_NEWHOME; you put as many of these as needed after an N_[RLP]SYM. I'd use the value of the stab to indicate the beginning of the range, perhaps put the length of the range in its desc, and encode the variable's new home in the name. STABS encodes a variable's home in the stab's type and value. There's no prior art saying how to put the variable's home in a symbol name. But there are really only a few kinds of locations GDB can handle anyway, so this isn't too hard. The value of an N_NEWHOME stab should be relative to the function start, to avoid creating relocs. # The function foo gets x as a parameter on the stack at fp+4. # From .LR3 to .LR5, it lives in register 2. # From .LR6 to .LR7, it lives in register 8. .stabs "x:p1",N_PSYM,0,0,4 .stabs "r2",N_NEWHOME,0,.LR5-.LR3,.LR3-foo .stabs "r8",N_NEWHOME,0,.LR7-.LR6,.LR6-foo That seems much simpler than what's described in gdb/doc/LRS. The drawbacks are: 1) We're inventing a new notation. But if EGCS doesn't like the existing LRS notation, I guess it's inevitable. 2) We avoid putting cruft in EGCS, but GDB acquires new complexity, because it needs to understand both notations, for at least a while. Maybe this isn't necessary, since only GnuPRO GCC produces it, and if someone gets a new GDB, they'll also get a new GCC. 3) We're investing effort in what I thought was a dead notation. We should be implementing Dwarf2 compression in the linker and encouraging people to switch, not adding more garbage to STABS. >From jimb@cygnus.com Mon Jul 12 16:09:00 1999 From: Jim Blandy To: law@cygnus.com Cc: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: IA32: printing FP register variables Date: Mon, 12 Jul 1999 16:09:00 -0000 Message-id: References: <400.931648196@upchuck.cygnus.com> X-SW-Source: 1999-q3/msg00052.html Content-length: 603 Hmm. What other IA32 compilers produce STABS? How do they number FP registers? If GDB can find the base of the FP stack reliably, using the method that Ben Combee suggests, then we don't need LRS at all to describe variables' homes. If we simply number the FP registers relative to the base of the FP stack, their names won't change as insns push and pop FP values. So the only work to be done is: - GCC needs to propage the register/variable association through the stackifier, so it can produce coherent debug output. - GDB needs to use Ben Combee's tactic for finding the base of the stack. >From law@cygnus.com Mon Jul 12 16:23:00 1999 From: Jeffrey A Law To: Jim Blandy Cc: egcs@egcs.cygnus.com, gdb@sourceware.cygnus.com Subject: Re: LRS in STABS Date: Mon, 12 Jul 1999 16:23:00 -0000 Message-id: <9101.931821781@upchuck.cygnus.com> References: X-SW-Source: 1999-q3/msg00053.html Content-length: 3547 In message < npaet1jxf7.fsf@zwingli.cygnus.com >you write: > > It would be nice to finally hash through these issues as I'd like to > > contribute Cygnus's LRS code to egcs in the near future. > > Tired of doing the merge every month? :) It's not so much the merge issues as a desire to get the code available to more folks. It's doing neither Cygnus nor egcs any good sitting in just the Cygnus sources. Both groups benefit from wider distribution of that code. > Is there a reason not to merge what we have now into EGCS, aside from > its quirkiness? It seems to me like it carries the right information. It certainly needs some cleanup. The way we find suitable loops for LRS needs to be using the cfg and code to detect natural loops. I'm not real happy with some of the stuff in final & dbxout. Looking further out, David Miller has been working on a new register allocator which would do LRS internally, which would make much of the stuff Cygnus did obsolete (LRS is better handled by building interference graphs during allocation and splitting in response to register pressure). > I would create a new stab type, N_NEWHOME; you put as many of these as > needed after an N_[RLP]SYM. I'd use the value of the stab to indicate > the beginning of the range, perhaps put the length of the range in its > desc, and encode the variable's new home in the name. > > STABS encodes a variable's home in the stab's type and value. There's > no prior art saying how to put the variable's home in a symbol name. > But there are really only a few kinds of locations GDB can handle > anyway, so this isn't too hard. > > The value of an N_NEWHOME stab should be relative to the function > start, to avoid creating relocs. > > # The function foo gets x as a parameter on the stack at fp+4. > # From .LR3 to .LR5, it lives in register 2. > # From .LR6 to .LR7, it lives in register 8. > .stabs "x:p1",N_PSYM,0,0,4 > .stabs "r2",N_NEWHOME,0,.LR5-.LR3,.LR3-foo > .stabs "r8",N_NEWHOME,0,.LR7-.LR6,.LR6-foo > > That seems much simpler than what's described in gdb/doc/LRS. Seems reasonable to me. It does assume that we know the labels for the ranges potentially before we actually emit code which can be a problem. > The drawbacks are: > 1) We're inventing a new notation. But if EGCS doesn't like the > existing LRS notation, I guess it's inevitable. I wouldn't go quite that far. How about "I think we can do better" :-) > 2) We avoid putting cruft in EGCS, but GDB acquires new complexity, > because it needs to understand both notations, for at least a > while. Maybe this isn't necessary, since only GnuPRO GCC produces > it, and if someone gets a new GDB, they'll also get a new GCC. They would get both in lock step. It would mean objects compiled with older GnuPro compilers could not be debugged with a newer gdb if they had any live range splits. But this is really a Cygnus issue and shouldn't effect what we do for gdb & gcc. If it means Cygnus has to keep some compat code in gdb for a while, we can do that. > 3) We're investing effort in what I thought was a dead notation. We > should be implementing Dwarf2 compression in the linker and > encouraging people to switch, not adding more garbage to STABS. Yup. This is one of the biggest reasons to live with the existing stabs notation and instead spend our time working on getting the dwarf2 range stuff working which is going to require both gcc & gdb work. jeff