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] |
>>>>> "shebs" == Stan Shebs <shebs@cygnus.com> writes: jimb> There are actually three "architectures" that we care about: jimb> - the architecture of the processor itself jimb> - the ABI and calling conventions (controlled by the jimb> compiler/linker environment) jimb> - the target board architecture (excluding the CPU) I think the second point could be further subdivided. For the most part, GDB only cares about the calling conventions. But in some cases, for example with setjmp()/longjmp(), it wants to know the internals of the implementation. There is no guarentee that my setjmp()/longjmp() implementation is going to store registers in the same order as anyone elses. I'm not quite sure what is meant by target board architecture, hopefully whatever back end GDB uses (the remote protocol, a ROM monitor, etc) abstracts and isolates it from the target board. shebs> Yes, this is a good mental model. jimb> At present, we kind of smoosh them all together, which causes jimb> confusion when someone else needs to wade into our code and jimb> disentangle our assumptions. We support multiple ABI's for the jimb> MIPS and PPC (at least), and (I think???) you have to select the jimb> one you want at configuration time (--target=powerpc-eabi, for jimb> example). So we are already drifting away from "generic" jimb> embedded toolchains, which I agree is bad. I think it's not so much drifting away from "generic" toolchains. The infrastructure for generic toolchains wasn't/isn't in place, and it is a lot of work to retrofit. It used to be much worse. When I joined Cygnus, I believe there were several m68k toolchains --- as GDB backend and newlib target support for the various eval boards were separate configs. shebs> This is a leftover from native debugging, where the shebs> configure-time choice of host OS determines architecture and shebs> ABI. In fact, even CPU variants are often reduced down to a shebs> single "programmer's model" that restricts access to some of a shebs> chip's features (like supervisor mode :-) ). And MMU and other system registers, etc. jimb> When we estimate new GDB ports, we should include time to jimb> actually segregate those three things nicely, so that GDB could jimb> have a "set abi" and "set board" command. Otherwise, if GDB is jimb> really to know all that stuff (as Stan has said it should), it's jimb> going to be a total mess. And also so you have a complete product in the end. For example, there've been many new GDB ports done, but there haven't been many new stubs. shebs> In general, GDB should not have to know much about specific shebs> boards; things are simplified overall if the board support shebs> package takes care of board idiosyncrasies, so for instance GDB shebs> can say "write memory" and the board does one thing for flash, shebs> and something else for RAM. Agreed, write protected RAM, EEPROM, flash, banked memory, etc. should all be handled by the code in the stub that handles the 'write memory' command. Using a vendor-supplied ROM monitor might require additional knowlege by GDB about the target and "helper" routines in the application. Bleh. That's too ugly to think about. --jtc -- J.T. Conklin RedBack Networks