This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 23 Nov 2016 14:41, Maciej W. Rozycki wrote: > On Fri, 18 Nov 2016, Mike Frysinger wrote: > > > It looks to me like this change needs be reverted and the `r3900' marking > > > removed from DMFC1/DMTC1 encodings and their dependencies instead. > > > > the mips ISAs are too varied for me to try and dive in and find the right > > answer, and you're certainly way more familiar than i here. so whatever > > you want to do here is fine :). > > You're always welcome to ask and I'll be happy to assist you with any > MIPS issues. And if you cc me on mailing list postings, then it'll make > it easier to me to give a timely response and certainly not to miss any > altogether, as I'm not always up to date with tracking general traffic. sorry, i've gotten used to mips being orphaned. i'll try to fix that muscle memory and loop you in sooner. would you mind adding yourself to the sim/MAINTAINERS list ? > I've had a closer look now and uncovered a whole bunch of ISA subsetting > and wrong conditioning issues. I've ended up with some half a dozen > patches, all of which should be fairly obvious if accompanied with decent > descriptions I yet need to write down, although most touch a fair amount > of igen markup and actual code. for these igen files, certainly feel free to jump in and push stuff. > Which means I'd be more confident about pushing them if I had a way to > verify them -- do you have a testing procedure established for verifying > GNU sim patches, MIPS or otherwise, that I could reuse? sorry, i had missed this last part. i was just waiting for you to post patches for me to rubber stamp :). a big problem with the mips sim is that it tailors its build heavily based on the target. most other sims enable everything and then wait for cpu selection at runtime. this is why some mips builds work fine but others break and it's a while before anyone notices+reports. if you look at sim/mips/configure.ac you'll see a large number of checks on $target. basically every matrix in there needs to be built. i do: mkdir build cd build mkdir <mips-tuple> cd <mips-tuple> ../../configure \ --disable-gdbtk --disable-readline --with-system-readline \ --with-system-zlib --disable-nls \ --target=<mips-tuple> make all-sim -j4 make check-sim make all-gdb # If you really want, but prob not needed. i would look at a check-sim as a good signal that things are OK, but not a great one. the number of tests in sim/testsuite/sim/mips/ is too low (although mips32-dsp2 is a nice example of large coverage). the three tuples i use currently are: mips-elf mips-sde-elf mipstx39-rtems4.12 but as you can see from that configure flag, i'm missing coverage. but i don't care that much as i rarely (if ever) touch igen files. my focus is on the common code/drivers. -mike
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |