ਗੂਗਲ ਦੇ ਡਿਵੈਲਪਰਾਂ ਨੇ LLVM ਲਈ ਆਪਣੀ ਖੁਦ ਦੀ libc ਵਿਕਸਿਤ ਕਰਨ ਦਾ ਸੁਝਾਅ ਦਿੱਤਾ

ਗੂਗਲ ਦੇ ਡਿਵੈਲਪਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਉਠਾਇਆ LLVM ਪ੍ਰੋਜੈਕਟ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਮਲਟੀ-ਪਲੇਟਫਾਰਮ ਸਟੈਂਡਰਡ C ਲਾਇਬ੍ਰੇਰੀ (Libc) ਦੇ ਵਿਕਾਸ ਬਾਰੇ LLVM ਮੇਲਿੰਗ ਲਿਸਟ 'ਤੇ। ਕਈ ਕਾਰਨਾਂ ਕਰਕੇ, Google ਮੌਜੂਦਾ libc (glibc, musl) ਤੋਂ ਸੰਤੁਸ਼ਟ ਨਹੀਂ ਹੈ ਅਤੇ ਕੰਪਨੀ ਇੱਕ ਨਵੇਂ ਲਾਗੂਕਰਨ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਦੇ ਰਾਹ 'ਤੇ ਹੈ, ਜਿਸ ਨੂੰ LLVM ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਵਿਕਸਤ ਕਰਨ ਦਾ ਪ੍ਰਸਤਾਵ ਹੈ।

LLVM ਵਿਕਾਸ ਨੂੰ ਹਾਲ ਹੀ ਵਿੱਚ ਗੂਗਲ ਦੇ ਅਸੈਂਬਲੀ ਟੂਲ ਬਣਾਉਣ ਲਈ ਆਧਾਰ ਵਜੋਂ ਵਰਤਿਆ ਗਿਆ ਹੈ। ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਜੇਕਰ ਗੂਗਲ ਨੇ ਪਹਿਲਾਂ ਹੀ ਆਪਣੀ libc ਨੂੰ ਵਿਕਸਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਹੈ, ਤਾਂ ਕਿਉਂ ਨਾ ਤੁਰੰਤ ਆਪਣੇ ਸਿਸਟਮ ਨੂੰ LLVM ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਵਿਕਸਤ ਕੀਤਾ ਜਾਵੇ, ਜੋ ਪਹਿਲਾਂ ਹੀ C++ (Libc++) ਲਈ ਆਪਣੀ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ, ਪਰ C ਲਈ ਸਮਾਨ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ ਨਹੀਂ ਹੈ। (libc)।

ਵਿਕਾਸ ਨੂੰ ਪੜਾਵਾਂ ਵਿੱਚ ਕੀਤੇ ਜਾਣ ਦੀ ਯੋਜਨਾ ਹੈ, ਹੌਲੀ ਹੌਲੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਵਿੱਚ ਵਾਧਾ. ਪਹਿਲੇ ਵਿਕਲਪਾਂ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਸਿਸਟਮ Libc ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਪਰਤ ਦੇ ਰੂਪ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਤਜਵੀਜ਼ ਹੈ, ਜਿਸ ਤੋਂ ਉਹ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜੋ ਅਜੇ ਤੱਕ ਲਾਗੂ ਨਹੀਂ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ ਉਧਾਰ ਲਈਆਂ ਜਾਣਗੀਆਂ। ਕਾਰਜਸ਼ੀਲਤਾ ਦੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਪੱਧਰ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਬਾਅਦ, ਨਵੇਂ Libc ਨੂੰ ਸਿਸਟਮ Libc ਲਈ ਇੱਕ ਪੂਰਨ ਬਦਲ ਵਜੋਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਸੀਂ x86-64 ਆਰਕੀਟੈਕਚਰ, ਲੀਨਕਸ, ਅਤੇ ਸਥਿਰ ਲਿੰਕਿੰਗ (ਡਾਇਨਾਮਿਕ ਲੋਡਿੰਗ, ਲਿੰਕਿੰਗ, ਅਤੇ ਵਾਧੂ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਦੂਜੇ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ) ਲਈ ਸਮਰਥਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ।

