OpenCores

OpenCores

Re: gdb: backtrace and single-step?

no use

no use

1/1

no use

no use

Re: gdb: backtrace and single-step? by Unknown on Jan 14, 2004			Not available!
Heiko Panther wrote: [q] I'm currently working on gdb, and I have some problems. One, I don't get a stack backtrace. I digged fairly deep into gdb and found things that are going wrong, still I can't see what needs fixing. Two, I can't do single stepping. This seems to be caused by my code being in ROM. Has anyone done either of these two things successfully? Scott, would single-stepping with ROMmed code be possible?[/q] I assume you're referring to problems experienced with HW and not or1ksim.... I haven't had a problem getting a stack backtrace out of gdb in a long time, so I'm not sure what problem you're having. As someone else noted, if you're using gcc 3.1, you need to compile with -fno-omit-frame-pointer if you want meaningful stack backtraces. (I think the newer versions of gcc have this turned on by default, but I couldn't say for sure, so it may be worth trying.) Single-stepping of ROM-resident code is not possible using the serial-based version of gdb - nor can you put breakpoints in such code. The debugger handles single-stepping and breakpoints in the same way, by temporarily replacing a single instruction in the program with a trap instruction that vectors to the debugger stub code. (The original instruction is restored by the debugger stub when the trap is taken.) There are a few alternatives I can think of: * Implement a target-specific version of gdb designed for use with the OR hardware debug unit via JTAG, which would allow breakpoints (and single-stepping) to be implemented in HW. Obviously, this is a non-trivial effort. I'm not even sure if the OR debug unit is fully implemented. * Use multiple build targets for the same set of code, e.g. when you type 'make' a version of the code is built that links so as to run out of RAM, another is linked to run out of ROM. The former is used for debugging and the latter is a production image (which can not be debugged). * A variant of this is to implement an alternative HW memory map (just for debugging purposes) in which part of the space that is nominally part of ROM in your production unit is actually mapped into RAM some time after boot. This allows you to use the same program code for debugging and production. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: <A HREF="http://www.opencores.org/forums/openrisc/attachments/20040114/0307b03c/attachment.htm">http://www.opencores.org/forums/openrisc/attachments/20040114/0307b03c/attachment.htm</A> Heiko Panther wrote: I'm currently working on gdb, and I have some problems. One, I don't get a stack backtrace. I digged fairly deep into gdb and found things that are going wrong, still I can't see what needs fixing. Two, I can't do single stepping. This seems to be caused by my code being in ROM. Has anyone done either of these two things successfully? Scott, would single-stepping with ROMmed code be possible? I assume you're referring to problems experienced with HW and not or1ksim.... I haven't had a problem getting a stack backtrace out of gdb in a long time, so I'm not sure what problem you're having. As someone else noted, if you're using gcc 3.1, you need to compile with -fno-omit-frame-pointer if you want meaningful stack backtraces. (I think the newer versions of gcc have this turned on by default, but I couldn't say for sure, so it may be worth trying.) Single-stepping of ROM-resident code is not possible using the serial-based version of gdb - nor can you put breakpoints in such code. The debugger handles single-stepping and breakpoints in the same way, by temporarily replacing a single instruction in the program with a trap instruction that vectors to the debugger stub code. (The original instruction is restored by the debugger stub when the trap is taken.) There are a few alternatives I can think of: * Implement a target-specific version of gdb designed for use with the OR hardware debug unit via JTAG, which would allow breakpoints (and single-stepping) to be implemented in HW. Obviously, this is a non-trivial effort. I'm not even sure if the OR debug unit is fully implemented. * Use multiple build targets for the same set of code, e.g. when you type 'make' a version of the code is built that links so as to run out of RAM, another is linked to run out of ROM. The former is used for debugging and the latter is a production image (which can not be debugged). * A variant of this is to implement an alternative HW memory map (just for debugging purposes) in which part of the space that is nominally part of ROM in your production unit is actually mapped into RAM some time after boot. This allows you to use the same program code for debugging and production. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums/openrisc/attachments/20040114/0307b03c/attachment.htm

Re: gdb: backtrace and single-step? by Unknown on Jan 14, 2004			Not available!
[q] I assume you're referring to problems experienced with HW and not or1ksim....[/q] Yes. [q] I haven't had a problem getting a stack backtrace out of gdb in a long time, so I'm not sure what problem you're having. As someone else noted, if you're using gcc 3.1, you need to compile with -fno-omit-frame-pointer if you want meaningful stack backtraces. (I think the newer versions of gcc have this turned on by default, but I couldn't say for sure, so it may be worth trying.)[/q] Weird. Did I overlook something simple? [q] Single-stepping of ROM-resident code is not possible using the serial-based version of gdb - nor can you put breakpoints in such code. The debugger handles single-stepping and breakpoints in the same way, by temporarily replacing a single instruction in the program with a trap instruction that vectors to the debugger stub code. (The original instruction is restored by the debugger stub when the trap is taken.) There are a few alternatives I can think of:[/q] Well actually, there seems to be another way. The debug unit could be programmed from the gdb stub, so that the gdb stub would set hard break points. The OR1200 manual says there is a minimalistic version of the debug unit, which lacks the actual breakpoint registers. I need to look into that more. Damjan, is it a lot of work to add a few breakpoint registers? The address comparator logic is probably missing too. Can you give a figure of what would have to be done? Heiko I assume you're referring to problems experienced with HW and not or1ksim.... Yes. I haven't had a problem getting a stack backtrace out of gdb in a long time, so I'm not sure what problem you're having. As someone else noted, if you're using gcc 3.1, you need to compile with -fno-omit-frame-pointer if you want meaningful stack backtraces. (I think the newer versions of gcc have this turned on by default, but I couldn't say for sure, so it may be worth trying.) Weird. Did I overlook something simple? Single-stepping of ROM-resident code is not possible using the serial-based version of gdb - nor can you put breakpoints in such code. The debugger handles single-stepping and breakpoints in the same way, by temporarily replacing a single instruction in the program with a trap instruction that vectors to the debugger stub code. (The original instruction is restored by the debugger stub when the trap is taken.) There are a few alternatives I can think of: Well actually, there seems to be another way. The debug unit could be programmed from the gdb stub, so that the gdb stub would set hard break points. The OR1200 manual says there is a minimalistic version of the debug unit, which lacks the actual breakpoint registers. I need to look into that more. Damjan, is it a lot of work to add a few breakpoint registers? The address comparator logic is probably missing too. Can you give a figure of what would have to be done? Heiko

