* [patch] adjust libgloss addresses for 64-bit @ 2005-04-14 22:08 Eric Christopher 2005-04-14 22:38 ` Thiemo Seufer 0 siblings, 1 reply; 21+ messages in thread From: Eric Christopher @ 2005-04-14 22:08 UTC (permalink / raw) To: newlib, binutils; +Cc: cgd Here's another shot at this. The problem that we encounter is that for 64-bit addresses "la" (or dla for that matter) does not sign extend the constant passed in the case of: la $2,0x80000000 leaving us with a zero-extended value in a register which is unpredictable as far as the standard (and at least one chip out there) is concerned. One option would be to modify the assembler to automatically sign-extend when in the presence of constants that are smaller than a single register. Not a bad idea, but we should also just be precise in what we pass as well. Since gas will accept sign extended constants from la when we're using a 64-bit pointers we can probably get by with this patch as well. The issue of whether or not to automagically sign extend when we load addresses is a separate one I think really in this case. Thoughts? -eric 2005-04-12 Eric Christopher <echristo@redhat.com> * mips/regs.S: For __mips64 sign-extend K0BASE. Clean up K1BASE_ADDR handling. Index: mips/regs.S =================================================================== RCS file: /cvs/src/src/libgloss/mips/regs.S,v retrieving revision 1.3 diff -u -p -r1.3 regs.S --- mips/regs.S 3 Apr 2004 01:02:51 -0000 1.3 +++ mips/regs.S 14 Apr 2005 22:04:32 -0000 @@ -53,15 +53,16 @@ #define fp1 $f1 /* Useful memory constants: */ -#define K0BASE 0x80000000 #ifndef __mips64 +#define K0BASE 0x80000000 #define K1BASE 0xA0000000 #define K0BASE_ADDR ((char *)K0BASE) #define K1BASE_ADDR ((char *)K1BASE) #else -#define K1BASE 0xFFFFFFFFA0000000LL +#define K0BASE 0xFFFFFFFF80000000 +#define K1BASE 0xFFFFFFFFA0000000 #define K0BASE_ADDR ((char *)0xFFFFFFFF80000000LL) -#define K1BASE_ADDR ((char *)K1BASE) +#define K1BASE_ADDR ((char *)0xFFFFFFFFA0000000LL) #endif #define PHYS_TO_K1(a) ((unsigned)(a) | K1BASE) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-14 22:08 [patch] adjust libgloss addresses for 64-bit Eric Christopher @ 2005-04-14 22:38 ` Thiemo Seufer 2005-04-15 10:32 ` Maciej W. Rozycki 0 siblings, 1 reply; 21+ messages in thread From: Thiemo Seufer @ 2005-04-14 22:38 UTC (permalink / raw) To: Eric Christopher; +Cc: newlib, binutils, cgd Eric Christopher wrote: > Here's another shot at this. The problem that we encounter is that for > 64-bit addresses "la" (or dla for that matter) does not sign extend the > constant passed in the case of: > > la $2,0x80000000 > > leaving us with a zero-extended value in a register which is > unpredictable as far as the standard (and at least one chip out there) > is concerned. One option would be to modify the assembler to > automatically sign-extend when in the presence of constants that are > smaller than a single register. I think la should load a proper address for 32bit address space, even when used in code with 64bit addresses. That's the most useful behaviour for it. > Not a bad idea, but we should also just be precise in what we pass as > well. Since gas will accept sign extended constants from la when we're > using a 64-bit pointers we can probably get by with this patch as well. FWIW, the Linux kernel uses this approach for a while now. Thiemo ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-14 22:38 ` Thiemo Seufer @ 2005-04-15 10:32 ` Maciej W. Rozycki 2005-04-15 11:28 ` Thiemo Seufer 2005-04-15 16:50 ` Eric Christopher 0 siblings, 2 replies; 21+ messages in thread From: Maciej W. Rozycki @ 2005-04-15 10:32 UTC (permalink / raw) To: Thiemo Seufer; +Cc: Eric Christopher, newlib, binutils, cgd On Fri, 15 Apr 2005, Thiemo Seufer wrote: > > Here's another shot at this. The problem that we encounter is that for > > 64-bit addresses "la" (or dla for that matter) does not sign extend the > > constant passed in the case of: > > > > la $2,0x80000000 > > > > leaving us with a zero-extended value in a register which is > > unpredictable as far as the standard (and at least one chip out there) Hmm, 0x80000000 should be a valid XKUSEG address... > > is concerned. One option would be to modify the assembler to > > automatically sign-extend when in the presence of constants that are > > smaller than a single register. > > I think la should load a proper address for 32bit address space, even > when used in code with 64bit addresses. That's the most useful > behaviour for it. So what should "la $2,0x80000000($3)" do when using 64-bit addresses? Replace/supplement the offset with a symbol as suitable... Maciej ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 10:32 ` Maciej W. Rozycki @ 2005-04-15 11:28 ` Thiemo Seufer 2005-04-15 16:50 ` Eric Christopher 2005-04-15 16:50 ` Eric Christopher 1 sibling, 1 reply; 21+ messages in thread From: Thiemo Seufer @ 2005-04-15 11:28 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Eric Christopher, newlib, binutils, cgd Maciej W. Rozycki wrote: [snip] > > I think la should load a proper address for 32bit address space, even > > when used in code with 64bit addresses. That's the most useful > > behaviour for it. > > So what should "la $2,0x80000000($3)" do when using 64-bit addresses? > Replace/supplement the offset with a symbol as suitable... Hm, looks like we break somebody's assumptions regardless what we do. So leaving la as it is and warn about its use seems to be best. Thiemo ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 11:28 ` Thiemo Seufer @ 2005-04-15 16:50 ` Eric Christopher 2005-04-15 19:37 ` Thiemo Seufer 0 siblings, 1 reply; 21+ messages in thread From: Eric Christopher @ 2005-04-15 16:50 UTC (permalink / raw) To: Thiemo Seufer; +Cc: Maciej W. Rozycki, newlib, binutils, cgd > > So what should "la $2,0x80000000($3)" do when using 64-bit addresses? > > Replace/supplement the offset with a symbol as suitable... > > Hm, looks like we break somebody's assumptions regardless what we do. > So leaving la as it is and warn about its use seems to be best. To warn we should do two things: 1) Turn HAVE_64BIT_OBJECTS back to HAVE_64BIT_ADDRESSES in do_la. 2) Warn if we have O_constant as the type and it isn't a sign-extended 32-bit number. -eric ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 16:50 ` Eric Christopher @ 2005-04-15 19:37 ` Thiemo Seufer 0 siblings, 0 replies; 21+ messages in thread From: Thiemo Seufer @ 2005-04-15 19:37 UTC (permalink / raw) To: Eric Christopher; +Cc: Maciej W. Rozycki, newlib, binutils, cgd Eric Christopher wrote: > > > > So what should "la $2,0x80000000($3)" do when using 64-bit addresses? > > > Replace/supplement the offset with a symbol as suitable... > > > > Hm, looks like we break somebody's assumptions regardless what we do. > > So leaving la as it is and warn about its use seems to be best. > > > To warn we should do two things: > > 1) Turn HAVE_64BIT_OBJECTS back to HAVE_64BIT_ADDRESSES in do_la. > 2) Warn if we have O_constant as the type and it isn't a sign-extended > 32-bit number. Agreed. Maybe we can make la invalid for 64bit register after 2.16. Thiemo ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 10:32 ` Maciej W. Rozycki 2005-04-15 11:28 ` Thiemo Seufer @ 2005-04-15 16:50 ` Eric Christopher 2005-04-15 17:03 ` Maciej W. Rozycki 1 sibling, 1 reply; 21+ messages in thread From: Eric Christopher @ 2005-04-15 16:50 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Thiemo Seufer, newlib, binutils, cgd > > > leaving us with a zero-extended value in a register which is > > > unpredictable as far as the standard (and at least one chip out there) > > Hmm, 0x80000000 should be a valid XKUSEG address... > Nothing wrong with the address, but it's loaded as: ori $2,0x8000 dsll $2,$2,0x10 so it's zero extended and not sign extended as it should be. -eric ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 16:50 ` Eric Christopher @ 2005-04-15 17:03 ` Maciej W. Rozycki 2005-04-15 17:07 ` Eric Christopher 2005-04-15 17:18 ` Thiemo Seufer 0 siblings, 2 replies; 21+ messages in thread From: Maciej W. Rozycki @ 2005-04-15 17:03 UTC (permalink / raw) To: Eric Christopher; +Cc: Thiemo Seufer, newlib, binutils, cgd On Fri, 15 Apr 2005, Eric Christopher wrote: > > > > leaving us with a zero-extended value in a register which is > > > > unpredictable as far as the standard (and at least one chip out there) > > > > Hmm, 0x80000000 should be a valid XKUSEG address... > > > > Nothing wrong with the address, but it's loaded as: > > ori $2,0x8000 > dsll $2,$2,0x10 > > so it's zero extended and not sign extended as it should be. Of course it is zero-extended. Otherwise it would be a different one; actually in the CKSEG0 space rather than XKUSEG. If you want the former, what's wrong with 0xffffffff80000000? -- please keep in mind we are talking about 64-bit addressing. Maciej ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 17:03 ` Maciej W. Rozycki @ 2005-04-15 17:07 ` Eric Christopher 2005-04-18 12:46 ` Maciej W. Rozycki 2005-04-15 17:18 ` Thiemo Seufer 1 sibling, 1 reply; 21+ messages in thread From: Eric Christopher @ 2005-04-15 17:07 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Thiemo Seufer, newlib, binutils, cgd > > Of course it is zero-extended. Otherwise it would be a different one; > actually in the CKSEG0 space rather than XKUSEG. If you want the former, > what's wrong with 0xffffffff80000000? -- please keep in mind we are > talking about 64-bit addressing. Hrm. Good point. This thread was mostly because of unpredictable errors from the assembler in crt0.S. The "location" that crt0 is trying to load is "K0BASE" which is likely CKSEG0, and yes, I have sign extended the constant used in the patch that started this thread :) (personally I think if we want to load a constant into a register using a macro we should use li, not la). -eric ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 17:07 ` Eric Christopher @ 2005-04-18 12:46 ` Maciej W. Rozycki 0 siblings, 0 replies; 21+ messages in thread From: Maciej W. Rozycki @ 2005-04-18 12:46 UTC (permalink / raw) To: Eric Christopher; +Cc: Thiemo Seufer, newlib, binutils, cgd On Fri, 15 Apr 2005, Eric Christopher wrote: > (personally I think if we want to load a constant into a register using > a macro we should use li, not la). Absolutely. Sometimes it may be hard to fulfil, though, e.g. the address supplied may be a result of macro expansion at the preprocessing stage and depending on some options it may expand either to a constant or to something else, e.g. a symbol. Making the instruction a part of the expansion may be difficult or at least obscure. And a constant is a valid address after all. ;-) Maciej ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 17:03 ` Maciej W. Rozycki 2005-04-15 17:07 ` Eric Christopher @ 2005-04-15 17:18 ` Thiemo Seufer 2005-04-15 17:35 ` Paul Koning 1 sibling, 1 reply; 21+ messages in thread From: Thiemo Seufer @ 2005-04-15 17:18 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Eric Christopher, newlib, binutils, cgd Maciej W. Rozycki wrote: > On Fri, 15 Apr 2005, Eric Christopher wrote: > > > > > > leaving us with a zero-extended value in a register which is > > > > > unpredictable as far as the standard (and at least one chip out there) > > > > > > Hmm, 0x80000000 should be a valid XKUSEG address... > > > > > > > Nothing wrong with the address, but it's loaded as: > > > > ori $2,0x8000 > > dsll $2,$2,0x10 > > > > so it's zero extended and not sign extended as it should be. > > Of course it is zero-extended. Otherwise it would be a different one; > actually in the CKSEG0 space rather than XKUSEG. If you want the former, > what's wrong with 0xffffffff80000000? -- please keep in mind we are > talking about 64-bit addressing. But people used to use "la $2, 0x80000000" in order to get a sign-extended address. Loading two different addresses with the same code is at least surprising. I see la in 64bit mode as backward compatibility legacy, and this suggests not to change its behaviour. Thiemo ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 17:18 ` Thiemo Seufer @ 2005-04-15 17:35 ` Paul Koning 2005-04-15 18:56 ` Maciej W. Rozycki 0 siblings, 1 reply; 21+ messages in thread From: Paul Koning @ 2005-04-15 17:35 UTC (permalink / raw) To: ths; +Cc: macro, echristo, newlib, binutils, cgd >>>>> "Thiemo" == Thiemo Seufer <ths@networkno.de> writes: >> Of course it is zero-extended. Otherwise it would be a different >> one; actually in the CKSEG0 space rather than XKUSEG. If you want >> the former, what's wrong with 0xffffffff80000000? -- please keep >> in mind we are talking about 64-bit addressing. Thiemo> But people used to use "la $2, 0x80000000" in order to get a Thiemo> sign-extended address. Loading two different addresses with Thiemo> the same code is at least surprising. I see la in 64bit mode Thiemo> as backward compatibility legacy, and this suggests not to Thiemo> change its behaviour. Agreed. Addresses are signed values on MIPS. Dxx opcodes are 64 bit operations; xx opcodes (when Dxx also exists) are 32 bit operations. So DLI loads a 64 bit int and LI a 32 bit int. DLA loads a 64 bit address and LA a 32 bit address. So the operand of LA should be a construct that is a valid 32 bit address (and 0x80000000 is one such) and it should be expanded into instructions that produce a valid representation of that address in a register (i.e., with sign extension if the registers are 64 bits). paul ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 17:35 ` Paul Koning @ 2005-04-15 18:56 ` Maciej W. Rozycki 2005-04-15 19:25 ` Paul Koning ` (3 more replies) 0 siblings, 4 replies; 21+ messages in thread From: Maciej W. Rozycki @ 2005-04-15 18:56 UTC (permalink / raw) To: Paul Koning; +Cc: ths, echristo, newlib, binutils, cgd On Fri, 15 Apr 2005, Paul Koning wrote: > So DLI loads a 64 bit int and LI a 32 bit int. DLA loads a 64 bit > address and LA a 32 bit address. So the operand of LA should be a > construct that is a valid 32 bit address (and 0x80000000 is one such) > and it should be expanded into instructions that produce a valid > representation of that address in a register (i.e., with sign > extension if the registers are 64 bits). With, "li" vs "dli" the definition is rather obvious and unambiguous. It's not with "la" vs "dla". With the (n)64 ABI what should the following macros expand to: la $2, 0x80000000 la $2, 0x80000000($3) la $2, foo + 0x80000000($3) la $2, foo + 0xc000000080000000($3) In particular, assuming the RHS operand is sign-extended, should "sll $2, $3, 0" be performed as a part of the three latters? What about "foo"? Or the 64-bit offset? But in principle you are right for consistency the presence or the lack of the "d" prefix should imply the size of the operands used as it is so for other assembly instructions. So how about disabling the "wrong" macros completely? That is using as_bad() for these two "dla/la used to load..." messages just below "do_la" that are currently warnings. After all these load address macros are the only place where non-default address calculation rules can be argued about at all -- the interpretation of e.g.: lh $2, 0x80000000 lh $2, 0x80000000($3) lh $2, foo + 0x80000000($3) lh $2, foo + 0xc000000080000000($3) is rather out of question, isn't it? Maciej ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 18:56 ` Maciej W. Rozycki @ 2005-04-15 19:25 ` Paul Koning 2005-04-15 19:28 ` Paul Koning ` (2 subsequent siblings) 3 siblings, 0 replies; 21+ messages in thread From: Paul Koning @ 2005-04-15 19:25 UTC (permalink / raw) To: macro; +Cc: ths, echristo, newlib, binutils, cgd >>>>> "Maciej" == Maciej W Rozycki <macro@linux-mips.org> writes: Maciej> On Fri, 15 Apr 2005, Paul Koning wrote: >> So DLI loads a 64 bit int and LI a 32 bit int. DLA loads a 64 bit >> address and LA a 32 bit address. So the operand of LA should be a >> construct that is a valid 32 bit address (and 0x80000000 is one >> such) and it should be expanded into instructions that produce a >> valid representation of that address in a register (i.e., with >> sign extension if the registers are 64 bits). Maciej> With, "li" vs "dli" the definition is rather obvious and Maciej> unambiguous. It's not with "la" vs "dla". With the (n)64 Maciej> ABI what should the following macros expand to: Maciej> la $2, 0x80000000 la $2, 0x80000000($3) la $2, foo + Maciej> 0x80000000($3) la $2, foo + 0xc000000080000000($3) Maciej> In particular, assuming the RHS operand is sign-extended, Maciej> should "sll $2, $3, 0" be performed as a part of the three Maciej> latters? What about "foo"? Or the 64-bit offset? In all cases, I would say the argument (offset argument in the case where a register is also used -- didn't realize that case even existed...) should be a 32 bit value. So the first to cases are fine, with sign extended values. The third and fourth are fine if the expression reduces to a 32 bit value. paul ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 18:56 ` Maciej W. Rozycki 2005-04-15 19:25 ` Paul Koning @ 2005-04-15 19:28 ` Paul Koning 2005-04-15 19:35 ` Thiemo Seufer 2005-04-15 20:57 ` cgd 2005-04-16 10:31 ` Richard Sandiford 3 siblings, 1 reply; 21+ messages in thread From: Paul Koning @ 2005-04-15 19:28 UTC (permalink / raw) To: macro; +Cc: ths, echristo, newlib, binutils, cgd >>>>> "Maciej" == Maciej W Rozycki <macro@linux-mips.org> writes: Maciej> But in principle you are right for consistency the presence Maciej> or the lack of the "d" prefix should imply the size of the Maciej> operands used as it is so for other assembly instructions. Maciej> So how about disabling the "wrong" macros completely? That Maciej> is using as_bad() for these two "dla/la used to load..." Maciej> messages just below "do_la" that are currently warnings. Maciej> After all these load address macros are the only place where Maciej> non-default address calculation rules can be argued about at Maciej> all -- the interpretation of e.g.: Maciej> lh $2, 0x80000000 lh $2, 0x80000000($3) lh $2, foo + Maciej> 0x80000000($3) lh $2, foo + 0xc000000080000000($3) One answer would be to use an implicit DLA for N64, and LA otherwise. I was thinking more about explicitly written LA vs. DLA. All this demonstrates once again that the whole built-in macro stuff in the MIPS assembler was a design blunder from day one. Sigh. Fortunately, GCC no longer uses any of this... paul ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 19:28 ` Paul Koning @ 2005-04-15 19:35 ` Thiemo Seufer 2005-04-16 10:26 ` Richard Sandiford 0 siblings, 1 reply; 21+ messages in thread From: Thiemo Seufer @ 2005-04-15 19:35 UTC (permalink / raw) To: Paul Koning; +Cc: macro, echristo, newlib, binutils, cgd Paul Koning wrote: > >>>>> "Maciej" == Maciej W Rozycki <macro@linux-mips.org> writes: > > Maciej> But in principle you are right for consistency the presence > Maciej> or the lack of the "d" prefix should imply the size of the > Maciej> operands used as it is so for other assembly instructions. > Maciej> So how about disabling the "wrong" macros completely? That > Maciej> is using as_bad() for these two "dla/la used to load..." > Maciej> messages just below "do_la" that are currently warnings. > Maciej> After all these load address macros are the only place where > Maciej> non-default address calculation rules can be argued about at > Maciej> all -- the interpretation of e.g.: > > Maciej> lh $2, 0x80000000 lh $2, 0x80000000($3) lh $2, foo + > Maciej> 0x80000000($3) lh $2, foo + 0xc000000080000000($3) > > One answer would be to use an implicit DLA for N64, and LA otherwise. > I was thinking more about explicitly written LA vs. DLA. > > All this demonstrates once again that the whole built-in macro stuff > in the MIPS assembler was a design blunder from day one. Sigh. > > Fortunately, GCC no longer uses any of this... For 64bit non-PIC it still does. Thiemo ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 19:35 ` Thiemo Seufer @ 2005-04-16 10:26 ` Richard Sandiford 0 siblings, 0 replies; 21+ messages in thread From: Richard Sandiford @ 2005-04-16 10:26 UTC (permalink / raw) To: Thiemo Seufer; +Cc: Paul Koning, macro, echristo, newlib, binutils, cgd Thiemo Seufer <ths@networkno.de> writes: >> Fortunately, GCC no longer uses any of this... > > For 64bit non-PIC it still does. That's true for 3.4, but the soon-to-be-released 4.0 will avoid macros across the board. Richard ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 18:56 ` Maciej W. Rozycki 2005-04-15 19:25 ` Paul Koning 2005-04-15 19:28 ` Paul Koning @ 2005-04-15 20:57 ` cgd 2005-04-18 12:58 ` Maciej W. Rozycki 2005-04-16 10:31 ` Richard Sandiford 3 siblings, 1 reply; 21+ messages in thread From: cgd @ 2005-04-15 20:57 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Paul Koning, ths, echristo, newlib, binutils At Fri, 15 Apr 2005 19:56:48 +0100 (BST), Maciej W. Rozycki wrote: > With, "li" vs "dli" the definition is rather obvious and unambiguous. > It's not with "la" vs "dla". With the (n)64 ABI what should the > following macros expand to: > [ ... ] Whatever SGI's assembler expands them into? 8-) With warnings for where that differs from historic GNU binutils behaviour? (just a suggestion. 8-) chris ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 20:57 ` cgd @ 2005-04-18 12:58 ` Maciej W. Rozycki 2005-04-18 19:32 ` Eric Christopher 0 siblings, 1 reply; 21+ messages in thread From: Maciej W. Rozycki @ 2005-04-18 12:58 UTC (permalink / raw) To: cgd; +Cc: Paul Koning, ths, echristo, newlib, binutils On Fri, 15 Apr 2005 cgd@broadcom.com wrote: > > With, "li" vs "dli" the definition is rather obvious and unambiguous. > > It's not with "la" vs "dla". With the (n)64 ABI what should the > > following macros expand to: > > [ ... ] > > Whatever SGI's assembler expands them into? 8-) Well, but does it actually fit all the variations of -mabi=/-march= that we implement? I have no access to that tool, so I can't tell... > With warnings for where that differs from historic GNU binutils > behaviour? Well, I'd rather warn about dangerous constructs. Finding out the difference to historic GNU binutils behaviour may be tough as for the corner cases the sets will be different depending on the version chosen. If you're careful enough with that choice, you may actually end up with disjoint sets... Trivial cases, like "la $2, 0" are likely to have always worked as expected. ;-) Maciej ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-18 12:58 ` Maciej W. Rozycki @ 2005-04-18 19:32 ` Eric Christopher 0 siblings, 0 replies; 21+ messages in thread From: Eric Christopher @ 2005-04-18 19:32 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: cgd, Paul Koning, ths, newlib, binutils > > Whatever SGI's assembler expands them into? 8-) > > Well, but does it actually fit all the variations of -mabi=/-march= that > we implement? I have no access to that tool, so I can't tell... > No, but we can extrapolate a bit :) > Well, I'd rather warn about dangerous constructs. Agreed. -eric ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [patch] adjust libgloss addresses for 64-bit 2005-04-15 18:56 ` Maciej W. Rozycki ` (2 preceding siblings ...) 2005-04-15 20:57 ` cgd @ 2005-04-16 10:31 ` Richard Sandiford 3 siblings, 0 replies; 21+ messages in thread From: Richard Sandiford @ 2005-04-16 10:31 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: Paul Koning, ths, echristo, newlib, binutils, cgd "Maciej W. Rozycki" <macro@linux-mips.org> writes: > But in principle you are right for consistency the presence or the lack > of the "d" prefix should imply the size of the operands used as it is so > for other assembly instructions. So how about disabling the "wrong" > macros completely? That is using as_bad() for these two "dla/la used to > load..." messages just below "do_la" that are currently warnings. After > all these load address macros are the only place where non-default address > calculation rules can be argued about at all -- the interpretation of > e.g.: > > lh $2, 0x80000000 > lh $2, 0x80000000($3) > lh $2, foo + 0x80000000($3) > lh $2, foo + 0xc000000080000000($3) > > is rather out of question, isn't it? Yeah, FWIW, this sounds like a good idea to me. I think these threads show that there's no obvious answer and that whatever we do will surprise someone. Richard ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2005-04-18 19:32 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-04-14 22:08 [patch] adjust libgloss addresses for 64-bit Eric Christopher 2005-04-14 22:38 ` Thiemo Seufer 2005-04-15 10:32 ` Maciej W. Rozycki 2005-04-15 11:28 ` Thiemo Seufer 2005-04-15 16:50 ` Eric Christopher 2005-04-15 19:37 ` Thiemo Seufer 2005-04-15 16:50 ` Eric Christopher 2005-04-15 17:03 ` Maciej W. Rozycki 2005-04-15 17:07 ` Eric Christopher 2005-04-18 12:46 ` Maciej W. Rozycki 2005-04-15 17:18 ` Thiemo Seufer 2005-04-15 17:35 ` Paul Koning 2005-04-15 18:56 ` Maciej W. Rozycki 2005-04-15 19:25 ` Paul Koning 2005-04-15 19:28 ` Paul Koning 2005-04-15 19:35 ` Thiemo Seufer 2005-04-16 10:26 ` Richard Sandiford 2005-04-15 20:57 ` cgd 2005-04-18 12:58 ` Maciej W. Rozycki 2005-04-18 19:32 ` Eric Christopher 2005-04-16 10:31 ` Richard Sandiford
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).