From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Doug Evans , David Taylor , Kevin Buettner , Nick Duffek , Michael Snyder , Jim Blandy Cc: GDB Discussion Subject: harvard architectures - the d10v Date: Thu, 08 Feb 2001 11:52:00 -0000 Message-id: <3A82F7E9.D4641BD1@cygnus.com> X-SW-Source: 2001-02/msg00082.html So a meta question, how should GDB behave when it comes to a harvard architecture? I've this feeling that at present we've lots of people all trying to get GDB to work on harvard architectures and each, in a vacuum, is determining how it should behave. The unfortunately consequence is that when the discussion is finally dragged, kicking and screaming, out onto a public forum, no one agrees. People refuse to discuss details because their harvard architecture is all hush, hush. By the time the issues are raised, it is all too late and the real problems are simply not fixed. The ironic part to all this is that, long ago, GDB was targeted at the d10v (it is the extreme games version of a harvard architectures). At the time it was decided that the d10v hacks should to be accepted into gdb because that way there was at least a working implementation out there in a public forum. The tool you all need to facilitate public discussion are available yet everyone refuses to use it! ``But the d10v is a hack''? So? The point of the d10v, wasn't to provide a reference implementation (anything but!) but rather to provide a vehicle through which a reference implementation could be developed. The really important thing is to remember that this implementation has been So, who out of all of you would like to steer this to resolution? The first thing I think needs to be done is for people to agree to the correct interaction and document it. That way if people ever want to re-open the debate about what the behaviour should be they can simply turn to the gdb.texinfo documentation. Andrew -- Anyway, onto more serious matters. One thing I do remember as a problem was: gdbtypes.h:builtin_type_ptr it isn't constructed correctly (at the time I didn't know what I was doing ...). It should be cloned into: builtin_type_data_ptr; (void*) builtin_type_func_ptr; (void(*)()) that would at least allow the POINTER_TO_ADDRESS and ADDRESS_TO_POINTER to be called when converting to/from generic pointers. Anyone? Andrew >From taylor@cygnus.com Thu Feb 08 12:38:00 2001 From: David Taylor To: Andrew Cagney Cc: Doug Evans , Kevin Buettner , Nick Duffek , Michael Snyder , Jim Blandy , GDB Discussion Subject: Re: harvard architectures - the d10v Date: Thu, 08 Feb 2001 12:38:00 -0000 Message-id: <200102082037.PAA07784@texas.cygnus.com> X-SW-Source: 2001-02/msg00083.html Content-length: 3403 Date: Thu, 08 Feb 2001 11:47:53 -0800 From: Andrew Cagney So a meta question, how should GDB behave when it comes to a harvard architecture? That's a very broad question. A vauge approximate answer is "As the d10v behaves, but without the bugs and without the kludges." [Of course that doesn't say "what is a bug" nor "what is a kludge".] For the d10v there are in several files the line if (GDB_TARGET_IS_D10V (Although I believe that the number of such files is diminishing over time.) I've this feeling that at present we've lots of people all trying to get GDB to work on harvard architectures and each, in a vacuum, is determining how it should behave. The unfortunately consequence is that when the discussion is finally dragged, kicking and screaming, out onto a public forum, no one agrees. People refuse to discuss details because their harvard architecture is all hush, hush. By the time the issues are raised, it is all too late and the real problems are simply not fixed. The ironic part to all this is that, long ago, GDB was targeted at the d10v (it is the extreme games version of a harvard architectures). At the time it was decided that the d10v hacks should to be accepted into gdb because that way there was at least a working implementation out there in a public forum. The tool you all need to facilitate public discussion are available yet everyone refuses to use it! ``But the d10v is a hack''? So? The point of the d10v, wasn't to provide a reference implementation (anything but!) but rather to provide a vehicle through which a reference implementation could be developed. The really important thing is to remember that this implementation has been Part of the sentence appears to be missing. So, who out of all of you would like to steer this to resolution? The first thing I think needs to be done is for people to agree to the correct interaction and document it. That way if people ever want to re-open the debate about what the behaviour should be they can simply turn to the gdb.texinfo documentation. I'm certainly interested in this discussion, have opinions on much of this, and am willing... but I don't have much care who "steers" it -- so long as the discussion occurs. Andrew -- Anyway, onto more serious matters. One thing I do remember as a problem was: gdbtypes.h:builtin_type_ptr it isn't constructed correctly (at the time I didn't know what I was doing ...). It should be cloned into: builtin_type_data_ptr; (void*) builtin_type_func_ptr; (void(*)()) Don't forget the existing msym_text_symbol_type. that would at least allow the POINTER_TO_ADDRESS and ADDRESS_TO_POINTER to be called when converting to/from generic pointers. Anyone? Andrew Currently, GDB and to a lesser extent the binutils/gas/ld toolsuite, deal with Harvard Architectures by adding extra bits to allow them to treat the system as having a unified address space. For example, for the d10v: . data memory starts at 0x2000000 . instruction memory starts at 0x1000000 . all addresses are byte addresses Converting between pointers and addresses generally seems to involve . or'ing in or masking off some high bits . shifting the low bits by some amount >From taylor@cygnus.com Thu Feb 08 12:51:00 2001 From: David Taylor To: gdb@sourceware.cygnus.com Subject: Harvard Architecture issues -- addresses vs pointers Date: Thu, 08 Feb 2001 12:51:00 -0000 Message-id: <200102082050.PAA07793@texas.cygnus.com> X-SW-Source: 2001-02/msg00084.html Content-length: 1059 I will refer to things as: . a user address . an internal gdb address . a target pointer For most targets, all three are the same thing. GDB clearly currently distinguishes between the last two -- an internal gdb address vs a target pointer, with the former living in a CORE_ADDR. I would maintain that while, long term, a user address should be separated from the other two, that gdb does not currently do so. And that if you peruse the code, modulo an occassional bug, you'll become convinced that currently, gdb treats user addresses and internal gdb addresses as the same thing. I feel that a user address should always mean the same thing. And that, for example, x/x 0x12345678 x/i 0x12345678 should both read the same set of bytes from the target. That the interpretation of 0x12345678 -- as a specific location within a specific address space -- should not depend upon whether the user typed /x or /i. That it should not be the case that one returns something from the data space and the other from the instruction space. Comments? >From dje@transmeta.com Thu Feb 08 13:06:00 2001 From: Doug Evans To: Andrew Cagney Cc: David Taylor , Kevin Buettner , Nick Duffek , Michael Snyder , Jim Blandy , GDB Discussion Subject: harvard architectures - the d10v Date: Thu, 08 Feb 2001 13:06:00 -0000 Message-id: <14979.2615.608456.807316@casey.transmeta.com> References: <3A82F7E9.D4641BD1@cygnus.com> X-SW-Source: 2001-02/msg00085.html Content-length: 2155 Andrew Cagney writes: > So a meta question, how should GDB behave when it comes to a harvard > architecture? Is "Harvard Architecture" really the best name for this? Seems to me it includes only a small subset of the total set of architectures that have multiple address spaces for different uses. > I've this feeling that at present we've lots of people all trying to get > GDB to work on harvard architectures and each, in a vacuum, is > determining how it should behave. The unfortunately consequence is that > when the discussion is finally dragged, kicking and screaming, out onto > a public forum, no one agrees. People refuse to discuss details because > their harvard architecture is all hush, hush. By the time the issues > are raised, it is all too late and the real problems are simply not > fixed. At best, this is a wee bit presumptious. [but never let that stop a good argument :-)] > The ironic part to all this is that, long ago, GDB was targeted at the > d10v (it is the extreme games version of a harvard architectures). At > the time it was decided that the d10v hacks should to be accepted into > gdb because that way there was at least a working implementation out > there in a public forum. The tool you all need to facilitate public > discussion are available yet everyone refuses to use it! Define "everyone". Define "refuses". > ``But the d10v is a hack''? So? The point of the d10v, wasn't to > provide a reference implementation (anything but!) but rather to provide > a vehicle through which a reference implementation could be developed. I don't know that the d10v was all the good a reference implementation or that one is even needed for the task at hand. > So, who out of all of you would like to steer this to resolution? The > first thing I think needs to be done is for people to agree to the > correct interaction and document it. That way if people ever want to > re-open the debate about what the behaviour should be they can simply > turn to the gdb.texinfo documentation. I'm not in a position to steer anything gdb-wise. But I do have an interest in seeing this resolved. >From kevinb@cygnus.com Thu Feb 08 13:14:00 2001 From: Kevin Buettner To: gdb@sourceware.cygnus.com Subject: Re: Harvard Architecture issues -- addresses vs pointers Date: Thu, 08 Feb 2001 13:14:00 -0000 Message-id: <1010208211432.ZM6398@ocotillo.lan> References: <200102082050.PAA07793@texas.cygnus.com> X-SW-Source: 2001-02/msg00087.html Content-length: 546 On Feb 8, 3:50pm, David Taylor wrote: > I feel that a user address should always mean the same thing. > And that, for example, > > x/x 0x12345678 > > x/i 0x12345678 > > should both read the same set of bytes from the target. That the > interpretation of 0x12345678 -- as a specific location within a > specific address space -- should not depend upon whether the user > typed /x or /i. That it should not be the case that one returns > something from the data space and the other from the instruction > space. I agree with David. >From per@bothner.com Thu Feb 08 13:14:00 2001 From: Per Bothner To: David Taylor Cc: GDB Discussion Subject: Re: harvard architectures - the d10v Date: Thu, 08 Feb 2001 13:14:00 -0000 Message-id: References: <200102082037.PAA07784@texas.cygnus.com> X-SW-Source: 2001-02/msg00086.html Content-length: 1954 David Taylor writes: > Currently, GDB and to a lesser extent the binutils/gas/ld toolsuite, > deal with Harvard Architectures by adding extra bits to allow them to > treat the system as having a unified address space. The problem of multiple address spaces is a more general problem: * We want to be able to use a single debugger to debug a distributed program running as mutiple processes. * Likewise, with the programs running on separate hardware with different architectures. * We want to be able to debug normal machine code as well as an interpreter ("virtual machine code"). * We want to debug programs that have separate data and instruction spaces. The cleanest solution would be to define CORE_ADDR as a struct: struct core_addr { struct address_space *target; uint64_t addr; }; typedef struct core_addr CORE_ADDR; struct address_space { pointer to table of functions that take a core_addr; ... address-space-specific data, such as process id ...; }; #define ADDR_ADDRESS_SPACE(ADDR) ((ADDR)->target) #define ADDR_VALUE(ADDR) ((ADDR)->target) This would be the Right Thing, but it might be a lot of work to convert Gdb. Perhaps not - I don't know. An interim step might be using certain high-order bits of an integer as an index into a table of address spaces: typedef unit64_t CORE_ADDR; struct addr_space normal_addr_space = { ... }; struct addr_space *(addr_space_table[256]) = { normal_addr_space, normal_addr_space, ... }; #define ADDR_ADDRESS_SPACE(ADDR) addr_space_table[(ADDR) >> 56] #define ADDR_VALUE(ADDR) (ADDR_ADDRESS_SPACE(ADDR)->addr_value(ADDR)) Something like the above can probably be implemented very easily, without breaking any "normal" architectures. You can then relatively cleanly implement support for multiple address spaces in this framework - just plud in new addr_spaces in the addr_space_table. -- --Per Bothner per@bothner.com http://www.bothner.com/~per/ >From taylor@cygnus.com Thu Feb 08 13:18:00 2001 From: David Taylor To: Doug Evans Cc: Andrew Cagney , Kevin Buettner , Nick Duffek , Michael Snyder , Jim Blandy , GDB Discussion Subject: Re: harvard architectures - the d10v Date: Thu, 08 Feb 2001 13:18:00 -0000 Message-id: <200102082118.QAA07810@texas.cygnus.com> X-SW-Source: 2001-02/msg00088.html Content-length: 1105 From: Doug Evans Date: Thu, 8 Feb 2001 13:05:59 -0800 (PST) Andrew Cagney writes: > So a meta question, how should GDB behave when it comes to a harvard > architecture? Is "Harvard Architecture" really the best name for this? Seems to me it includes only a small subset of the total set of architectures that have multiple address spaces for different uses. It could have multiple address spaces for a variety of reasons -- for example, the Sony Playstation 2, if I recall correctly, has 5 total processors in it of 2 (or is it 3?) different types. Each has its own memory. Are there issues people wish to discuss beyond the issues that arise as a result of multiple address spaces? > ``But the d10v is a hack''? So? The point of the d10v, wasn't to > provide a reference implementation (anything but!) but rather to provide > a vehicle through which a reference implementation could be developed. I don't know that the d10v was all the good a reference implementation or that one is even needed for the task at hand. >From per@bothner.com Thu Feb 08 13:21:00 2001 From: Per Bothner To: David Taylor Cc: gdb@sourceware.cygnus.com Subject: Re: Harvard Architecture issues -- addresses vs pointers Date: Thu, 08 Feb 2001 13:21:00 -0000 Message-id: References: <200102082050.PAA07793@texas.cygnus.com> X-SW-Source: 2001-02/msg00089.html Content-length: 670 David Taylor writes: > I feel that a user address should always mean the same thing. > And that, for example, > > x/x 0x12345678 > > x/i 0x12345678 > > should both read the same set of bytes from the target. I agree. We need soem syntax to specify address space literals. I might suggest '@' followed by an address-space name. (I'm not sure if this conflicts with the array "repeat" operator.) 0x12345678@i 0x12345678@d More generally: integer-expression @NAME coerces the integer to a pointer in the named space. This syntax could also be used for output. -- --Per Bothner per@bothner.com http://www.bothner.com/~per/ >From dje@transmeta.com Thu Feb 08 13:31:00 2001 From: Doug Evans To: David Taylor Cc: GDB Discussion Subject: Re: harvard architectures - the d10v Date: Thu, 08 Feb 2001 13:31:00 -0000 Message-id: <14979.4102.901998.291182@casey.transmeta.com> References: <200102082037.PAA07784@texas.cygnus.com> X-SW-Source: 2001-02/msg00090.html Content-length: 1935 David Taylor writes: >I feel that a user address should always mean the same thing. >And that, for example, > > x/x 0x12345678 > > x/i 0x12345678 > >should both read the same set of bytes from the target. That the >interpretation of 0x12345678 -- as a specific location within a >specific address space -- should not depend upon whether the user >typed /x or /i. That it should not be the case that one returns >something from the data space and the other from the instruction >space. > >Comments? Agreed. The way I would extend this is to name the address space you want the address to refer to. Without claiming this is the best syntax/wording/etc., maybe something like x/x insn:0x12345678 x/i insn:0x12345678 x/x data:0x12345678 x/i data:0x12345678 - there could be a default address space, or target could specify that "x/x 0x12345678 is an error - users of targets without address spaces would see no change - I would treat the address space names as target specific Implementation-wise, this would get translated to a CORE_ADDR that had two parts: address space id, and address. Obviously, you really don't want to fake the encoding of this by still have CORE_ADDR be an integral type as you have to worry about address calculations over/underflowing to a different address space. An integral CORE_ADDR may not even be big enough to hold all the possiblities. Ergo, CORE_ADDR becomes a struct. A simplistic count of the number of places in the source that has to change is about 1400 (make CORE_ADDR a struct, and process the output of make -k). That's a lot. I have heard "hallway discussions" where people have been thinking about making CORE_ADDR a struct, and it seems (though I'm by no means certain) like "the right thing to do". Targets without address spaces could probably keep CORE_ADDR as an integral type. You'd just need to write an appropriate set of cover macros for definition/manipulation. >From ac131313@cygnus.com Thu Feb 08 14:02:00 2001 From: Andrew Cagney To: Per Bothner Cc: GDB Discussion Subject: Re: harvard architectures - the d10v Date: Thu, 08 Feb 2001 14:02:00 -0000 Message-id: <3A831664.2AB12A43@cygnus.com> References: <200102082037.PAA07784@texas.cygnus.com> X-SW-Source: 2001-02/msg00091.html Content-length: 612 FYI, Per Bothner wrote: > The cleanest solution would be to define CORE_ADDR as a struct: > > struct core_addr { > struct address_space *target; > uint64_t addr; > }; Yes. People have talked about doing this for longer than I can remember. Problem is, making CORE_ADDR an object is only a tiny part of the solution and, to be honest, probably comes last in the long list of things to change. As a broad strategy, I'd expect all the prototyping to be done using functions that take a CORE_ADDR and then, only at the last moment, would someone push a button and change it to a struct. enjoy, Andrew >From ac131313@cygnus.com Thu Feb 08 14:06:00 2001 From: Andrew Cagney To: Doug Evans Cc: David Taylor , Kevin Buettner , Nick Duffek , Michael Snyder , Jim Blandy , GDB Discussion Subject: Re: harvard architectures - the d10v Date: Thu, 08 Feb 2001 14:06:00 -0000 Message-id: <3A831746.CAB9C621@cygnus.com> References: <3A82F7E9.D4641BD1@cygnus.com> <14979.2615.608456.807316@casey.transmeta.com> X-SW-Source: 2001-02/msg00092.html Content-length: 1108 Doug Evans wrote: > > ``But the d10v is a hack''? So? The point of the d10v, wasn't to > > provide a reference implementation (anything but!) but rather to provide > > a vehicle through which a reference implementation could be developed. > > I don't know that the d10v was all the good a reference implementation > or that one is even needed for the task at hand. Notice that I carefully avoided calling the d10v a reference implementation. It isn't and I'm not claiming that it is. Rather it is a working example. The moment anyone refers to the D10V code they are probably missing the point :-) The thing to do with the d10v is look at how the user is able to interact with it. For instance, the user can cut addresses from one part of the screen and paste them directly into new commands. The user can use 0 and have it mean NULL. It is that sort of subtlety that the d10v managed to resolve. The one thing people shouldn't be doing is designing some new set of implementations without looking at what has been before and seeing how real people felt things should work. enjoy, Andrew >From per@bothner.com Thu Feb 08 14:13:00 2001 From: Per Bothner To: Andrew Cagney Cc: GDB Discussion Subject: Re: harvard architectures - the d10v Date: Thu, 08 Feb 2001 14:13:00 -0000 Message-id: References: <200102082037.PAA07784@texas.cygnus.com> <3A831664.2AB12A43@cygnus.com> X-SW-Source: 2001-02/msg00093.html Content-length: 906 Andrew Cagney writes: > FYI, > > Per Bothner wrote: > > The cleanest solution would be to define CORE_ADDR as a struct: > > Yes. People have talked about doing this for longer than I can > remember. I certainly did when I was at Cygnus ... > Problem is, making CORE_ADDR an object is only a tiny part of > the solution Well, it seems like a prerequisite: If you want to deal with multiple addres-spaces, you have to have some way of representing that. > As a broad strategy, I'd expect all the prototyping > to be done using functions that take a CORE_ADDR We're still talking about the problem of handling more than one address space, right? How do you want to represent that during "prototyping"? It need not be a struct - in fact the second half of my message proposed a relatively generic alternative. -- --Per Bothner per@bothner.com http://www.bothner.com/~per/ >From ac131313@cygnus.com Thu Feb 08 15:06:00 2001 From: Andrew Cagney To: David Taylor Cc: Doug Evans , Kevin Buettner , Nick Duffek , Michael Snyder , Jim Blandy , GDB Discussion Subject: Re: harvard architectures - the d10v Date: Thu, 08 Feb 2001 15:06:00 -0000 Message-id: <3A831EA7.7C3CEF72@cygnus.com> References: <200102082118.QAA07810@texas.cygnus.com> X-SW-Source: 2001-02/msg00094.html Content-length: 897 David Taylor wrote: > Andrew Cagney writes: > > So a meta question, how should GDB behave when it comes to a harvard > > architecture? > > Is "Harvard Architecture" really the best name for this? > Seems to me it includes only a small subset of the total set of > architectures that have multiple address spaces for different uses. > > It could have multiple address spaces for a variety of reasons -- for > example, the Sony Playstation 2, if I recall correctly, has 5 total > processors in it of 2 (or is it 3?) different types. Each has its own > memory. True. Multiple address spaces for a single thread. Singleing out harvard architecture was probably badness on my part. > Are there issues people wish to discuss beyond the issues that arise > as a result of multiple address spaces? Please don't. Lets fix one bug and then worry about the next. Andrew >From wung_y@263.net Thu Feb 08 16:49:00 2001 From: "Wang Yong" To: Subject: how to build Date: Thu, 08 Feb 2001 16:49:00 -0000 Message-id: X-SW-Source: 2001-02/msg00095.html Content-length: 171 I want to run gdb on windows nt to debug MPC823 target. Does anyone know how to build this gdb. Should I build it on linux or cygwin and how to configure? thx Wang