Re: gdb: backtrace and single-step? by Unknown on Jan 14, 2004			Not available!
Heiko, the plan originally was to do the full implementatino of the debug unit in the OR1200 as specified by the architecture manual. The thinking was that implementing the whole debug as in the architecture manual is probably too much work for the gain you have from HW breakpoints so we implemented only the basic needed stuff (ie the breakpoints with insns). Thinking now I think the HW breakpoints are in fact easier to implement in the OR1200 RTL. So I'm most willing to do it, or to help if somebody else wants to do it, as long as somebody will do the support in gdb. To summurize, I can implement the full debug in RTL as long as somebody else implements needed support in gdb. regards, Damjan [q] Well actually, there seems to be another way. The debug unit could be programmed from the gdb stub, so that the gdb stub would set hard break points. The OR1200 manual says there is a minimalistic version of the debug unit, which lacks the actual breakpoint registers. I need to look into that more. Damjan, is it a lot of work to add a few breakpoint registers? The address comparator logic is probably missing too. Can you give a figure of what would have to be done? Heiko _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] Heiko, the plan originally was to do the full implementatino of the debug unit in the OR1200 as specified by the architecture manual. The thinking was that implementing the whole debug as in the architecture manual is probably too much work for the gain you have from HW breakpoints so we implemented only the basic needed stuff (ie the breakpoints with insns). Thinking now I think the HW breakpoints are in fact easier to implement in the OR1200 RTL. So I'm most willing to do it, or to help if somebody else wants to do it, as long as somebody will do the support in gdb. To summurize, I can implement the full debug in RTL as long as somebody else implements needed support in gdb. regards, Damjan Well actually, there seems to be another way. The debug unit could be programmed from the gdb stub, so that the gdb stub would set hard break points. The OR1200 manual says there is a minimalistic version of the debug unit, which lacks the actual breakpoint registers. I need to look into that more. Damjan, is it a lot of work to add a few breakpoint registers? The address comparator logic is probably missing too. Can you give a figure of what would have to be done? Heiko _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

