Re: Linux-abi group
H.J. Lu wrote: On Thu, Feb 11, 2016 at 8:05 AM, Suprateeka R Hegde wrote: On 11-Feb-2016 07:21 PM, H.J. Lu wrote: On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde wrote: H.J, I think we are fragmenting with too many standards and mailing lists. This new discussion group and eventually the resulting standards, all might be put under LSB http://refspecs.linuxfoundation.org/lsb.shtml The Intro on LSB says: http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html And thats what this proposal is intended for. And we can use the LSB mailing list https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all discussions. What do you think? LSB lists extensions which have been implemented. But it isn't a spec you can use to implement them. For example: http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/progheader.html lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO. But it gives no details. Linux ABI group is the place where we propose extensions before they get implemented. How to implement, according to me, is design details of a particular product. It also depends on the language used to develop the product. Standards, in most cases, are not tied to a language and hence do not enforce implementation details. That is exactly what Linux ABI group tries to address. Please see the Linux gABI extension draft at https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI It describes the conventions and constraints on the implementa- tion of these extensions for interoperability between various tools. Intel ABI allows abi for binary compatibility on intel machines - just copy bins no need to target compile. Linux ABI? linus already suggested this in even 1990's releases: warning: do not share your kernel headers with applications, they might abuse it and anyway software relying on it would break soon (be a waste of time) when new releases released i just noticed myself the BEST PROTECTION against the need of ABI: is a kernel that has abi inside and offers fast exported features on "well known unix interfaces" to what otherwise would make software "machine dependant, fallible, and short lived"
Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]
H.J. Lu wrote: On Tue, Apr 19, 2016 at 7:06 AM, Michael Matz wrote: Hi, On Tue, 19 Apr 2016, Richard Biener wrote: So with all this it sounds that current protected visibility is just broken and we should forgo with it, making it equal to default visibility? Like how? You mean in GCC regarding protected as default visibility? No, that's just throwing out the baby with the water. We should make protected do what it was intended to do and accept that not all invariants that are true for default visible symbols are also true for protected symbols, possibly by ... At least I couldn't decipher a solution that solves all of the issues with protected visibility apart from trying to error at link-time (or runtime?) for the cases that are tricky (impossible?) to solve. Protected visibility is a useful feature. But as it stands today, it is pretty much useless on x86 as seen in ld and ld.so. We have known this defect for a long time, almost from day 1. To make it truly useful, we need to clearly spell out how and when it can be used. We should enforce its limitation in compiler, ld and ld.so so that there is no surprise, either for correctness or performance, at run-time. my prefference would be if you (re)add it: do so such that there is no portability issue with next or previous gcc version (or other cc if possible), and that it be left as optional with a quick note that it is, and insure both on and off both build w/o fail in doing so. picky? thank you, have a nice day!
How can I get started as a GCC developer
Hello everyone, I'd like to help with the modularization of GCC. I've visited the getting started page at the official wiki but its contents seem too old. I'm fairly new to GCC and and I'm bewildered by its huge code base with lengthy and complicated makefiles and sophisticated internal mechanisms. I don't know how to figure out the exact process GCC is built and feel incompetent to make changes to existing code for fear of breaking the underlying mechanisms. Also, it seems to me that the documentation on GCC internals at the official wiki and various resources the wiki points to are not enough to help a newcomer to make significant contribution, since they are largely incomplete and outdated. However, I do have rudimentary knowledge about the structure of the code base and have successfully built a frontend that merely emits a main function that returns 0 for GCC 4.9.0. But I have no idea how I can make further progress other than by aimlessly browsing through the source code. So how can I gain a systematic understanding of the internals of GCC in order to get started with some serious work?
Spelling mistake!
At http://gcc.gnu.org/onlinedocs/libstdc++/manual/streambufs.html Under section 'Buffering', Particularly is written as 'Chaptericularly'. Regards
