Bug#434855: Processed: A (partial) fix for mips/mipsel
Thiemo Seufer wrote: Christian Holm Christensen wrote: [snip] Just one question: Is it possible for you to try to build the packages on mipsel? I can try, but right now the best mipsel machine I have set up is a puny 250 MHz machine. :-) This fails due to a missing -lcurl, your package lacks the build dependency. I installed libcurl4-openssl-dev, this seems to work (but may cause license trouble with GPL software, in that case it should be libcurl4-gnutls-dev). Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434855: Processed: A (partial) fix for mips/mipsel
Hi Thiemo, First off, thank you for your detailed answers. On Wed, 2007-11-07 at 02:44 +, Thiemo Seufer wrote: Christian Holm Christensen wrote: Hi again, On Tue, 2007-11-06 at 21:10 +, Thiemo Seufer wrote: Christian Holm Christensen wrote: Hi Thiemo, On Tue, 2007-11-06 at 18:56 +, Thiemo Seufer wrote: Christian Holm Christensen wrote: Hi Thiemo, On Mon, 2007-11-05 at 00:48 +, Debian Bug Tracking System wrote: ... I notice that the regex in configure excludes now mipsel. From your mails, I gather that it would be OK to assume that mips and mipsel are the same (Endianness is handled directly in the code). ... Currently, there's the following code in ROOT to deal with Linux on mips: #if defined(linux) defined(__mips) Better would be to check for __linux__ and __mips__. linux might be a variable in the code somewhere... The __mips__ version with two trailing underscores is the more common one. So: #if defined(__linux__) defined(__mips__) OK, thanks. # define R__LINUX # define R__UNIX # define NEED_SIGJMP # if defined(__mips64) || defined(_ABI64) This is broken, as __mips64 is also defined for N32, and _ABI64 is always defined. Assuming the R__B64 controls both address space and register size, it should be: # if _MIPS_SIM==_ABI64 Ah, I see. Ok thanks. I don't know what the exact semantics of those defines are, and how well suilted they are to support N32. # define R__B64 /* enable when 64 bit machine */ # endif # if !defined(__MIPSEB__) /* Little endian */ For more clarity: # if defined(__MIPSEL__) /* Little endian */ Right. # define R__BYTESWAP # endif #endif The only difference between both is the endianness. For complete MIPS support it would need the following: mipsO32 ABI, ILP32, long long in a aligned even-odd register mipsel pair, 4 argument registers mipsn32el N32 ABI, ILP32, but with 64 bit wide registers, and mipsn32 long long in a single register, 8 argument registers mips64elN64 ABI, LP64, 8 argument registers mips64 ... Just to make sure: There are only two Debian MIPS architectures: mips and mipsel. Does that mean, that Debian arch | ABI (from your list above) -+--- mips | mips, mipsn32, mips64 mipsel | mipsel, mipsn32el, mips64el No, sorry again for leaving ot crucial information. Debian currently supports only O32 ABI. Support for the other ABIs is planned in future but so far hasn't progressed much beyond 64bit Kernels. The ABI names quoted above are actually the propsed Debian architecture names, since Debian architecture effectiely means support for one specific ABI. No worries, and thank you for the clearification. The code in CINT related to MIPS is currently #elif (defined(__mips)defined(linux)) /** * MIPS, Linux **/ # define G__VAARG_INC_COPY_N 4 # define G__VAARG_PASS_BY_REFERENCE 8 I guess these should really be | mips | mipsn32 | mips64 | mipsel | mipsn32el | mips64el ---++- G__VAARG_INC_COPY_N| 4| 8 |8 G__VAARG_PASS_BY_REFERENCE | 4| 8 |8 if G__VAARG_INC_COPY_N is meant to be the size of the argument registers, and G__VAARG_PASS_BY_REFERENCE is the number of arguments passed by reference through registers. Can someone on the CINT mailing list elaborate please? Thanks. Sounds like it, yes. OK, fixed. How would one find out whether the ABI was O32 or N32? Is there some pre-processor macro that will tell you? I guess the code quoted above will be enough to distinguish between mips/mipsn32 and mips64, but it's not clear how I would distinguish between mips and mipsn32. For O32: #if _MIPS_SIM==_ABIO32 ... #endif For N32: #if _MIPS_SIM==_ABIN32 ... #endif For N64: #if _MIPS_SIM==_ABI64 ... #endif Very nice, thank you. ... The ROOT configure script uses the triplet arch=`uname -s | tr '[A-Z]' '[a-z]'` chip=`uname -m | tr '[A-Z]' '[a-z]'` rele=`uname -r` to figure out the platform we're compiling fore - can I some how, from that triplet - figure out which ABI we're using? As I tried to explain, no. You can see the same problem already on a AMD64 machine when trying to compile 32-bit code (via gcc -m32). Using uname to figure out the ABI
Bug#434855: Processed: A (partial) fix for mips/mipsel
Christian Holm Christensen wrote: [snip] Just one question: Is it possible for you to try to build the packages on mipsel? I can try, but right now the best mipsel machine I have set up is a puny 250 MHz machine. :-) I plan to change that soon-ish, but this depends on fixing some kernel bugs first. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434855: Processed: A (partial) fix for mips/mipsel
Hi Thiemo, On Mon, 2007-11-05 at 00:48 +, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: tags 434855 +patch Bug#434855: root-system_5.15.07-4(experimental/mipsel/modi): Attempts at guessing your architecture failed. Tags were: experimental Tags added: patch thanks Thank you for looking into this. However, I have, with the help of Boris [EMAIL PROTECTED] ported ROOT to mips. The GSL stuff is also fixed. The current sources at deb-src http://mirror.phy.bnl.gov/debian-root unstable main contrib supports mips and hppa. For more details, see http://wiki.debian.org/DebianScienceROOT But thank you for looking into this. If you'd like to help, then if you could try to build the packages, it would be great. Yours, -- ___ | Christian Holm Christensen |_| | - | | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 _| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91 _|DenmarkOffice: (+45) 353 25 404 | Email: [EMAIL PROTECTED] Web:www.nbi.dk/~cholm | | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434855: Processed: A (partial) fix for mips/mipsel
Christian Holm Christensen wrote: Hi Thiemo, On Mon, 2007-11-05 at 00:48 +, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: tags 434855 +patch Bug#434855: root-system_5.15.07-4(experimental/mipsel/modi): Attempts at guessing your architecture failed. Tags were: experimental Tags added: patch thanks Thank you for looking into this. However, I have, with the help of Boris [EMAIL PROTECTED] ported ROOT to mips. The GSL stuff is also fixed. The current sources at I notice that the regex in configure excludes now mipsel. The only difference between both is the endianness. For complete MIPS support it would need the following: mipsO32 ABI, ILP32, long long in a aligned even-odd register mipsel pair, 4 argument registers mipsn32el N32 ABI, ILP32, but with 64 bit wide registers, and mipsn32 long long in a single register, 8 argument registers mips64elN64 ABI, LP64, 8 argument registers mips64 Note that the el is always the suffix. deb-src http://mirror.phy.bnl.gov/debian-root unstable main contrib supports mips and hppa. For more details, see http://wiki.debian.org/DebianScienceROOT But thank you for looking into this. If you'd like to help, then if you could try to build the packages, it would be great. Builds fine on mips/experimental. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434855: Processed: A (partial) fix for mips/mipsel
Hi Thiemo, On Tue, 2007-11-06 at 18:56 +, Thiemo Seufer wrote: Christian Holm Christensen wrote: Hi Thiemo, On Mon, 2007-11-05 at 00:48 +, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: tags 434855 +patch Bug#434855: root-system_5.15.07-4(experimental/mipsel/modi): Attempts at guessing your architecture failed. Tags were: experimental Tags added: patch thanks Thank you for looking into this. However, I have, with the help of Boris [EMAIL PROTECTED] ported ROOT to mips. The GSL stuff is also fixed. The current sources at I notice that the regex in configure excludes now mipsel. I did that because I wasn't sure if it would work on mipsel straight out of the box, since the endianess is important for I/O among other things. The only difference between both is the endianness. For complete MIPS support it would need the following: mipsO32 ABI, ILP32, long long in a aligned even-odd register mipsel pair, 4 argument registers mipsn32el N32 ABI, ILP32, but with 64 bit wide registers, and mipsn32 long long in a single register, 8 argument registers mips64elN64 ABI, LP64, 8 argument registers mips64 I'm not sure how to understand your table. Could you, along the lines outlined at http://wiki.debian.org/DebianScienceROOT - Porting Notes tell me what changes would be needed? Perhaps which already support registers the 6 cases above would be similar to? I guess the O32/N32/N64 is the word-size, but what is the O and N? I don't know what you mean by ILP32/LP63. I also don't know how to deal with long long in 1 or 2 registers. I guess the argument registers refers to variadic arguments, but exactly what that would imply in the ROOT source code I don't know. I've Cc'ed this mail to rootdev and cintdev for more input. Note that the el is always the suffix. OK. That goes for the return from `uname'? deb-src http://mirror.phy.bnl.gov/debian-root unstable main contrib supports mips and hppa. For more details, see http://wiki.debian.org/DebianScienceROOT But thank you for looking into this. If you'd like to help, then if you could try to build the packages, it would be great. Builds fine on mips/experimental. Great. Could you make the packages publicly available? If so, I'll upload them to the above repository. Thanks again for your help. Yours, -- ___ | Christian Holm Christensen |_| | - | | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 _| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91 _|DenmarkOffice: (+45) 353 25 404 | Email: [EMAIL PROTECTED] Web:www.nbi.dk/~cholm | | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434855: Processed: A (partial) fix for mips/mipsel
Christian Holm Christensen wrote: Hi Thiemo, On Tue, 2007-11-06 at 18:56 +, Thiemo Seufer wrote: Christian Holm Christensen wrote: Hi Thiemo, On Mon, 2007-11-05 at 00:48 +, Debian Bug Tracking System wrote: Processing commands for [EMAIL PROTECTED]: tags 434855 +patch Bug#434855: root-system_5.15.07-4(experimental/mipsel/modi): Attempts at guessing your architecture failed. Tags were: experimental Tags added: patch thanks Thank you for looking into this. However, I have, with the help of Boris [EMAIL PROTECTED] ported ROOT to mips. The GSL stuff is also fixed. The current sources at I notice that the regex in configure excludes now mipsel. I did that because I wasn't sure if it would work on mipsel straight out of the box, since the endianess is important for I/O among other things. The places where endianness is visible would need some care, true. The compiler provides built-in macros for that purpose: __MIPSEL__ for little endian __MIPSEB__ for big endian I presume you already use a macro to select endianness, selecting it via the compiler builtins should be straightforward. The only difference between both is the endianness. For complete MIPS support it would need the following: mipsO32 ABI, ILP32, long long in a aligned even-odd register mipsel pair, 4 argument registers mipsn32el N32 ABI, ILP32, but with 64 bit wide registers, and mipsn32 long long in a single register, 8 argument registers mips64elN64 ABI, LP64, 8 argument registers mips64 I'm not sure how to understand your table. Could you, along the lines outlined at http://wiki.debian.org/DebianScienceROOT - Porting Notes tell me what changes would be needed? Perhaps which already support registers the 6 cases above would be similar to? I guess the O32/N32/N64 is the word-size, but what is the O and N? I don't know what you mean by ILP32/LP63. I also don't know how to deal with long long in 1 or 2 registers. Sorry, I realize that was too terse. O32/N32/N64 are the names of the ABIs (Application Binary Interfaces) supported on Linux/MIPS. I attempted to add a short outline of its properties to each mention. ILP32 is a common abbreviation for an ABI with 32bit integer, 32bit long, 32bit pointer size, describing the most important C types. This is like classic Linux i386. The comparable MIPS ABI is O32. LP64 is a shorthand for 64bit long, 64bit pointer size. This is what most 64bit Unices use, one example is Linux AMD64. The comparable MIPS ABI is N64. The N32 ABI is a bit odd, it combines a 32bit address space with 64bit wide registers, but it still retains the classic (ILP32) data type lengths. I mentioned long long since that is the only data type which is subtly different between both ILP32 variants. Maybe this part isn't relevant for ROOT. I guess the argument registers refers to variadic arguments, but exactly what that would imply in the ROOT source code I don't know. On MIPS (and most other RISC-like architectures) the first few arguments to a function are passed via registers. From the powerpc code in cint I inferred this is an important property which the code needs to know about. I've Cc'ed this mail to rootdev and cintdev for more input. Note that the el is always the suffix. OK. That goes for the return from `uname'? Not quite. The uname is on a 32bit kernel MIPS, and on a 64bit kernel MIPS64, regardless of endianness. You may have noticed by now that I say ABI and try to avoid Machine or CPU, since those are not necessarily identical things. 'uname' would return the wrong result if we want to build a 32bit program on a 64bit capable machine. In Debian the selection is handled via dpkg-architecture, which tells exactly what build type is asked for. For other Distributions the best practice is to combine uname output with a test for predefined compiler macros to figure out the default endianness, and hope the result is what was asked for. deb-src http://mirror.phy.bnl.gov/debian-root unstable main contrib supports mips and hppa. For more details, see http://wiki.debian.org/DebianScienceROOT But thank you for looking into this. If you'd like to help, then if you could try to build the packages, it would be great. Builds fine on mips/experimental. Great. Could you make the packages publicly available? If so, I'll upload them to the above repository. Will soon show up at http://people.debian.org/~ths/root-system/mips/ Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434855: Processed: A (partial) fix for mips/mipsel
Hi again, On Tue, 2007-11-06 at 21:10 +, Thiemo Seufer wrote: Christian Holm Christensen wrote: Hi Thiemo, On Tue, 2007-11-06 at 18:56 +, Thiemo Seufer wrote: Christian Holm Christensen wrote: Hi Thiemo, On Mon, 2007-11-05 at 00:48 +, Debian Bug Tracking System wrote: ... I notice that the regex in configure excludes now mipsel. I did that because I wasn't sure if it would work on mipsel straight out of the box, since the endianess is important for I/O among other things. The places where endianness is visible would need some care, true. The compiler provides built-in macros for that purpose: __MIPSEL__ for little endian __MIPSEB__ for big endian I presume you already use a macro to select endianness, selecting it via the compiler builtins should be straightforward. Currently, there's the following code in ROOT to deal with Linux on mips: #if defined(linux) defined(__mips) # define R__LINUX # define R__UNIX # define NEED_SIGJMP # if defined(__mips64) || defined(_ABI64) # define R__B64 /* enable when 64 bit machine */ # endif # if !defined(__MIPSEB__) /* Little endian */ # define R__BYTESWAP # endif #endif The only difference between both is the endianness. For complete MIPS support it would need the following: mipsO32 ABI, ILP32, long long in a aligned even-odd register mipsel pair, 4 argument registers mipsn32el N32 ABI, ILP32, but with 64 bit wide registers, and mipsn32 long long in a single register, 8 argument registers mips64elN64 ABI, LP64, 8 argument registers mips64 I'm not sure how to understand your table. Could you, along the lines outlined at http://wiki.debian.org/DebianScienceROOT - Porting Notes tell me what changes would be needed? Perhaps which already support registers the 6 cases above would be similar to? Just to make sure: There are only two Debian MIPS architectures: mips and mipsel. Does that mean, that Debian arch | ABI (from your list above) -+--- mips | mips, mipsn32, mips64 mipsel | mipsel, mipsn32el, mips64el I guess the O32/N32/N64 is the word-size, but what is the O and N? I don't know what you mean by ILP32/LP63. I also don't know how to deal with long long in 1 or 2 registers. Sorry, I realize that was too terse. O32/N32/N64 are the names of the ABIs (Application Binary Interfaces) supported on Linux/MIPS. Ah, I see. I attempted to add a short outline of its properties to each mention. ILP32 is a common abbreviation for an ABI with 32bit integer, 32bit long, 32bit pointer size, describing the most important C types. This is like classic Linux i386. The comparable MIPS ABI is O32. LP64 is a shorthand for 64bit long, 64bit pointer size. This is what most 64bit Unices use, one example is Linux AMD64. The comparable MIPS ABI is N64. The N32 ABI is a bit odd, it combines a 32bit address space with 64bit wide registers, but it still retains the classic (ILP32) data type lengths. I mentioned long long since that is the only data type which is subtly different between both ILP32 variants. Maybe this part isn't relevant for ROOT. I guess whether the O32/N32 split is important, depends on where 64bit wide registers registers are used and important. I guess the argument registers refers to variadic arguments, but exactly what that would imply in the ROOT source code I don't know. On MIPS (and most other RISC-like architectures) the first few arguments to a function are passed via registers. From the powerpc code in cint I inferred this is an important property which the code needs to know about. The code in CINT related to MIPS is currently #elif (defined(__mips)defined(linux)) /** * MIPS, Linux **/ # define G__VAARG_INC_COPY_N 4 # define G__VAARG_PASS_BY_REFERENCE 8 I guess these should really be | mips | mipsn32 | mips64 | mipsel | mipsn32el | mips64el ---++- G__VAARG_INC_COPY_N| 4| 8 |8 G__VAARG_PASS_BY_REFERENCE | 4| 8 |8 if G__VAARG_INC_COPY_N is meant to be the size of the argument registers, and G__VAARG_PASS_BY_REFERENCE is the number of arguments passed by reference through registers. Can someone on the CINT mailing list elaborate please? Thanks. How would one find out whether the ABI was O32 or N32? Is there some pre-processor macro that will tell you? I guess the code quoted above will be enough to distinguish
Bug#434855: Processed: A (partial) fix for mips/mipsel
Christian Holm Christensen wrote: Hi again, On Tue, 2007-11-06 at 21:10 +, Thiemo Seufer wrote: Christian Holm Christensen wrote: Hi Thiemo, On Tue, 2007-11-06 at 18:56 +, Thiemo Seufer wrote: Christian Holm Christensen wrote: Hi Thiemo, On Mon, 2007-11-05 at 00:48 +, Debian Bug Tracking System wrote: ... I notice that the regex in configure excludes now mipsel. I did that because I wasn't sure if it would work on mipsel straight out of the box, since the endianess is important for I/O among other things. The places where endianness is visible would need some care, true. The compiler provides built-in macros for that purpose: __MIPSEL__ for little endian __MIPSEB__ for big endian I presume you already use a macro to select endianness, selecting it via the compiler builtins should be straightforward. Currently, there's the following code in ROOT to deal with Linux on mips: #if defined(linux) defined(__mips) Better would be to check for __linux__ and __mips__. linux might be a variable in the code somewhere... The __mips__ version with two trailing underscores is the more common one. So: #if defined(__linux__) defined(__mips__) # define R__LINUX # define R__UNIX # define NEED_SIGJMP # if defined(__mips64) || defined(_ABI64) This is broken, as __mips64 is also defined for N32, and _ABI64 is always defined. Assuming the R__B64 controls both address space and register size, it should be: # if _MIPS_SIM==_ABI64 I don't know what the exact semantics of those defines are, and how well suilted they are to support N32. # define R__B64 /* enable when 64 bit machine */ # endif # if !defined(__MIPSEB__) /* Little endian */ For more clarity: # if defined(__MIPSEL__) /* Little endian */ # define R__BYTESWAP # endif #endif The only difference between both is the endianness. For complete MIPS support it would need the following: mipsO32 ABI, ILP32, long long in a aligned even-odd register mipsel pair, 4 argument registers mipsn32el N32 ABI, ILP32, but with 64 bit wide registers, and mipsn32 long long in a single register, 8 argument registers mips64elN64 ABI, LP64, 8 argument registers mips64 I'm not sure how to understand your table. Could you, along the lines outlined at http://wiki.debian.org/DebianScienceROOT - Porting Notes tell me what changes would be needed? Perhaps which already support registers the 6 cases above would be similar to? Just to make sure: There are only two Debian MIPS architectures: mips and mipsel. Does that mean, that Debian arch | ABI (from your list above) -+--- mips | mips, mipsn32, mips64 mipsel | mipsel, mipsn32el, mips64el No, sorry again for leaving ot crucial information. Debian currently supports only O32 ABI. Support for the other ABIs is planned in future but so far hasn't progressed much beyond 64bit Kernels. The ABI names quoted above are actually the propsed Debian architecture names, since Debian architecture effectiely means support for one specific ABI. I guess the O32/N32/N64 is the word-size, but what is the O and N? I don't know what you mean by ILP32/LP63. I also don't know how to deal with long long in 1 or 2 registers. Sorry, I realize that was too terse. O32/N32/N64 are the names of the ABIs (Application Binary Interfaces) supported on Linux/MIPS. Ah, I see. I attempted to add a short outline of its properties to each mention. ILP32 is a common abbreviation for an ABI with 32bit integer, 32bit long, 32bit pointer size, describing the most important C types. This is like classic Linux i386. The comparable MIPS ABI is O32. LP64 is a shorthand for 64bit long, 64bit pointer size. This is what most 64bit Unices use, one example is Linux AMD64. The comparable MIPS ABI is N64. The N32 ABI is a bit odd, it combines a 32bit address space with 64bit wide registers, but it still retains the classic (ILP32) data type lengths. I mentioned long long since that is the only data type which is subtly different between both ILP32 variants. Maybe this part isn't relevant for ROOT. I guess whether the O32/N32 split is important, depends on where 64bit wide registers registers are used and important. I guess the argument registers refers to variadic arguments, but exactly what that would imply in the ROOT source code I don't know. On MIPS (and most other RISC-like architectures) the first few arguments to a function are passed via registers. From the powerpc code in cint I inferred this is an important property which the code