ਪ੍ਰੋਜੈਕਟ ਅਜੇ ਵੀ ਵਿਕਾਸ ਦੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ ਹੈ, ਪਰ ਬੁਨਿਆਦੀ ਟੀਚਿਆਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ:

• ਇੱਕ ਮੋਨੋਲਿਥਿਕ ਸੈੱਟ ਦੀ ਬਜਾਏ ਇੱਕ ਦਾਣੇਦਾਰ ਲਾਇਬ੍ਰੇਰੀ ਪ੍ਰਦਾਨ ਕਰਨ ਦੇ ਦਰਸ਼ਨ ਦੇ ਅਨੁਸਾਰ ਮਾਡਯੂਲਰਿਟੀ ਅਤੇ ਵਿਕਾਸ;
• ਮੋਡਾਂ ਵਿੱਚ ਸਥਿਰ ਲਿੰਕਿੰਗ ਲਈ ਸਮਰਥਨ FOOT (ਪੋਜ਼ੀਸ਼ਨ-ਸੁਤੰਤਰ ਐਗਜ਼ੀਕਿਊਟੇਬਲ) ਅਤੇ PIE ਤੋਂ ਬਿਨਾਂ। ਸਟੈਟਿਕਲੀ ਲਿੰਕਡ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਲਈ CRT (C ਰਨਟਾਈਮ) ਅਤੇ PIE ਲੋਡਰ ਪ੍ਰਦਾਨ ਕਰਨਾ;
• POSIX ਜੋੜਾਂ ਅਤੇ ਮੌਜੂਦਾ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੁਆਰਾ ਲੋੜੀਂਦੇ ਕੁਝ ਸਿਸਟਮ-ਵਿਸ਼ੇਸ਼ ਐਕਸਟੈਂਸ਼ਨਾਂ ਦੇ ਨਾਲ ਜ਼ਿਆਦਾਤਰ ਮਿਆਰੀ C ਲਾਇਬ੍ਰੇਰੀ ਫੰਕਸ਼ਨਾਂ ਲਈ ਸਮਰਥਨ;
• ਵਿਕਰੇਤਾ-ਵਿਸ਼ੇਸ਼ ਐਕਸਟੈਂਸ਼ਨਾਂ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ ਅਤੇ ਲੋੜ ਪੈਣ 'ਤੇ ਹੀ ਉਹਨਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ। ਥਰਡ-ਪਾਰਟੀ ਐਕਸਟੈਂਸ਼ਨਾਂ ਲਈ ਸਮਰਥਨ ਦੇ ਸੰਬੰਧ ਵਿੱਚ, ਕਲੈਂਗ ਅਤੇ libc++ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਪ੍ਰਸਤਾਵ ਹੈ;
• LLVM ਟੂਲਕਿੱਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵਿਕਾਸ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ, ਜਿਵੇਂ ਕਿ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸੈਨੀਟਾਈਜ਼ਰ ਅਤੇ ਫਜ਼ ਟੈਸਟਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਨਾ।

