I noticed there is no support for a disassembler except for BedBug.
I am working on a new processor and board for that processor. I'm in need of a disassembler for this work.
I was thinking about adding a cmd_dis.c file as a stub and make the implementation exist in board/..
Is this the right way to go as we are willing to release our code back to the community once it is completed. Ideas/comments about this are appreciated.
-brad w.
Hi Brad,
On Thu, 16 May 2013 10:45:47 -0600, Brad Walker bwalker@musings.com wrote:
I noticed there is no support for a disassembler except for BedBug.
I am working on a new processor and board for that processor. I'm in need of a disassembler for this work.
I was thinking about adding a cmd_dis.c file as a stub and make the implementation exist in board/..
Is this the right way to go as we are willing to release our code back to the community once it is completed. Ideas/comments about this are appreciated.
There is little too no point in having a disassembler command in U-Boot, when one can usually talk to the target with a debugging probe that will work with gdb, and thus allow using gdd's own disassembler.
(also, out of the target, objdump can disassemble an ELF binary)
The best location IMO for putting the disassembler is by adding support for your new processor to gcc/gdb/objdump so that you have it not only for U-Boot but for any other code you care to build for this processor.
-brad w.
Amicalement,
Dear Brad Walker,
In message CAPKZHbVOpoLNHAsjfwyEi9783zgYbfNuf9_GZ=AVuXTmEwSy_g@mail.gmail.com you wrote:
I am working on a new processor and board for that processor. I'm in need of a disassembler for this work.
And why exactly do you need that on the target?
Why cannot you just use objdump ?
Best regards,
Wolfgang Denk
Sorry for being delayed on getting back to you on this. Work issues took hold.
There were several good questions.
Let me give you some background.
I am working at a start-up. We are building a new processor and system for that new processor. So we have hardware work and software work to get through.
Part of my reasoning in asking the question about a disassembler is becuase there is a reference to BedBug in the manual. http://www.denx.de/wiki/view/U-Bootdoc/BedbugEmbeddedDebuggerCommands . As well as, the BedBug debugger is in the source code.
So I'm trying to understand at a high level if I can utilize this work to help me. Or should I just go and implement this independently.
Why not just use JTAG? We are doing new processor design, so it's not defined if the system will even have a JTAG interface. There are lots of systems that do not have a JTAG interface.
Why not use use objdump? We are in the process of porting binutils, so I currently don't have an objdump to use. I do have a manual disassembly routine that we created in h/w design to help us. But, until binutils has been ported, there is no objdump.
I think the big issue that is confusing to me is why is BedBug still in U-Boot? Should i try and graft my work into BedBug? If so, then I'm happy to do the work and contribute it back to the group. But, if not, then I'll just go ahead implement the work independently.
Hopefully, this makes sense. Feel free to ask questions.
-brad w.
On Thu, May 16, 2013 at 4:15 PM, Wolfgang Denk wd@denx.de wrote:
Dear Brad Walker,
In message <CAPKZHbVOpoLNHAsjfwyEi9783zgYbfNuf9_GZ= AVuXTmEwSy_g@mail.gmail.com> you wrote:
I am working on a new processor and board for that processor. I'm in need of a disassembler for this work.
And why exactly do you need that on the target?
Why cannot you just use objdump ?
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing.
Hi Brad,
On Thu, 23 May 2013 11:13:53 -0600, Brad Walker bwalker@musings.com wrote:
Sorry for being delayed on getting back to you on this. Work issues took hold.
There were several good questions.
Let me give you some background.
I am working at a start-up. We are building a new processor and system for that new processor. So we have hardware work and software work to get through.
Part of my reasoning in asking the question about a disassembler is becuase there is a reference to BedBug in the manual. http://www.denx.de/wiki/view/U-Bootdoc/BedbugEmbeddedDebuggerCommands . As well as, the BedBug debugger is in the source code.
So I'm trying to understand at a high level if I can utilize this work to help me. Or should I just go and implement this independently.
Why not just use JTAG? We are doing new processor design, so it's not defined if the system will even have a JTAG interface. There are lots of systems that do not have a JTAG interface.
Why not use use objdump? We are in the process of porting binutils, so I currently don't have an objdump to use. I do have a manual disassembly routine that we created in h/w design to help us. But, until binutils has been ported, there is no objdump.
I think the big issue that is confusing to me is why is BedBug still in U-Boot? Should i try and graft my work into BedBug? If so, then I'm happy to do the work and contribute it back to the group. But, if not, then I'll just go ahead implement the work independently.
Hopefully, this makes sense. Feel free to ask questions.
The way I understand your project, I wonder why you want to disassemble code at all: if you manage to get U-Boot running on your target with BedBug support for your CPU enabled, this means you have a working gcc+binutils, which in turn means you have a toolchain, including an assembler, that works well enough for bedbug to become pointless.
Compare the bedbug and objdump/gdb options: on the one hand you get a crude debugger and disassembler that will only run from U-Boot and will be practically useless for debugging say a Linux kernel or U-Boot itself; and on the other hand, with objdump you get a disassembler that will work on just about any binary, and with gdb, you get a debugger that will debug anything from U-boot to userland apps.
Also, I *very* strongly suggest that you integrate *some* debugging interface, based on *some* industry standard. Seeing as you're working on a brand new, untested so far, silicon, such a debugging interface is an absolute must IMO.
-brad w.
Amicalement,
On 05/23/2013 02:53 PM, Albert ARIBAUD wrote:
Also, I *very* strongly suggest that you integrate *some* debugging interface, based on *some* industry standard. Seeing as you're working on a brand new, untested so far, silicon, such a debugging interface is an absolute must IMO.
Ditto here.
JTAG (or some other industry debugging standard) allows attaching mature tools (like an Abatron BDI or some such) to not only help verify the state, but develop/debug the code you're writing. Without such you'll only be able to do a postmortem and inspect memory after the code/processor crash - a much more laborious process...
Hi Peter,
On Thu, 23 May 2013 15:08:24 -0400, Peter Barada peter.barada@logicpd.com wrote:
On 05/23/2013 02:53 PM, Albert ARIBAUD wrote:
Also, I *very* strongly suggest that you integrate *some* debugging interface, based on *some* industry standard. Seeing as you're working on a brand new, untested so far, silicon, such a debugging interface is an absolute must IMO.
Ditto here.
JTAG (or some other industry debugging standard) allows attaching mature tools (like an Abatron BDI or some such) to not only help verify the state, but develop/debug the code you're writing. Without such you'll only be able to do a postmortem and inspect memory after the code/processor crash - a much more laborious process...
One won't even be able to do that, at least not if the inspection is done using Bedbug within U-Boot since launching U-boot will, in itself, overwrite some of the memory -- and Murphy guarantees that the overwritten memory will include the areas needed for a successful postmortem.
Amicalement,
On 05/23/2013 03:49 PM, Albert ARIBAUD wrote:
Hi Peter,
On Thu, 23 May 2013 15:08:24 -0400, Peter Barada peter.barada@logicpd.com wrote:
On 05/23/2013 02:53 PM, Albert ARIBAUD wrote:
Also, I *very* strongly suggest that you integrate *some* debugging interface, based on *some* industry standard. Seeing as you're working on a brand new, untested so far, silicon, such a debugging interface is an absolute must IMO.
Ditto here.
JTAG (or some other industry debugging standard) allows attaching mature tools (like an Abatron BDI or some such) to not only help verify the state, but develop/debug the code you're writing. Without such you'll only be able to do a postmortem and inspect memory after the code/processor crash - a much more laborious process...
One won't even be able to do that, at least not if the inspection is done using Bedbug within U-Boot since launching U-boot will, in itself, overwrite some of the memory -- and Murphy guarantees that the overwritten memory will include the areas needed for a successful postmortem.
If one was lucky maybe. But who builds schedules around luck? And yes, Murphy's a mother...
I was assuming that through some black magic they could get into Bedbug on reset and use it to inspect memory. Of course this assumes that Bedbug and u-boot don't collide, u-boot doesn't try to relocate itself (or scribble over memory), all of which is extra development that a JTAG[1] attached debugger would preclude.
A JTAG debugger would allow you to load code directly into memory and then step through the processor initialization(or supply instructions on the fly!), low-level startup development that everyone does on a new processor. Also by stepping you can see where/when the processor is about to go off into the weeds many, many, many instructions _before_ it munches any hope of postmortem debugging. From experience bringing up boards w/o JTAG is not only tedious but unpredictable and takes a loooong time - the extra cost/effort of integrating JTAG (especially since this is a spanking new processor!) is more than justified by it reducing both total development time and overall schedule risk...
[1] I use JTAG to mean any industry standard hardware debug/access method that allows arbitrary execution and inspection/modification of registers/memory...
Dear Brad Walker,
In message CAPKZHbU1wKxJZ82O9v54Lct482o7MfcN4Yq_WniwL-TB8_-cGg@mail.gmail.com you wrote:
Why not just use JTAG? We are doing new processor design, so it's not defined if the system will even have a JTAG interface. There are lots of systems that do not have a JTAG interface.
I have no information what the target for your new processor might be; there is such systems that go to basically a single big customer / a single, highly specific use case, and there are those that are intended for general use - the more use cases the better. If you want to make your system easy to use for a big grouyp of people, then make sure that standard debug tools work. Include JTAG, and make sure it works with standard tools like the Abatron BDI2000/3000, Lauterbach Trace32 and OpenOCD etc.
Why not use use objdump? We are in the process of porting binutils, so I currently don't have an objdump to use. I do have a manual disassembly routine that we created in h/w design to help us. But, until binutils has been ported, there is no objdump.
Well, without a working binut=ils you cannot build U-Boot anyway, so you probably have to wait for that.
I think the big issue that is confusing to me is why is BedBug still in U-Boot? Should i try and graft my work into BedBug? If so, then I'm happy
BedBug is strill there, because it was useful for some (at some point of time), and it does not hurt to have it. I think the actual number of users is epsilon.
to do the work and contribute it back to the group. But, if not, then I'll just go ahead implement the work independently.
I'd recommend to save the efforts, and rather help the guys who are working on binutils. This is probably better invested time, then.
Best regards,
Wolfgang Denk
participants (4)
-
Albert ARIBAUD -
Brad Walker -
Peter Barada -
Wolfgang Denk