Re: gdb: backtrace and single-step? by Unknown on Jan 15, 2004			Not available!
Heiko Panther wrote: [q] Well actually, there seems to be another way. The debug unit could be programmed from the gdb stub, so that the gdb stub would set hard break points. The OR1200 manual says there is a minimalistic version of the debug unit, which lacks the actual breakpoint registers. I need to look into that more.[/q] Yah - actually that's a much better idea than using the JTAG since it could be done w/o modifying the host-side gdb. Of course, you have the usual limitation that there is a finite number of HW breakpoints, but that's better than no breakpoints at all. -Scott Heiko Panther wrote: Well actually, there seems to be another way. The debug unit could be programmed from the gdb stub, so that the gdb stub would set hard break points. The OR1200 manual says there is a minimalistic version of the debug unit, which lacks the actual breakpoint registers. I need to look into that more. Yah - actually that's a much better idea than using the JTAG since it could be done w/o modifying the host-side gdb. Of course, you have the usual limitation that there is a finite number of HW breakpoints, but that's better than no breakpoints at all. -Scott

Re: gdb: backtrace and single-step? by Unknown on Jan 15, 2004			Not available!
[q]> Has anyone done either of these two things successfully? Scott, would > single-stepping with ROMmed code be possible?[/q] As Scott mentioned below, this is not possible without HW based debug unit. [q] There are a few alternatives I can think of: * Implement a target-specific version of gdb designed for use with the OR hardware debug unit via JTAG, which would allow breakpoints (and single-stepping) to be implemented in HW. Obviously, this is a non-trivial effort. I'm not even sure if the OR debug unit is fully implemented.[/q] If I am not wrong everything should be implemented in or1200 (not so sure about this) and gdb, but was never tested. [q] * Use multiple build targets for the same set of code, e.g. when you type 'make' a version of the code is built that links so as to run out of RAM, another is linked to run out of ROM. The former is used for debugging and the latter is a production image (which can not be debugged). * A variant of this is to implement an alternative HW memory map (just for debugging purposes) in which part of the space that is nominally part of ROM in your production unit is actually mapped into RAM some time after boot. This allows you to use the same program code for debugging and production.[/q] Yes something like this should work, if applicable. Everybody was doing it this way, so nobody really needed it. best regards, Marko > Has anyone done either of these two things successfully? Scott, would > single-stepping with ROMmed code be possible? As Scott mentioned below, this is not possible without HW based debug unit. There are a few alternatives I can think of: * Implement a target-specific version of gdb designed for use with the OR hardware debug unit via JTAG, which would allow breakpoints (and single-stepping) to be implemented in HW. Obviously, this is a non-trivial effort. I'm not even sure if the OR debug unit is fully implemented. If I am not wrong everything should be implemented in or1200 (not so sure about this) and gdb, but was never tested. * Use multiple build targets for the same set of code, e.g. when you type 'make' a version of the code is built that links so as to run out of RAM, another is linked to run out of ROM. The former is used for debugging and the latter is a production image (which can not be debugged). * A variant of this is to implement an alternative HW memory map (just for debugging purposes) in which part of the space that is nominally part of ROM in your production unit is actually mapped into RAM some time after boot. This allows you to use the same program code for debugging and production. Yes something like this should work, if applicable. Everybody was doing it this way, so nobody really needed it. best regards, Marko

Re: gdb: backtrace and single-step? by Unknown on Jan 19, 2004			Not available!
Damjan, [q] So I'm most willing to do it, or to help if somebody else wants to do it, as long as somebody will do the support in gdb. To summurize, I can implement the full debug in RTL as long as somebody else implements needed support in gdb.[/q] Cool. I will do the gdb stub implementation for eCos. I don't think gdb itself needs to be changed. Regards, Heiko Damjan, So I'm most willing to do it, or to help if somebody else wants to do it, as long as somebody will do the support in gdb. To summurize, I can implement the full debug in RTL as long as somebody else implements needed support in gdb. Cool. I will do the gdb stub implementation for eCos. I don't think gdb itself needs to be changed. Regards, Heiko

