* Register numbers on hppa64 [not found] <200511260253.jAQ2rP7Z021130@hiauly1.hia.nrc.ca> @ 2005-11-26 9:23 ` Randolph Chung 2005-11-26 15:54 ` Mark Kettenis 2005-11-26 17:13 ` John David Anglin 0 siblings, 2 replies; 16+ messages in thread From: Randolph Chung @ 2005-11-26 9:23 UTC (permalink / raw) To: gdb; +Cc: John David Anglin, Joel Brobecker OK, this is a mess....:) Apparently we now have at least three different register numbering schemes for hppa64: 1) gcc "dbx": 0-31: r0-r31 72-135: fr0-fr31 (odd numbers are not used) 60: sar 2) gcc dwarf frame: unity mapping, so: 0-31: r0-r31 32-59: fr4-fr31 60: sar 3) gdb 0-31: r0-r31 32-63: sar, pcoqh, pcsqh, other "special" registers 64-95: fr0-fr31 4) HP compilers ??? Joel, does your GNAT C compiler output something different from the above? :-) Obviously this will not work.... The gdb numbering scheme seems to be there for a long time. I don't know if this is the way HP numbers registers in their debug format. Does anybody have a pointer to this information? I see that in late 2003/early 2004 there was a discussion about archs with mismatched "dbx register numbers" vs "dwarf CFI register numbers" on gcc@gcc.gnu.org and gdb-patches@gcc.gnu.org. Back then the discussion was about ppc64, although i was not quite sure what was the conclusion of those discussions. hppa64 is in a similar situation. Any comments or suggestions on how to sort this out? Should I just change gdb to match what gcc outputs? Should we change gcc to match what gdb expects? (safer?) randolph ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-26 9:23 ` Register numbers on hppa64 Randolph Chung @ 2005-11-26 15:54 ` Mark Kettenis 2005-11-26 16:52 ` Randolph Chung 2005-11-26 17:20 ` John David Anglin 2005-11-26 17:13 ` John David Anglin 1 sibling, 2 replies; 16+ messages in thread From: Mark Kettenis @ 2005-11-26 15:54 UTC (permalink / raw) To: randolph; +Cc: gdb, dave, brobecker > Date: Sat, 26 Nov 2005 15:27:39 +0800 > From: Randolph Chung <randolph@tausq.org> > > OK, this is a mess....:) It's not too bad ;-). > Apparently we now have at least three different register numbering > schemes for hppa64: > > 1) gcc "dbx": > 0-31: r0-r31 > 72-135: fr0-fr31 (odd numbers are not used) > 60: sar gcc/config/pa/pa64-regs.h says: /* How to renumber registers for dbx and gdb. Registers 0 - 31 remain unchanged. Registers 32 - 59 are mapped to 72, 74, 76 ... Register 60 is mapped to 32. */ So it seems that the last line of your list should be: 32: sar > 2) gcc dwarf frame: > unity mapping, so: > 0-31: r0-r31 > 32-59: fr4-fr31 > 60: sar > > 3) gdb > 0-31: r0-r31 > 32-63: sar, pcoqh, pcsqh, other "special" registers > 64-95: fr0-fr31 This is GDB's *internal* register mapping. On some targets we've been careful and made that internal register mapping match the one used by the "standard" compiler/debugger on that target, for most targets this is not the case. > 4) HP compilers > ??? I'm not even sure what debug format HP's 64-bit compilers use. The fact that the dbx mapping is a bit weird, suggests that there has been a system that used stabs with that register mapping once. Not sure if that was HP-UX or the old BSD variant that ran on PA-RISC systems. > Joel, does your GNAT C compiler output something different from the > above? :-) > > Obviously this will not work.... > > The gdb numbering scheme seems to be there for a long time. I don't know > if this is the way HP numbers registers in their debug format. Does > anybody have a pointer to this information? Since it's GDB's internal numbering it's perfectly well possible that the numbering scheme isn't used by any debug format at all. I think it's mostly dictated by the layout of "struct save_state" from HP-UX. Could be that this is the numbering scheme used by HP though. > I see that in late 2003/early 2004 there was a discussion about archs > with mismatched "dbx register numbers" vs "dwarf CFI register numbers" > on gcc@gcc.gnu.org and gdb-patches@gcc.gnu.org. Back then the discussion > was about ppc64, although i was not quite sure what was the conclusion > of those discussions. hppa64 is in a similar situation. Well, the ppc64 situation was a real mess, because the GCC people screwed up, and used *their* internal mapping instead of the officially documented numbers defined in the ELF ABI for DWARF2, and this mapping was also used for GCC's exception handling info (which is based on DWARF2). I'm not sure at all whether the issue has been resolved. For hppa64 the situation is much better since... > Any comments or suggestions on how to sort this out? Should I just > change gdb to match what gcc outputs? Should we change gcc to match what > gdb expects? (safer?) ...we (GDB) are the ones that screwed up. Fortunately it's really easy to fix things. We just need to provide the appropriate xxx_reg_to_regnum functions in the acrhitecture vector. Actually the fix seems to be partly implemented already: there's a #ifdeffed out hppa_dwarf_reg_to_regnum in hppa-linux-tdep.c. I think it should be moved to hppa-tdep.c, and a 64-bit version should be created. Anyway, see i386-tdep.c for a complicated example of how registers are mapped differently for several debugging formats and executable formats. Mark ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-26 15:54 ` Mark Kettenis @ 2005-11-26 16:52 ` Randolph Chung 2005-11-26 17:32 ` Mark Kettenis 2005-11-26 17:34 ` John David Anglin 2005-11-26 17:20 ` John David Anglin 1 sibling, 2 replies; 16+ messages in thread From: Randolph Chung @ 2005-11-26 16:52 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb, dave, brobecker > Well, the ppc64 situation was a real mess, because the GCC people > screwed up, and used *their* internal mapping instead of the > officially documented numbers defined in the ELF ABI for DWARF2, and > this mapping was also used for GCC's exception handling info (which is > based on DWARF2). I'm not sure at all whether the issue has been > resolved. > > For hppa64 the situation is much better since... I thought one of the problems was that because the "dbx" and "dwarf" mappings in gcc are different, it would use the dbx mappings in debug info but the dwarf numbers elsewhere (e.g. for exception handling?). Is that an issue at all? >>Any comments or suggestions on how to sort this out? Should I just >>change gdb to match what gcc outputs? Should we change gcc to match what >>gdb expects? (safer?) > > ...we (GDB) are the ones that screwed up. Fortunately it's really > easy to fix things. We just need to provide the appropriate > xxx_reg_to_regnum functions in the acrhitecture vector. Right, this does work for gcc, but I wonder if I'm breaking HP compiler compatibility (which I cannot test...) > Actually the fix seems to be partly implemented already: there's a > #ifdeffed out hppa_dwarf_reg_to_regnum in hppa-linux-tdep.c. I think > it should be moved to hppa-tdep.c, and a 64-bit version should be > created. I wrote that code... :) but I think it's actually wrong; for 32-bit we have a 1:1 mapping between what gcc outputs for "dbx" register numbers in dwarf debug mode and the gdb internal register numbering, so we shouldn't need this mapping function for 32-bit. > Anyway, see i386-tdep.c for a complicated example of how > registers are mapped differently for several debugging formats and > executable formats. I believe HP compilers for hppa64-hpux also use dwarf; I don't see where the register numbering is documented in the ABI. I can easily implement a hppa64_dwarf_reg_to_regnum method, but I need to know if all hppa64 compilers have the same view of register numbers. randolph ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-26 16:52 ` Randolph Chung @ 2005-11-26 17:32 ` Mark Kettenis 2005-11-26 18:50 ` John David Anglin 2005-11-27 16:30 ` Randolph Chung 2005-11-26 17:34 ` John David Anglin 1 sibling, 2 replies; 16+ messages in thread From: Mark Kettenis @ 2005-11-26 17:32 UTC (permalink / raw) To: randolph; +Cc: gdb, dave, brobecker > Date: Sun, 27 Nov 2005 00:38:27 +0800 > From: Randolph Chung <randolph@tausq.org> > > > Well, the ppc64 situation was a real mess, because the GCC people > > screwed up, and used *their* internal mapping instead of the > > officially documented numbers defined in the ELF ABI for DWARF2, and > > this mapping was also used for GCC's exception handling info (which is > > based on DWARF2). I'm not sure at all whether the issue has been > > resolved. > > > > For hppa64 the situation is much better since... > > I thought one of the problems was that because the "dbx" and "dwarf" > mappings in gcc are different, it would use the dbx mappings in debug > info but the dwarf numbers elsewhere (e.g. for exception handling?). Is > that an issue at all? Oh wait, now I see. I was a bit confused. Yes, the GCC people did screw up. It's silly to use to use a different encoding for DWARF2 CFI than for other DWARF2 sections. > > >>Any comments or suggestions on how to sort this out? Should I just > >>change gdb to match what gcc outputs? Should we change gcc to match what > >>gdb expects? (safer?) > > > > ...we (GDB) are the ones that screwed up. Fortunately it's really > > easy to fix things. We just need to provide the appropriate > > xxx_reg_to_regnum functions in the acrhitecture vector. > > Right, this does work for gcc, but I wonder if I'm breaking HP compiler > compatibility (which I cannot test...) If fixing things for GCC means that we break the HP compilers, we should do so: GDB is part of the GNU project so its primary job should be supporting the GNU compiler, not some proprietary compiler. Unfortunately the encoding used for .debug_frame (proper DWARF CFI) and .eh_frame (GCC's bastardized DWARF CFI used for exception handling) is presumed to be the same in GCC, and changing the .eh_frame encoding in't an option, since that would break binary compatibility for code that uses C++ exception handling. It looks like we need some GCC_DEVELOPERS_DONT_THINK_BEFORE_THEY_CODE_MAP_REG_TO_REGNUM mapping. (sorry Dave) Sigh.... Well, let's call it dwarf2_frame_reg_to_regnum(). > > Actually the fix seems to be partly implemented already: there's a > > #ifdeffed out hppa_dwarf_reg_to_regnum in hppa-linux-tdep.c. I think > > it should be moved to hppa-tdep.c, and a 64-bit version should be > > created. > > I wrote that code... :) but I think it's actually wrong; for 32-bit we > have a 1:1 mapping between what gcc outputs for "dbx" register numbers > in dwarf debug mode and the gdb internal register numbering, so we > shouldn't need this mapping function for 32-bit. No, even for 32-bit stuff there is a mapping: /* How to renumber registers for dbx and gdb. Registers 0 - 31 remain unchanged. Registers 32 - 87 are mapped to 72 - 127 Register 88 is mapped to 32. */ But you're right, it's not right to use this encoding for decoding DWARF CFI since that uses the a different mapping (but that mapping isn't 1:1). Mark ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-26 17:32 ` Mark Kettenis @ 2005-11-26 18:50 ` John David Anglin 2005-11-27 16:30 ` Randolph Chung 1 sibling, 0 replies; 16+ messages in thread From: John David Anglin @ 2005-11-26 18:50 UTC (permalink / raw) To: Mark Kettenis; +Cc: randolph, gdb, brobecker > It looks like we need some > GCC_DEVELOPERS_DONT_THINK_BEFORE_THEY_CODE_MAP_REG_TO_REGNUM mapping. > (sorry Dave) Sigh.... ~ > > I wrote that code... :) but I think it's actually wrong; for 32-bit we > > have a 1:1 mapping between what gcc outputs for "dbx" register numbers > > in dwarf debug mode and the gdb internal register numbering, so we > > shouldn't need this mapping function for 32-bit. > > No, even for 32-bit stuff there is a mapping: > > /* How to renumber registers for dbx and gdb. > > Registers 0 - 31 remain unchanged. > > Registers 32 - 87 are mapped to 72 - 127 > > Register 88 is mapped to 32. */ > > But you're right, it's not right to use this encoding for decoding > DWARF CFI since that uses the a different mapping (but that mapping > isn't 1:1). I believe that we have a 1:1 mapping between gcc's frame and dbx numbers at the moment. I haven't fully thought this through but the save state contains information that we don't currently copy to the frame state. We could record this frame state data if there was a way to restore it. Thus, I don't believe that gcc's sets of frame and dbx registers have to be the same. For example, there is no direct way in gcc to set the floating point status registers. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-26 17:32 ` Mark Kettenis 2005-11-26 18:50 ` John David Anglin @ 2005-11-27 16:30 ` Randolph Chung 1 sibling, 0 replies; 16+ messages in thread From: Randolph Chung @ 2005-11-27 16:30 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb, dave, brobecker > If fixing things for GCC means that we break the HP compilers, we > should do so: GDB is part of the GNU project so its primary job should > be supporting the GNU compiler, not some proprietary compiler. While I do not disagree either from a pragmatic (ability to test) and a philosophical point of view, if somebody who cares speaks up with the required info I think we should try to continue to support the HP compilers. Of course if we cannot get to the required information we shouldn't hold up progress in supporting gcc. > It looks like we need some > GCC_DEVELOPERS_DONT_THINK_BEFORE_THEY_CODE_MAP_REG_TO_REGNUM mapping. > (sorry Dave) Sigh.... > > Well, let's call it dwarf2_frame_reg_to_regnum(). I'll submit a patch to gdb-patches to implement this for hppa64 shortly. randolph ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-26 16:52 ` Randolph Chung 2005-11-26 17:32 ` Mark Kettenis @ 2005-11-26 17:34 ` John David Anglin 1 sibling, 0 replies; 16+ messages in thread From: John David Anglin @ 2005-11-26 17:34 UTC (permalink / raw) To: Randolph Chung; +Cc: mark.kettenis, gdb, brobecker > I believe HP compilers for hppa64-hpux also use dwarf; I don't see where > the register numbering is documented in the ABI. I can easily implement > a hppa64_dwarf_reg_to_regnum method, but I need to know if all hppa64 > compilers have the same view of register numbers. I can't provide a definitive answer but I don't think so. We see debug information in sections like the following: [34] .debug_header PROGBITS 0000000000000000 00004800 0000000000000030 0000000000000000 0 0 4 [35] .debug_gntt PROGBITS 0000000000000028 00004830 00000000000001a0 0000000000000000 0 0 4 [36] .debug_lntt PROGBITS 0000000000001398 000049d0 00000000000018f0 0000000000000000 0 0 4 I think this is a modification of the debug format documented in the 32-bit runtime. At one time, I think there was support for this format in gdb (wdb?). However, the practical use is limited as HP libraries don't contain debug information. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-26 15:54 ` Mark Kettenis 2005-11-26 16:52 ` Randolph Chung @ 2005-11-26 17:20 ` John David Anglin 1 sibling, 0 replies; 16+ messages in thread From: John David Anglin @ 2005-11-26 17:20 UTC (permalink / raw) To: Mark Kettenis; +Cc: randolph, gdb, brobecker > It's not too bad ;-). > > > Apparently we now have at least three different register numbering > > schemes for hppa64: > > > > 1) gcc "dbx": > > 0-31: r0-r31 > > 72-135: fr0-fr31 (odd numbers are not used) > > 60: sar > > gcc/config/pa/pa64-regs.h says: > > /* How to renumber registers for dbx and gdb. > > Registers 0 - 31 remain unchanged. > > Registers 32 - 59 are mapped to 72, 74, 76 ... > > Register 60 is mapped to 32. */ > > So it seems that the last line of your list should be: > > 32: sar Also, gcc register 32 is fr4, so the floating-point registers match the gdb numbers. Odd "floating-point" numbers aren't used. > > 3) gdb > > 0-31: r0-r31 > > 32-63: sar, pcoqh, pcsqh, other "special" registers > > 64-95: fr0-fr31 > > This is GDB's *internal* register mapping. On some targets we've been > careful and made that internal register mapping match the one used by > the "standard" compiler/debugger on that target, for most targets this > is not the case. > > > 4) HP compilers > > ??? > > I'm not even sure what debug format HP's 64-bit compilers use. The > fact that the dbx mapping is a bit weird, suggests that there has been > a system that used stabs with that register mapping once. Not sure if > that was HP-UX or the old BSD variant that ran on PA-RISC systems. I don't think stabs has been used with GCC on hppa64. > Since it's GDB's internal numbering it's perfectly well possible that > the numbering scheme isn't used by any debug format at all. I think > it's mostly dictated by the layout of "struct save_state" from HP-UX. > Could be that this is the numbering scheme used by HP though. That's also my impression. However, since PA 2.0, the layout of "struct save_state" is more complicated. In the 32-bit case, access depends on whether or not UseWideRegs (ssp) is true or not. It's not entirely clear how one would derive an unique numbering. Really, the issue seems to be converting the dbx and frame numbers to gdb's internal numbering. This is a nop for the dbx numbers but not for the frame numbers. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-26 9:23 ` Register numbers on hppa64 Randolph Chung 2005-11-26 15:54 ` Mark Kettenis @ 2005-11-26 17:13 ` John David Anglin 2005-11-26 17:52 ` Mark Kettenis 1 sibling, 1 reply; 16+ messages in thread From: John David Anglin @ 2005-11-26 17:13 UTC (permalink / raw) To: Randolph Chung; +Cc: gdb, brobecker > OK, this is a mess....:) > > Apparently we now have at least three different register numbering > schemes for hppa64: > > 1) gcc "dbx": > 0-31: r0-r31 > 72-135: fr0-fr31 (odd numbers are not used) GCC regno 32 is fr4. fr0 through fr3 aren't known to GCC. So, we actually have: 72, 74, ...: fr4, fr5, ... This appears compatible with the gdb mapping. > 60: sar I believe that sar is 32 in the gcc dbx mapping. > 2) gcc dwarf frame: > unity mapping, so: > 0-31: r0-r31 > 32-59: fr4-fr31 > 60: sar This can't change (at least not easily). This is tied to the allocation of the dwarf_reg_size_table.s The only way this can change is by adding the control and space registers that GCC doesn't currently know about to GCC's register tables. This will impact performance to some extent. There's also no easy way to use these registers as they are mostly priviledged or require special access techniques. > 3) gdb > 0-31: r0-r31 > 32-63: sar, pcoqh, pcsqh, other "special" registers > 64-95: fr0-fr31 > > 4) HP compilers > ??? This doesn't matter since HP uses a proprietary debug format. I believe that the dbx mapping generally corresponds to the ordering used by HP for fp_int_block_t, __reg32_t and __reg64_t in the save state. However, the introduction of PA 2.0 made the save state more complex. See the definition for struct save_state in pa/save_state.h. Thus, numbering compatibility with the save state probably isn't as useful as it once once. > The gdb numbering scheme seems to be there for a long time. I don't know > if this is the way HP numbers registers in their debug format. Does > anybody have a pointer to this information? The current gcc numbering scheme has also been there for a long time. At the moment, I don't see a reason to change the number scheme anywhere. It seems that if there is a problem, it's in gdb (dbx vs. dwarf numbers). Adding unused registers to gcc register tables isn't going to help performance and it might break exception support if code from two GCC versions is linked together. We can define DWARF_FRAME_REGISTERS if we need more frame registers (e.g., to restore the floating-point state or 64-bit registers in 32-bit mode). However, at the moment, the unwind hooks to do this aren't there. One bit in gcc bothers me. If we didn't define DWARF_FRAME_REGNUM (i.e., used the dbx default), it appears we could map the dbx numbers to frame numbers using DWARF2_FRAME_REG_OUT. The two techniques appear redundant unless we actually need to define DWARF2_FRAME_REG_OUT to map dbx numbers to frame numbers (i.e., the documentation is wrong about the numbers being collected using DWARF_FRAME_REGNUM). In the rs6000 sysv4.h case, DWARF_FRAME_REGNUM is also the gcc hard registers but it appears that the ABIs mandate numbers for .debug_frame, so a remapping is needed. In our case, we don't have an ABI... > I see that in late 2003/early 2004 there was a discussion about archs > with mismatched "dbx register numbers" vs "dwarf CFI register numbers" > on gcc@gcc.gnu.org and gdb-patches@gcc.gnu.org. Back then the discussion > was about ppc64, although i was not quite sure what was the conclusion > of those discussions. hppa64 is in a similar situation. I guess this was the result: 2004-01-21 Alan Modra <amodra@bigpond.net.au> * config/rs6000/sysv4.h (DWARF2_FRAME_REG_OUT): Define. * dwarf2out.c (output_cfi): Map regs using DWARF2_FRAME_REG_OUT. * doc/tm.texi (DWARF_FRAME_REGNUM, DWARF2_FRAME_REG_OUT): Document. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-26 17:13 ` John David Anglin @ 2005-11-26 17:52 ` Mark Kettenis 2005-11-26 18:00 ` John David Anglin 0 siblings, 1 reply; 16+ messages in thread From: Mark Kettenis @ 2005-11-26 17:52 UTC (permalink / raw) To: dave; +Cc: randolph, gdb, brobecker > Date: Sat, 26 Nov 2005 11:52:34 -0500 (EST) > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca> > > One bit in gcc bothers me. If we didn't define DWARF_FRAME_REGNUM > (i.e., used the dbx default), it appears we could map the dbx numbers > to frame numbers using DWARF2_FRAME_REG_OUT. The two techniques > appear redundant unless we actually need to define DWARF2_FRAME_REG_OUT > to map dbx numbers to frame numbers (i.e., the documentation is > wrong about the numbers being collected using DWARF_FRAME_REGNUM). > In the rs6000 sysv4.h case, DWARF_FRAME_REGNUM is also the gcc hard > registers but it appears that the ABIs mandate numbers for .debug_frame, > so a remapping is needed. In our case, we don't have an ABI... But we have a de-facto ABI since GCC has been using DBX_REGISTER_NUMBER for all non-CFI DWARF2 output. I never noticed DWARF2_FRAME_REG_OUT before, but it seems to implement a suggestion I made in the ppc64 discussion. Now that it's there I really think you should consider using it for hppa/hppa64 too. Something like #define DWARF2_FRAME_REG_OUT(REGNO, FOR_EH) \ ((FOR_EH) ? (REGNO) : DBX_REGISTER_NUMBER (REGNO) if pa32-reg.h and pa64-reg.h should be enough. Meanwhile, I should get busy and implement the necessary support in gdb to cope with the fact that .debug_frame has a different encoding than .eh_frame. Mark ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-26 17:52 ` Mark Kettenis @ 2005-11-26 18:00 ` John David Anglin 2005-11-26 18:31 ` Mark Kettenis 0 siblings, 1 reply; 16+ messages in thread From: John David Anglin @ 2005-11-26 18:00 UTC (permalink / raw) To: Mark Kettenis; +Cc: randolph, gdb, brobecker > But we have a de-facto ABI since GCC has been using > DBX_REGISTER_NUMBER for all non-CFI DWARF2 output. I never noticed > DWARF2_FRAME_REG_OUT before, but it seems to implement a suggestion I > made in the ppc64 discussion. Now that it's there I really think you > should consider using it for hppa/hppa64 too. Something like > > #define DWARF2_FRAME_REG_OUT(REGNO, FOR_EH) \ > ((FOR_EH) ? (REGNO) : DBX_REGISTER_NUMBER (REGNO) > > if pa32-reg.h and pa64-reg.h should be enough. > > Meanwhile, I should get busy and implement the necessary support in > gdb to cope with the fact that .debug_frame has a different encoding > than .eh_frame. Let me understand, are you saying that .debug_frame has a mix of gcc and dbx register numbers at present (i.e., it contains both cfi and non-cfi data)? If that's the case and it's hard for gdb to tell the difference, then I agree that we should make the above change. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-26 18:00 ` John David Anglin @ 2005-11-26 18:31 ` Mark Kettenis 2005-11-27 4:30 ` John David Anglin 0 siblings, 1 reply; 16+ messages in thread From: Mark Kettenis @ 2005-11-26 18:31 UTC (permalink / raw) To: dave; +Cc: randolph, gdb, brobecker > Date: Sat, 26 Nov 2005 12:52:25 -0500 (EST) > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca> > > > But we have a de-facto ABI since GCC has been using > > DBX_REGISTER_NUMBER for all non-CFI DWARF2 output. I never noticed > > DWARF2_FRAME_REG_OUT before, but it seems to implement a suggestion I > > made in the ppc64 discussion. Now that it's there I really think you > > should consider using it for hppa/hppa64 too. Something like > > > > #define DWARF2_FRAME_REG_OUT(REGNO, FOR_EH) \ > > ((FOR_EH) ? (REGNO) : DBX_REGISTER_NUMBER (REGNO) > > > > if pa32-reg.h and pa64-reg.h should be enough. > > > > Meanwhile, I should get busy and implement the necessary support in > > gdb to cope with the fact that .debug_frame has a different encoding > > than .eh_frame. > > Let me understand, are you saying that .debug_frame has a mix > of gcc and dbx register numbers at present (i.e., it contains > both cfi and non-cfi data)? If that's the case and it's hard > for gdb to tell the difference, then I agree that we should > make the above change. No what I'm saying is that .dwarf_frame uses different register numbers than .debug_info and other .debug_xxx sections. This is awkward and confusing because the same DWARF operations that refer to register numbers are used in both sections but suddenly have a different meaning. Mark ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-26 18:31 ` Mark Kettenis @ 2005-11-27 4:30 ` John David Anglin 2005-11-27 15:10 ` Randolph Chung 0 siblings, 1 reply; 16+ messages in thread From: John David Anglin @ 2005-11-27 4:30 UTC (permalink / raw) To: Mark Kettenis; +Cc: randolph, gdb, brobecker > No what I'm saying is that .dwarf_frame uses different register > numbers than .debug_info and other .debug_xxx sections. This is > awkward and confusing because the same DWARF operations that refer to > register numbers are used in both sections but suddenly have a > different meaning. Ok. If we change the register use in .dwarf_frame, then we are breaking compatibility with previously compiled code. This isn't a big deal under HP-UX (dwarf debugging was totally broken on hppa64 until a recent assembler fix). However, there is a fair bit of installed code running linux. Thus, I would say not change the status quo if the above confusion can be handled. The actual numbers used for the FP registers are obscure and I doubt many people actually care what they are. It's only people maintaining the dwarf code that are likely to get confused. If readelf produced a text rather than numeric representation, then the problem would largely go away. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-27 4:30 ` John David Anglin @ 2005-11-27 15:10 ` Randolph Chung 2005-11-27 16:52 ` John David Anglin 2005-11-27 17:42 ` Mark Kettenis 0 siblings, 2 replies; 16+ messages in thread From: Randolph Chung @ 2005-11-27 15:10 UTC (permalink / raw) To: John David Anglin; +Cc: Mark Kettenis, gdb, brobecker > If we change the register use in .dwarf_frame, then we are breaking > compatibility with previously compiled code. This isn't a big deal > under HP-UX (dwarf debugging was totally broken on hppa64 until a > recent assembler fix). However, there is a fair bit of installed > code running linux. Thus, I would say not change the status quo > if the above confusion can be handled. The actual numbers used for > the FP registers are obscure and I doubt many people actually care > what they are. It's only people maintaining the dwarf code that > are likely to get confused. If readelf produced a text rather than > numeric representation, then the problem would largely go away. If I understand Mark correctly, the suggestion would change the numbering used for dwarf cfi/eh, but not the register numbers emitted for .debug_info, right? FWIW currently on hppa-linux, gdb does not use dwarf cfi for frame unwinding. It's on my list of things to do, but if something need changing in gcc for whatever reason, now is a good time to do it as far as I'm concerned. randolph ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-27 15:10 ` Randolph Chung @ 2005-11-27 16:52 ` John David Anglin 2005-11-27 17:42 ` Mark Kettenis 1 sibling, 0 replies; 16+ messages in thread From: John David Anglin @ 2005-11-27 16:52 UTC (permalink / raw) To: Randolph Chung; +Cc: mark.kettenis, gdb, brobecker > > If we change the register use in .dwarf_frame, then we are breaking > > compatibility with previously compiled code. This isn't a big deal > > under HP-UX (dwarf debugging was totally broken on hppa64 until a > > recent assembler fix). However, there is a fair bit of installed > > code running linux. Thus, I would say not change the status quo > > if the above confusion can be handled. The actual numbers used for > > the FP registers are obscure and I doubt many people actually care > > what they are. It's only people maintaining the dwarf code that > > are likely to get confused. If readelf produced a text rather than > > numeric representation, then the problem would largely go away. > > If I understand Mark correctly, the suggestion would change the > numbering used for dwarf cfi/eh, but not the register numbers emitted > for .debug_info, right? It would change the numbering in .debug_frame but not .eh_frame if I understand correctly. We could change to dbx numbers everwhere but that would have a much more significant on the ABI and make the frame tables for unwinding much larger. The positive side is that it would allow recording more information in the frame state if required. > FWIW currently on hppa-linux, gdb does not use dwarf cfi for frame > unwinding. It's on my list of things to do, but if something need > changing in gcc for whatever reason, now is a good time to do it as far > as I'm concerned. That certainly would provide a test as to whether we are providing the correct call frame information in all cases. I guess there may be problems with unwinding through signal frames with really old kernels. I'm still not convinced that the numbers in gcc need changing. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Register numbers on hppa64 2005-11-27 15:10 ` Randolph Chung 2005-11-27 16:52 ` John David Anglin @ 2005-11-27 17:42 ` Mark Kettenis 1 sibling, 0 replies; 16+ messages in thread From: Mark Kettenis @ 2005-11-27 17:42 UTC (permalink / raw) To: randolph; +Cc: dave, gdb, brobecker > Date: Sun, 27 Nov 2005 23:07:16 +0800 > From: Randolph Chung <randolph@tausq.org> > > > If we change the register use in .dwarf_frame, then we are breaking > > compatibility with previously compiled code. This isn't a big deal > > under HP-UX (dwarf debugging was totally broken on hppa64 until a > > recent assembler fix). However, there is a fair bit of installed > > code running linux. Thus, I would say not change the status quo > > if the above confusion can be handled. The actual numbers used for > > the FP registers are obscure and I doubt many people actually care > > what they are. It's only people maintaining the dwarf code that > > are likely to get confused. If readelf produced a text rather than > > numeric representation, then the problem would largely go away. > > If I understand Mark correctly, the suggestion would change the > numbering used for dwarf cfi/eh, but not the register numbers emitted > for .debug_info, right? Sorry no. I propose to use DWARF2_FRAME_REG_OUT() on hppa and hppa32 to change the register numbers for .dwarf_frame to match the ones in .dwarf_info for ages, and leave .eh_frame alone. We can't change the numbers in .eh_frame because that will break binary compatibility for (C++) exception handling. It's really silly for .dwarf_info and .dwarf_frame to use different register numbers. The fact that on hppa there is no ABI that defines these register numbers doesn't really change the argument I made for powerpc. > FWIW currently on hppa-linux, gdb does not use dwarf cfi for frame > unwinding. It's on my list of things to do, but if something need > changing in gcc for whatever reason, now is a good time to do it as far > as I'm concerned. Indeed, so the impact of changing the register numbers should be small. In addition it doesn't affect the integer registers. Some people might have old object modules around that contain the wrong register numbers, but they'll only affect floating-point registers which probably don't show up in CFI a lot anyway. Mark ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2005-11-27 16:52 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <200511260253.jAQ2rP7Z021130@hiauly1.hia.nrc.ca> 2005-11-26 9:23 ` Register numbers on hppa64 Randolph Chung 2005-11-26 15:54 ` Mark Kettenis 2005-11-26 16:52 ` Randolph Chung 2005-11-26 17:32 ` Mark Kettenis 2005-11-26 18:50 ` John David Anglin 2005-11-27 16:30 ` Randolph Chung 2005-11-26 17:34 ` John David Anglin 2005-11-26 17:20 ` John David Anglin 2005-11-26 17:13 ` John David Anglin 2005-11-26 17:52 ` Mark Kettenis 2005-11-26 18:00 ` John David Anglin 2005-11-26 18:31 ` Mark Kettenis 2005-11-27 4:30 ` John David Anglin 2005-11-27 15:10 ` Randolph Chung 2005-11-27 16:52 ` John David Anglin 2005-11-27 17:42 ` Mark Kettenis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).