Hello,
gdb currently displays the contents of set variables wrongly on big endian machines for at least GPC and FPC. The reason is that it treats a set as a linear array of bits, while both GPC and FPC treat it as an array of ordinals in which bits are set using "1 shl (elementnr mod sizeof(ordinal))".
The problem with creating a patch is that in FPC the size of this ordinal is always 32 bit, while on GPC it is MedCard (which is 64 bit on 64 bit architectures). The main reasons for FPC to always use 32 bits are
a) binary compatibility b) performance (even on 64 bit machines, loading/storing a 32 bit value from/to memory is often faster)
I have found several mails in the archives of this list noting that people should not rely on GPC sets having a particular format, so I wonder whether this could be changed in GPC? Regardless of those warnings, I guess it will still cause problems (the same binary compatibility mentioned above, for people who created data files containing sets on 64 bit machines with GPC), but it will also have advantages (making files containing sets compatible with both 32 and 64 bit apps compiled by GPC).
If someone sees a way to automatically detect the used set format inside gdb itself, that would be great as well of course.
What do you think?
Jonas
PS: I've attached a patch to gdb which fixes the problem for big endian FPC and 32 bit GPC apps. I think it may still have to be changed to not treat bitstrings differently from sets, because the stabs docs (http://www.cygwin.com/stabs.html) state:
--- S Indicate that this type is a string instead of an array of characters, or a bitstring instead of a set. It doesn't change the layout of the data being represented, but does enable the debugger to know which type it is. ---
What are "bitstrings" in Pascal anyway? gdb displays them as
B'1..3,5,7' (sets are printed as [1..3,5,7])
so they don't seem to be the same as a bit-packed array of boolean or so.
PS2: the patch was created against Apple's gdb-477. However it applies cleanly to plain GNU gdb (cvs version) as well (with a few line offset differences)