Re: gdb: backtrace and single-step? by Unknown on Jan 19, 2004			Not available!
Heiko, I'd prefer the JTAG target of gdb to be extended with support for HW breakpoint ;-) If I understand you are talking about eCos stub, like the gdb connecting through serial to eCos stub, right? regards, Damjan ----- Original Message ----- From: "Heiko Panther" <<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>>; <<A HREF="mailto:lampret@opencores.org">lampret@opencores.org</A>> Sent: Monday, January 19, 2004 12:06 PM Subject: Re: gdb: backtrace and single-step? [q] Damjan, [q]> So I'm > most willing to do it, or to help if somebody else wants to do it, as[/q] long [q]> as somebody will do the support in gdb. To summurize, I can implement[/q] the [q]> full debug in RTL as long as somebody else implements needed support in[/q] gdb. [q] Cool. I will do the gdb stub implementation for eCos. I don't think gdb itself needs to be changed. Regards, Heiko[/q] Heiko, I'd prefer the JTAG target of gdb to be extended with support for HW breakpoint ;-) If I understand you are talking about eCos stub, like the gdb connecting through serial to eCos stub, right? regards, Damjan ----- Original Message ----- From: "Heiko Panther" heiko.panther@web.de> To: openrisc@opencores.org>; lampret@opencores.org> Sent: Monday, January 19, 2004 12:06 PM Subject: Re: gdb: backtrace and single-step? Damjan, > So I'm > most willing to do it, or to help if somebody else wants to do it, as long > as somebody will do the support in gdb. To summurize, I can implement the > full debug in RTL as long as somebody else implements needed support in gdb. Cool. I will do the gdb stub implementation for eCos. I don't think gdb itself needs to be changed. Regards, Heiko

Re: gdb: backtrace and single-step? by Unknown on Jan 20, 2004			Not available!
Well, I was offering to do it in the gdb stub because I'm on Mac, and don't have a parallel port around. That's why I don't do JTAG... sorry! Heiko [q] I'd prefer the JTAG target of gdb to be extended with support for HW breakpoint ;-) If I understand you are talking about eCos stub, like the gdb connecting through serial to eCos stub, right? regards, Damjan ----- Original Message ----- From: "Heiko Panther" <<A HREF="mailto:heiko.panther@w...">heiko.panther@w...</A> > To: <<A HREF="mailto:openrisc@o...">openrisc@o...</A> >; <<A HREF="mailto:lampret@o...">lampret@o...</A> > Sent: Monday, January 19, 2004 12:06 PM Subject: Re: gdb: backtrace and single-step? [q] Damjan, [q]> So I'm > most willing to do it, or to help if somebody else wants to do it, as[/q] long [q]> as somebody will do the support in gdb. To summurize, I can implement[/q] the [q]> full debug in RTL as long as somebody else implements needed support in[/q] gdb. [q] Cool. I will do the gdb stub implementation for eCos. I don't think gdb itself needs to be changed. Regards, Heiko[/q] [/q] Well, I was offering to do it in the gdb stub because I'm on Mac, and don't have a parallel port around. That's why I don't do JTAG... sorry! Heiko I'd prefer the JTAG target of gdb to be extended with support for HW breakpoint ;-) If I understand you are talking about eCos stub, like the gdb connecting through serial to eCos stub, right? regards, Damjan ----- Original Message ----- From: "Heiko Panther" heiko.panther@w... > To: openrisc@o... >; lampret@o... > Sent: Monday, January 19, 2004 12:06 PM Subject: Re: gdb: backtrace and single-step? Damjan, > So I'm > most willing to do it, or to help if somebody else wants to do it, as long > as somebody will do the support in gdb. To summurize, I can implement the > full debug in RTL as long as somebody else implements needed support in gdb. Cool. I will do the gdb stub implementation for eCos. I don't think gdb itself needs to be changed. Regards, Heiko

no use

no use

1/1

no use

no use

© copyright 1999-2025 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.