ਸਰਗਰਮ LLVM ਡਿਵੈਲਪਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਇਸ਼ਾਰਾ ਕੀਤਾਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ LLVM ਟੂਲਕਿੱਟ ਦੇ ਹਿੱਸੇ ਵਜੋਂ libc ਨੂੰ ਭੇਜਣਾ ਸਮਝਦਾਰ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ, ਜਦੋਂ ਅਜਿਹੀ ਕੋਈ ਲੋੜ ਪੈਦਾ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਉਹ ਮਸਲ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਜੋ ਕਿ ਚੰਗੀ ਤਰ੍ਹਾਂ ਲਿਖੀ ਗਈ ਹੈ, ਵੱਖ-ਵੱਖ ਆਰਕੀਟੈਕਚਰ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਲੋੜੀਂਦੀ ਕਾਰਜਸ਼ੀਲਤਾ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਗਤੀਸ਼ੀਲ ਲਈ ਸਮਰਥਨ ਵੀ ਸ਼ਾਮਲ ਹੈ। ਲਿੰਕ ਕਰਨਾ ਮੁਸਲ ਨੂੰ LLVM ਵਿੱਚ ਜੋੜਨਾ ਅਤੇ ਇਸਨੂੰ ਮੁੱਖ ਪ੍ਰੋਜੈਕਟ ਦੇ ਨਾਲ ਸਮਕਾਲੀ ਫੋਰਕ ਦੇ ਰੂਪ ਵਿੱਚ ਵਿਕਸਤ ਕਰਨਾ ਜਾਇਜ਼ ਹੋ ਸਕਦਾ ਹੈ।

ਤੁਹਾਡੀ ਰਾਏ ਵੀ ਪ੍ਰਗਟ ਕੀਤਾ ਮੁਸਲ ਪ੍ਰੋਜੈਕਟ ਦੇ ਲੇਖਕ, ਜਿਸ ਨੇ ਬਹਿਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਕਿ ਗੂਗਲ ਦਾ ਪ੍ਰਸਤਾਵ ਅਤੇ ਐਲਐਲਵੀਐਮ ਵੰਡ ਵਿੱਚ ਲਿਬੀਸੀ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਬਹੁਤ ਮਾੜੇ ਵਿਚਾਰ ਕਿਉਂ ਹਨ:

