Re: x32 psABI draft version 0.2
>>> On 17.02.11 at 18:59, "H.J. Lu" wrote: > On Thu, Feb 17, 2011 at 8:11 AM, Jan Beulich wrote: > On 17.02.11 at 16:49, "H.J. Lu" wrote: >>> On Thu, Feb 17, 2011 at 7:44 AM, Jan Hubicka wrote: > > According to Mozilla folks however REL+RELA scheme used by EABI leads > > to significandly smaller libxul.so size > > > > According to http://glandium.org/blog/?p=1177 the difference is about > > 4-5MB > > (out of approximately 20-30MB shared lib) > > This is orthogonal to x32 psABI. Understood. I am just pointing out that x86-64 Mozilla suffers from startup problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, we would not have this problem here. >>> >>> If people want to see REL+RELA in x32, they have to contribute codes. >> >> That's exactly the wrong way round: First the specification has to allow >> for (but not require) it, and only then does it make sense to write code. >> > > No, it has to be supported at least by static linker and dynamic > linker. Otherwise, no one can use it. I'm afraid I have to disagree: ELF (and the psABI) is not specific to a particular OS, and hence it allowing something doesn't mean the OS ABI may not restrict it. Hence the psABI first has to at least not forbid something (as it currently does for REL on x86-64), in order for an implementation of that something to make sense. Jan
Re: x32 psABI draft version 0.2
>>> On 18.02.11 at 00:07, Jakub Jelinek wrote: > So one way to cut down the size of .rela.dyn section would be a relocation > like > R_X86_64_RELATIVE_BLOCK where applying such a relocation with r_offset O and > r_addend N would be: > uint64_t *ptr = O; > for (i = 0; i < N; i++) > ptr[i] += bias; > Then e.g. > 003ec6d86008 0008 R_X86_64_RELATIVE > 003ec5aef3f3 > 003ec6d86010 0008 R_X86_64_RELATIVE > 003ec5af92f6 > 003ec6d86018 0008 R_X86_64_RELATIVE > 003ec5b06d17 > 003ec6d86020 0008 R_X86_64_RELATIVE > 003ec5b1dc5f > 003ec6d86028 0008 R_X86_64_RELATIVE > 003ec5b1edaf > 003ec6d86030 0008 R_X86_64_RELATIVE > 003ec5b27358 > 003ec6d86038 0008 R_X86_64_RELATIVE > 003ec5b30f9f > 003ec6d86040 0008 R_X86_64_RELATIVE > 003ec5b3317d > 003ec6d86048 0008 R_X86_64_RELATIVE > 003ec5b34479 > could be represented as: > 003ec6d86008 00MN R_X86_64_RELATIVE_BLOCK > 0009 > I see many hundreds of consecutive R_X86_64_RELATIVE relocs in libxul.so, > though > of course it would need much better analysis over larger body of code. > > In most programs if the library is prelinked all relative relocs are skipped > and .rela.dyn for them doesn't need to be even paged in, but Mozilla is > quite > special in that it one of the most common security relevant packages and > thus > wants randomization, but is linked against huge libraries, so the question > is > if Mozilla is the right candidate to drive our decisions on. > > Another alternative to compress relative relocations would be an indirect > relative relocation, which would give you in r_offset address of a block of > addresses > and r_addend the size of that block, and the block would just contain > offsets > on which words need to be += bias. Then, instead of changing RELA to REL to > save 8 bytes from 24 you'd save 16 bytes from those 24 (well, for x32 half > of that). For relocations where the relocated field is large enough, considering chained relocations (as seen in NetWare NLMs) would also be a possibility, i.e. r_offset specifies just the first relocation that all need the same addend (and eventual other properties), and the relocated field holds the r_offset of the next field to be relocated. Jan
AspectG++ ?
Hello Folks You certainly know about aspect orientated programming. http://www.aspectc.org/ Is there any chance that this will ever be integrated into official gcc? Would be cool to define aspect because it would make your code much smaller and more readable. Additionally it comes in very handy if you wanna debug something. best regards David [aka .leviathan] signature.asc Description: This is a digitally signed message part.
AspectG++ ?
Hello Folks You certainly know about aspect orientated programming. http://www.aspectc.org/ Is there any chance that this will ever be integrated into official gcc? Would be cool to define aspect because it would make your code much smaller and more readable. Additionally it comes in very handy if you wanna debug something. best regards David [aka .leviathan] signature.asc Description: This is a digitally signed message part.
Re: PATCH committed: 64-bit Apple Objective-C runtime support
On Thu, Feb 17, 2011 at 06:21:17PM -0800, Mike Stump wrote: > On Feb 17, 2011, at 4:09 PM, Nicola Pero wrote: > > This patch is not me - it's by Iain Sandoe. :-) > > Thanks for chipping in and helping out. I'm excited at having a Objective-C > compiler that works again on darwin. > > That said, if people have any Objective-C codes, feel free to beat on them > and let us know what you find. We're interested in regressions first and > foremost, after that functionality on 64-bit darwin. We know about PCH not > working well in some situations, so, be prepared to turn that off. Did Iain see these failures in his testing at -m64? FAIL: objc/execute/exceptions/foward-1.m execution, -O0 -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -O1 -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -O2 -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer -funroll-loops -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -g -fnext-runtime FAIL: objc/execute/exceptions/foward-1.m execution, -Os -fnext-runtime I am seeing those on x86_64-apple-darwin10. Jack
Re: PATCH committed: 64-bit Apple Objective-C runtime support
Jack,
thanks for testing this out. You can xfail these. Iain sent me this
morning an additional patch that xfails these; he must have forgotten
to include it in the original one.
I'll attach it. I can't commit now; if Mike or you have time, please do.
I understand that the patch is pre-approved by Mike.
Else, I'll commit it myself tonight (GMT). Apologies for the temporary
noise on the m64 testsuite on Darwin.
Thanks
-Original Message-
From: "Jack Howarth"
Sent: Friday, 18 February, 2011 14:10
To: "Mike Stump"
Cc: gcc-patc...@gnu.org, "GCC Development"
Subject: Re: PATCH committed: 64-bit Apple Objective-C runtime support
On Thu, Feb 17, 2011 at 06:21:17PM -0800, Mike Stump wrote:
> On Feb 17, 2011, at 4:09 PM, Nicola Pero wrote:
> > This patch is not me - it's by Iain Sandoe. :-)
>
> Thanks for chipping in and helping out. I'm excited at having a Objective-C
> compiler that works again on darwin.
>
> That said, if people have any Objective-C codes, feel free to beat on them
> and let us know what you find. We're interested in regressions first and
> foremost, after that functionality on 64-bit darwin. We know about PCH not
> working well in some situations, so, be prepared to turn that off.
Did Iain see these failures in his testing at -m64?
FAIL: objc/execute/exceptions/foward-1.m execution, -O0 -fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -O1 -fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -O2 -fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer
-fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer
-funroll-loops -fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions -fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -g -fnext-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -Os -fnext-runtime
I am seeing those on x86_64-apple-darwin10.
Jack
Index: gcc/testsuite/objc/execute/exceptions/foward-1.x
===
--- gcc/testsuite/objc/execute/exceptions/foward-1.x(revision 0)
+++ gcc/testsuite/objc/execute/exceptions/foward-1.x(revision 0)
@@ -0,0 +1,11 @@
+# XFAIL the run for m64 Darwin NeXT (seems to be a system runtime lib problem).
+if { [istarget *-*-darwin*] && [check_effective_target_lp64] } {
+set torture_eval_before_execute {
+global compiler_conditional_xfail_data
+set compiler_conditional_xfail_data {
+ "Target fails for fnext-runtime" "*-*-*" { "-fnext-runtime" } { "" }
+}
+}
+}
+# carry on...
+return false
Re: x32 psABI draft version 0.2
On Fri, Feb 18, 2011 at 12:11 AM, Jan Beulich wrote: On 17.02.11 at 18:59, "H.J. Lu" wrote: >> On Thu, Feb 17, 2011 at 8:11 AM, Jan Beulich wrote: >> On 17.02.11 at 16:49, "H.J. Lu" wrote: On Thu, Feb 17, 2011 at 7:44 AM, Jan Hubicka wrote: >> > According to Mozilla folks however REL+RELA scheme used by EABI leads >> > to significandly smaller libxul.so size >> > >> > According to http://glandium.org/blog/?p=1177 the difference is about >> > 4-5MB >> > (out of approximately 20-30MB shared lib) >> >> This is orthogonal to x32 psABI. > > Understood. I am just pointing out that x86-64 Mozilla suffers from > startup > problems (extra 5MB of disk read needed) compared to both x86 and ARM EABI > because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI is, > we > would not have this problem here. > If people want to see REL+RELA in x32, they have to contribute codes. >>> >>> That's exactly the wrong way round: First the specification has to allow >>> for (but not require) it, and only then does it make sense to write code. >>> >> >> No, it has to be supported at least by static linker and dynamic >> linker. Otherwise, no one can use it. > > I'm afraid I have to disagree: ELF (and the psABI) is not specific to > a particular OS, and hence it allowing something doesn't mean the > OS ABI may not restrict it. Hence the psABI first has to at least not > forbid something (as it currently does for REL on x86-64), in order > for an implementation of that something to make sense. > > Jan > > How about only allowing REL relocations in executables and DSOes? BTW, the psABI source is available on hjl/x32 banch at http://git.kernel.org/?p=devel/binutils/hjl/x86-64-psabi.git;a=summary -- H.J.
Re: AspectG++ ?
On Fri, Feb 18, 2011 at 01:56:47AM -0800, David Lanzendörfer wrote: > Hello Folks > You certainly know about aspect orientated programming. > http://www.aspectc.org/ > Is there any chance that this will ever be integrated into official gcc? > Would be cool to define aspect because it would make your code much smaller > and more readable. Additionally it comes in very handy if you wanna debug > something. The following is just my opinion and others may disagree, but I don't think it's a good idea because I think that the costs would greatly outweigh the benefits. OK, let's assume that the Aspect C++ group contributes a beautifully engineered set of extensions to g++, meeting all the coding standards, done with great style and with a large regression test suite, properly legally assigned to the FSF. Great code, slap the GNU label on it and ship it, right? But then there's the issue that there is no rigorous specification (at the level of a draft ISO standard) for how the Aspect C++ features interact with all other C++ language features (templates, exceptions, rvalue references, the standard library, etc), and the fact that the user community is microscopic as compared to existing GCC-supported languages. Then there's the question of how long we would have a skilled maintainer. It's an academic project. It's a decade old and still around, but all the publications are from one research group, which might eventually move on to some other project. In the meantime, g++ developers who don't know Aspect C++ will face the problem that their checkins break a language that they don't understand. If, on the other hand, the language really catches on, to the point where part or all of Aspect C++ gets into future standards for ISO C++, this of course changes everything.
Re: MIPS: Changing the PC stored from a "and link" instruction
I had already removed all define_delay definitions in mips.md. There were still a few leftover branches that had nop in the delay slot. One of these cases is the first example I showed. I solved the issue by editing the SETUP_GTX macro located in glibc-2.3.6/sysdeps/mips/sys/asm.h The macro was: .set noreorder; move r, $31; /* Save old ra.*/ bal 10f; /* Find addr of cpload./ nop; 10: .cpload $31; move $31, r; .set reorder So I simply removed the nop after the bal instruction. The .cpload function expects the PC of label 10 in the $ra address. Since I am storing the PC of the first instruction of .cpload into $ra (the instruction after bal), then .cpload still functions correctly. -Brandon On 02/18/2011 01:43 AM, Ian Lance Taylor wrote: "Brandon H. Dwiel" writes: I would like to make the changes necessary so that the compiler expects the PC of the instruction directly after the branch to be put in the $ra register. I cannot locate where it is specified that PC+8 of an "and link" instruction is to be put in the $ra so that I may change it. It's not specified in that way. Instead, it's specified that jalr has a delay slot. See the uses of define_delay in gcc/config/mips/mips.md. Ian
Re: AspectG++ ?
>The following is just my opinion and others may disagree, but I don't >think it's a good idea because I think that the costs would greatly >outweigh the benefits. As long as it supports the development of a productive and informative conversation, I'm glad about any kind of opinion. >OK, let's assume that the Aspect C++ group contributes a beautifully >engineered set of extensions to g++, meeting all the coding standards, >done with great style and with a large regression test suite, properly >legally assigned to the FSF. Great code, slap the GNU label on it and >ship it, right? AOP is not a new language. It's just an improofement of OOP. While nowadays we have to put debug-logic into our class declaration, AOP allows us to go a step further and separate the logic from the duty. Instead of putting stderr-streams and such stuff into declarations, we can deploy logging of certain classes and class-groups into separat files. It wouldn't talk "another language", it just would help to express actions a programmer is already programming anyway today in a more unified and eysier way. I'm NO compiler architect, but from my point of perspective - please correct me if I'm wrong - for adding support for AOP into C/C++ part of gcc, only minor changes would be needed. best regards David signature.asc Description: This is a digitally signed message part.
Re: x32 psABI draft version 0.2
> On Fri, Feb 18, 2011 at 12:11 AM, Jan Beulich wrote: > On 17.02.11 at 18:59, "H.J. Lu" wrote: > >> On Thu, Feb 17, 2011 at 8:11 AM, Jan Beulich wrote: > >> On 17.02.11 at 16:49, "H.J. Lu" wrote: > On Thu, Feb 17, 2011 at 7:44 AM, Jan Hubicka wrote: > >> > According to Mozilla folks however REL+RELA scheme used by EABI leads > >> > to significandly smaller libxul.so size > >> > > >> > According to http://glandium.org/blog/?p=1177 the difference is > >> > about 4-5MB > >> > (out of approximately 20-30MB shared lib) > >> > >> This is orthogonal to x32 psABI. > > > > Understood. I am just pointing out that x86-64 Mozilla suffers from > > startup > > problems (extra 5MB of disk read needed) compared to both x86 and ARM > > EABI > > because x86-64 ABI is RELA only. If x86-64 ABI was REL+RELA like EABI > > is, we > > would not have this problem here. > > > > If people want to see REL+RELA in x32, they have to contribute codes. > >>> > >>> That's exactly the wrong way round: First the specification has to allow > >>> for (but not require) it, and only then does it make sense to write code. > >>> > >> > >> No, it has to be supported at least by static linker and dynamic > >> linker. Otherwise, no one can use it. > > > > I'm afraid I have to disagree: ELF (and the psABI) is not specific to > > a particular OS, and hence it allowing something doesn't mean the > > OS ABI may not restrict it. Hence the psABI first has to at least not > > forbid something (as it currently does for REL on x86-64), in order > > for an implementation of that something to make sense. > > > > Jan > > > > > > How about only allowing REL relocations in executables and DSOes? I don't know, I am not really expert in this area. So I am not quit sure if allowing REL is good idea given the mess they imply in binutils sources. I guess it makes sense supposing that it is easy for linker to turn RELAs at input with addend fitting range into RELs. I wondered, based on the Mozilla experience, if we don't want to make REL optional in x86-64 ABI, too? Honza
Re: AspectG++ ?
On 18 February 2011 20:26, David Lanzendörfer wrote: > I'm NO compiler architect, but from my point of perspective - please correct > me if I'm wrong - for adding support for AOP into C/C++ part of gcc, only > minor > changes would be needed. Even if that's true (I don't know, but adding almost anything to g++ is difficult) the point is not "can it be done" but whether someone would be willing to maintain and support the changes. If not, the code will rot and stop working and eventually have to be removed.
Re: AspectG++ ?
On 02/18/2011 02:46 PM, Jonathan Wakely wrote: On 18 February 2011 20:26, David Lanzendörfer wrote: I'm NO compiler architect, but from my point of perspective - please correct me if I'm wrong - for adding support for AOP into C/C++ part of gcc, only minor changes would be needed. Even if that's true (I don't know, but adding almost anything to g++ is difficult) the point is not "can it be done" but whether someone would be willing to maintain and support the changes. If not, the code will rot and stop working and eventually have to be removed. And non-standard extensions are generally not acceptable. -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: AspectG++ ?
>And non-standard extensions are generally not acceptable. Well, I think as soon as people begin to use it, even gcc itself might become more and more aspect orientated (at the c-parts). It's one of the aspects of AOP that sourcecode will be stripped down enormous, because generalization is much eaysier. But anyway, seems as there is really no ISO standard yet for AOP. Seems as there first have to be made some definitions, before I can hope to use AOP features in my one-and-only compiler... :-( Ok, well, in this case, let me ask a very naive question: Who do I need to mail to, in order to motivate the definition of an ISO standard for AOP in C/C++? ^.^" best regards David signature.asc Description: This is a digitally signed message part.
Re: AspectG++ ?
On 18 February 2011 21:59, David Lanzendörfer wrote: > > Ok, well, in this case, let me ask a very naive question: > Who do I need to mail to, in order to motivate the definition of an ISO > standard for AOP in C/C++? ^.^" You could contact your national standards body, or post to the comp.std.c++ newsgroup. But you'll have a better chance if you stop saying C/C++, they're two separate languages, with separate standards and standardisation processes. And the ISO committees will not standardise a niche product just because someone asks them to. You'd need to demonstrate interest from a significant user base and/or compiler vendors.
Re: AspectG++ ?
On 2/18/2011 4:59 PM, David Lanzendörfer wrote: And non-standard extensions are generally not acceptable. Well, I think as soon as people begin to use it, even gcc itself might become more and more aspect orientated (at the c-parts). It's one of the aspects of AOP that sourcecode will be stripped down enormous, because generalization is much eaysier. But anyway, seems as there is really no ISO standard yet for AOP. Seems as there first have to be made some definitions, before I can hope to use AOP features in my one-and-only compiler... :-( Ok, well, in this case, let me ask a very naive question: Who do I need to mail to, in order to motivate the definition of an ISO standard for AOP in C/C++? ^.^" You can contact a commercial company that deals with gcc, and be prepared to pay the cost (which I am sure would be substantial). Or you can do it yourself. best regards David
Re: AspectG++ ?
On 2/18/2011 8:05 PM, Robert Dewar wrote: On 2/18/2011 4:59 PM, David Lanzendörfer wrote: And non-standard extensions are generally not acceptable. Well, I think as soon as people begin to use it, even gcc itself might become more and more aspect orientated (at the c-parts). It's one of the aspects of AOP that sourcecode will be stripped down enormous, because generalization is much eaysier. But anyway, seems as there is really no ISO standard yet for AOP. Seems as there first have to be made some definitions, before I can hope to use AOP features in my one-and-only compiler... :-( Ok, well, in this case, let me ask a very naive question: Who do I need to mail to, in order to motivate the definition of an ISO standard for AOP in C/C++? ^.^" You can contact a commercial company that deals with gcc, and be prepared to pay the cost (which I am sure would be substantial). Or you can do it yourself. Ah, sorry I missed the ISO. This is indeed a naive question. Standardizing something like this is a huge effort. Assuming the existence of an enthusiastic bunch of people from multiple countries to work on this, you are talking about a design effort that would take years, followed by a standardization effort that would take years. You can't just take along your home grown half-baked definition of a language and expect to get an ISO stamp for it. Furthermore, as someone else pointed out saying C/C++ means you are seriously confused to start with. These are two separate languages with two separate standardization bodies that don't always cooperate with one another. best regards David
Re: x32 psABI status update
On Wed, Feb 16, 2011 at 9:45 PM, H.J. Lu wrote: > On Wed, Feb 16, 2011 at 11:22 AM, H.J. Lu wrote: >> Hi, >> >> I updated x32 psABI draft to version 0.2 to change x32 library path >> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian, >> Ubuntu and other derivative distributions. The new x32 psABI is >> available from: >> >> https://sites.google.com/site/x32abi/home >> > > Initial kernel, glibc and gcc port for x32 psABI draft version 0.2 is done: > > 1. Kernel should be very stable. Fedora 14 kernel patch is also available. > 2. Need to fix GCC run-time libraries. > 3. Need to fix glibc tests. > > Please check them out and provide feed backs. I updated x32 website: https://sites.google.com/site/x32abi/ with "get started" instructions. -- H.J.
Re: GCC 4.6.0 Status Report (2011-02-13)
2011/2/13 Joseph S. Myers : > User-visible improvements relative to 4.5 should also be > documented in gcc-4.6/changes.html if not already mentioned there. We also have a new section for developer-visible changes which would be helpful for plugin and out-of-the-tree front-/back-end developers, please feel free to expand that section too. -- Laurynas