• ਇੱਕ ਸਹੀ, ਅਨੁਕੂਲ, ਅਤੇ ਉੱਚ-ਗੁਣਵੱਤਾ ਵਾਲੇ Libc ਦਾ ਵਿਕਾਸ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਇੱਕ ਬਹੁਤ ਮੁਸ਼ਕਲ ਕੰਮ ਹੈ। ਸਮੱਸਿਆ ਕੋਡ ਦੀ ਮਾਤਰਾ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਪਰ ਸਹੀ ਵਿਵਹਾਰ ਅਤੇ ਇੰਟਰਫੇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲਾਂ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਵਿੱਚ, C/C++ ਵਿੱਚ ਲਿਖੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਵੱਡੀ ਪਰਤ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਨਾਲ ਹੀ ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ, ਜਿਸਦਾ ਰਨਟਾਈਮ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। Libc ਦੁਆਰਾ. ਸੂਖਮਤਾਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੇ ਬਿਨਾਂ ਇੱਕ ਸਿਰੇ ਦੀ ਪਹੁੰਚ ਸਿਰਫ ਇਸ ਤੱਥ ਵੱਲ ਲੈ ਜਾਂਦੀ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੇ ਮੌਜੂਦਾ ਪ੍ਰੋਗਰਾਮ Libc ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਣਗੇ, ਪਰ ਫਿਰ ਅਜਿਹਾ ਪ੍ਰੋਜੈਕਟ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਦਿਲਚਸਪੀ ਦਾ ਨਹੀਂ ਹੋਵੇਗਾ.
• ਕਾਰਪੋਰੇਟ ਵਿਕਾਸ Libc ਨੂੰ ਤਬਾਹ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਸਨੂੰ ਵਿਆਪਕ ਵਰਤੋਂ ਲਈ ਧੱਕ ਸਕਦਾ ਹੈ, ਨਤੀਜੇ ਵਜੋਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਅਨੁਕੂਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਹੈਕ ਜੋੜਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਕਾਰਪੋਰੇਟ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਦੀ ਸਰਪ੍ਰਸਤੀ ਹੇਠ ਵਿਕਾਸ, ਕਮਿਊਨਿਟੀ ਦੇ ਹਿੱਤਾਂ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਣ ਲਈ ਕੰਪਨੀ ਦੀਆਂ ਲੋੜਾਂ ਅਤੇ ਹੱਲਾਂ ਵੱਲ ਕੰਬਲ ਨੂੰ ਖਿੱਚੇਗਾ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੀ ਪਛਾਣ ਕਰਦੇ ਹੋ ਜੋ ਕਿਸੇ ਹੋਰ ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ ਇੱਕ ਬੱਗ ਕਾਰਨ ਹੈ, ਤਾਂ ਨਿਯੰਤਰਿਤ ਵਿਕਾਸ ਵਿੱਚ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਆਸਾਨ ਹੈ ਕਿ Libc ਇਸ ਬੱਗ ਨਾਲ ਅਨੁਕੂਲ ਹੈ ਬਗ ਨੂੰ ਠੀਕ ਕਰਨ ਨਾਲੋਂ। ਐਪਲ ਇਹਨਾਂ ਉਦੇਸ਼ਾਂ ਲਈ BSD libc ਫੋਰਕ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਅਤੇ Google Fuchsia ਵਿੱਚ ਮਸਲ ਫੋਰਕ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਮੁਸਲ ਡਿਵੈਲਪਰ ਦਾ ਤਜਰਬਾ ਇਹ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਮੁੱਖ ਤੌਰ 'ਤੇ ਵਕੀਲਾਂ ਦੁਆਰਾ ਲਾਇਸੈਂਸ ਸੰਬੰਧੀ ਮੁੱਦਿਆਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨ ਲਈ ਸੰਪਰਕ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਉਸ ਦੀਆਂ ਸ਼ਾਖਾਵਾਂ ਵਿੱਚ ਬੇਕਾਰ ਅਤੇ ਵਿਘਨਕਾਰੀ ਤਬਦੀਲੀਆਂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤਕਨੀਕੀ ਵੇਰਵਿਆਂ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਨ ਲਈ ਕਦੇ ਵੀ ਸੰਪਰਕ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ।
• libc ਵਿਕਾਸ ਵਿੱਚ ਇੱਕ ਮੋਨੋਕਲਚਰ ਦੀ ਅਣਹੋਂਦ ਅਤੇ ਵਿਅਕਤੀਗਤ ਨਿਯੰਤਰਣ ਦੀ ਬਜਾਏ ਸਹਿਮਤੀ ਦੁਆਰਾ ਸੰਚਾਲਿਤ ਮਾਪਦੰਡਾਂ 'ਤੇ ਫੋਕਸ, ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਖਾਸ ਲਾਗੂਕਰਨਾਂ ਨਾਲ ਬੰਨ੍ਹਣ ਦੀ ਬਜਾਏ ਮਿਆਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦਾ ਹੈ। ਇਸੇ ਲਈ ਮੁਸਲ ਦਾ ਲੇਖਕ LLVM ਵਿੱਚ ਆਪਣੀ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਦੇ ਵਿਰੁੱਧ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ LLVM ਦੇ ਅੰਦਰ libc ਦੇ ਵਿਕਾਸ ਦੇ ਵਿਰੁੱਧ ਹੈ, ਕਿਉਂਕਿ ਇਸ ਮਾਮਲੇ ਵਿੱਚ libc ਦੀ ਸੁਤੰਤਰ ਪ੍ਰਕਿਰਤੀ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਲਾਗੂਕਰਨ ਇੱਕ ਪਹਿਲੇ ਦਰਜੇ ਦਾ ਹੱਲ ਬਣ ਜਾਂਦਾ ਹੈ। LLVM, ਅਤੇ ਹੋਰ ਸਾਰੇ ਦੂਜੇ ਦਰਜੇ ਦਾ ਹੱਲ ਬਣ ਜਾਂਦੇ ਹਨ।

ਸਰੋਤ: opennet.ru