Comments

David Miller <davem@davemloft.net> wrote
> From: Dodji Seketeli <dodji@redhat.com>> Date: Wed, 14 Nov 2012 14:26:40 +0100> > > I guess we could do that. That would build libsanitizer, but asan will> > still not be available on sparc if the asan_shadow_offset() target hook> > is not provided. Is that OK to you?> > Yes.
So, here is the (IMO obvious) patch to enable libsanitizer's build on
sparc linux, even if asan is not supported on that platform yet.
OK for trunk?
libsanitizer/ChangeLog:
* configure.tgt: Enable sparc linux.
---
libsanitizer/configure.tgt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

On Thu, Nov 15, 2012 at 5:56 AM, Dodji Seketeli <dodji@redhat.com> wrote:
> David Miller <davem@davemloft.net> wrote>>> From: Dodji Seketeli <dodji@redhat.com>>> Date: Wed, 14 Nov 2012 14:26:40 +0100>>>> > I guess we could do that. That would build libsanitizer, but asan will>> > still not be available on sparc if the asan_shadow_offset() target hook>> > is not provided. Is that OK to you?>>>> Yes.>> So, here is the (IMO obvious) patch to enable libsanitizer's build on> sparc linux, even if asan is not supported on that platform yet.>> OK for trunk?>> libsanitizer/ChangeLog:>> * configure.tgt: Enable sparc linux.
If this does not break the sparc build, it's OK.
Diego.

From: Eric Botcazou <ebotcazou@adacore.com>
Date: Sun, 18 Nov 2012 00:18:15 +0100
> error: '__NR_mmap2' was not declared in this scope> return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);
The people making libsanitizer changes are really going to have to
stop making i386 specific changes to these generic files.
Specifically, in this case, they are checking for whether mmap2 is
available using __x86_64__ cpp tests. A more appropriate test is
necessary.
Oh nevermind, H.J. Liu added this build regression, I should have
known.
H.J., either fix or revert this code back to using __WORDSIZE if you
cannot come up with an appropriate test.

On Sat, Nov 17, 2012 at 4:04 PM, David Miller <davem@davemloft.net> wrote:
> From: Eric Botcazou <ebotcazou@adacore.com>> Date: Sun, 18 Nov 2012 00:18:15 +0100>>> error: '__NR_mmap2' was not declared in this scope>> return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);>> The people making libsanitizer changes are really going to have to> stop making i386 specific changes to these generic files.>> Specifically, in this case, they are checking for whether mmap2 is> available using __x86_64__ cpp tests. A more appropriate test is> necessary.>> Oh nevermind, H.J. Liu added this build regression, I should have> known.>> H.J., either fix or revert this code back to using __WORDSIZE if you> cannot come up with an appropriate test.
Please follow:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00951.html

From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Sat, 17 Nov 2012 16:06:23 -0800
> On Sat, Nov 17, 2012 at 4:04 PM, David Miller <davem@davemloft.net> wrote:>> From: Eric Botcazou <ebotcazou@adacore.com>>> Date: Sun, 18 Nov 2012 00:18:15 +0100>>>>> error: '__NR_mmap2' was not declared in this scope>>> return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);>>>> The people making libsanitizer changes are really going to have to>> stop making i386 specific changes to these generic files.>>>> Specifically, in this case, they are checking for whether mmap2 is>> available using __x86_64__ cpp tests. A more appropriate test is>> necessary.>>>> Oh nevermind, H.J. Liu added this build regression, I should have>> known.>>>> H.J., either fix or revert this code back to using __WORDSIZE if you>> cannot come up with an appropriate test.> > Please follow:> > http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00951.html
The whole way this libsanitizer merge is being handled is
beyond unreasonable.
A build fix being held up for 4 days just proves that requiring things
get merged into LLVM first is completely the wrong way for this stuff
to work.
The people who merged in this library should be responsible for
keeping changes in sync, not the individual developers who fix bugs
and make improvements to this code on the gcc side.
It's lunacy that this build problem is in the tree for 4 days because
of this.

On Sat, Nov 17, 2012 at 4:14 PM, David Miller <davem@davemloft.net> wrote:
> From: "H.J. Lu" <hjl.tools@gmail.com>> Date: Sat, 17 Nov 2012 16:06:23 -0800>>> On Sat, Nov 17, 2012 at 4:04 PM, David Miller <davem@davemloft.net> wrote:>>> From: Eric Botcazou <ebotcazou@adacore.com>>>> Date: Sun, 18 Nov 2012 00:18:15 +0100>>>>>>> error: '__NR_mmap2' was not declared in this scope>>>> return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);>>>>>> The people making libsanitizer changes are really going to have to>>> stop making i386 specific changes to these generic files.>>>>>> Specifically, in this case, they are checking for whether mmap2 is>>> available using __x86_64__ cpp tests. A more appropriate test is>>> necessary.>>>>>> Oh nevermind, H.J. Liu added this build regression, I should have>>> known.>>>>>> H.J., either fix or revert this code back to using __WORDSIZE if you>>> cannot come up with an appropriate test.>>>> Please follow:>>>> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00951.html>> The whole way this libsanitizer merge is being handled is> beyond unreasonable.>> A build fix being held up for 4 days just proves that requiring things> get merged into LLVM first is completely the wrong way for this stuff> to work.
I am open to suggestions on how to avoid forking the two versions.
If we fork, the original asan team will not be able to cope with two
repositories.
--kcc
>> The people who merged in this library should be responsible for> keeping changes in sync, not the individual developers who fix bugs> and make improvements to this code on the gcc side.>> It's lunacy that this build problem is in the tree for 4 days because> of this.

From: Konstantin Serebryany <konstantin.s.serebryany@gmail.com>
Date: Sat, 17 Nov 2012 19:01:56 -0800
> I am open to suggestions on how to avoid forking the two versions.> If we fork, the original asan team will not be able to cope with two> repositories.
The maintainer of the sanitizer's job is to do the merging and resolve
the conflicts between the two trees. This is how every other similar
situation is handled.
What's happening here, frankly, is garbage.
The current situation is unacceptable and HJ's fix should go into the
GCC tree right now.
The current situation is preventing people from getting work done, and
unnecessarily consuming developer resources.

On Sat, Nov 17, 2012 at 7:10 PM, David Miller <davem@davemloft.net> wrote:
> From: Konstantin Serebryany <konstantin.s.serebryany@gmail.com>> Date: Sat, 17 Nov 2012 19:01:56 -0800>>> I am open to suggestions on how to avoid forking the two versions.>> If we fork, the original asan team will not be able to cope with two>> repositories.>> The maintainer of the sanitizer's job is to do the merging and resolve> the conflicts between the two trees. This is how every other similar> situation is handled.
I am new to the gcc community and may not know all the rules.
But your nice words (lunacy, garbage, etc) are not helping us.
As for the particular problem, I did not even see a patch (did I miss
it? Sorry, I am just back from a long trip)
I'd prefer to mention the ARCHs explicitly where possible, i.e.
#if defined(__x86_64__) || definde (__sparc64__)
instead of
#if __WORDSIZE == 64 || ...
--kcc
>> What's happening here, frankly, is garbage.>> The current situation is unacceptable and HJ's fix should go into the> GCC tree right now.>> The current situation is preventing people from getting work done, and> unnecessarily consuming developer resources.

On Sat, Nov 17, 2012 at 10:10 PM, David Miller <davem@davemloft.net> wrote:
> From: Konstantin Serebryany <konstantin.s.serebryany@gmail.com>> Date: Sat, 17 Nov 2012 19:01:56 -0800>>> I am open to suggestions on how to avoid forking the two versions.>> If we fork, the original asan team will not be able to cope with two>> repositories.>> The maintainer of the sanitizer's job is to do the merging and resolve> the conflicts between the two trees. This is how every other similar> situation is handled.>> What's happening here, frankly, is garbage.
Calm down, David. I understand this is frustrating, but reacting in
this manner is not helpful to anyone. We have some new maintainers
that are trying to understand how the system works. Insulting and
berating them will only encourage them to pack up and leave.
There is no need to do any forking.
Kostya, would it be acceptable if fixes that go in the gcc tree get
then propagated to the LLVM tree? The two trees don't need to be kept
in sync at every commit. Patches to the GCC tree will be in your
inbox or submitted to gcc-patches.
Diego.

From: Konstantin Serebryany <konstantin.s.serebryany@gmail.com>
Date: Sat, 17 Nov 2012 19:17:17 -0800
> I'd prefer to mention the ARCHs explicitly where possible, i.e.> #if defined(__x86_64__) || definde (__sparc64__)> instead of> #if __WORDSIZE == 64 || ...
You really do need to check __x86_64__ as well the word size, in order
to distinguish x32 from traditional x86-64.
So no, it is not possible to just use an ARCH check all by itself
to handle this case.
Therefore, HJ's check is the correct check, and mirrors similar
existing checks elsewhere in the tree (f.e. libffi).

From: Diego Novillo <dnovillo@google.com>
Date: Sat, 17 Nov 2012 22:26:24 -0500
> We have some new maintainers that are trying to understand how the> system works.
Wouldn't we have someone become at least roughly familiar with these
kinds of things before we allow them to commit such an invasive set of
changes which have a non-trivial effect on pretty much everyone?
You cannot get around the fact that this was all handled poorly.

On Sat, Nov 17, 2012 at 7:26 PM, Diego Novillo <dnovillo@google.com> wrote:
> On Sat, Nov 17, 2012 at 10:10 PM, David Miller <davem@davemloft.net> wrote:>> From: Konstantin Serebryany <konstantin.s.serebryany@gmail.com>>> Date: Sat, 17 Nov 2012 19:01:56 -0800>>>>> I am open to suggestions on how to avoid forking the two versions.>>> If we fork, the original asan team will not be able to cope with two>>> repositories.>>>> The maintainer of the sanitizer's job is to do the merging and resolve>> the conflicts between the two trees. This is how every other similar>> situation is handled.>>>> What's happening here, frankly, is garbage.>> Calm down, David. I understand this is frustrating, but reacting in> this manner is not helpful to anyone. We have some new maintainers> that are trying to understand how the system works. Insulting and> berating them will only encourage them to pack up and leave.>> There is no need to do any forking.>> Kostya, would it be acceptable if fixes that go in the gcc tree get> then propagated to the LLVM tree?
It may be acceptable for trivial patches, but we still want to review them.
Once we review patch, it is easier for us to put it into LLVM first
and then to gcc.
Which reminds me, that libsanitizer/README.gcc is not helping in this
process yet...
> The two trees don't need to be kept> in sync at every commit. Patches to the GCC tree will be in your> inbox or submitted to gcc-patches.>>> Diego.

On Sat, Nov 17, 2012 at 7:17 PM, Konstantin Serebryany
<konstantin.s.serebryany@gmail.com> wrote:
> On Sat, Nov 17, 2012 at 7:10 PM, David Miller <davem@davemloft.net> wrote:>> From: Konstantin Serebryany <konstantin.s.serebryany@gmail.com>>> Date: Sat, 17 Nov 2012 19:01:56 -0800>>>>> I am open to suggestions on how to avoid forking the two versions.>>> If we fork, the original asan team will not be able to cope with two>>> repositories.>>>> The maintainer of the sanitizer's job is to do the merging and resolve>> the conflicts between the two trees. This is how every other similar>> situation is handled.>> I am new to the gcc community and may not know all the rules.> But your nice words (lunacy, garbage, etc) are not helping us.>> As for the particular problem, I did not even see a patch (did I miss> it? Sorry, I am just back from a long trip)> I'd prefer to mention the ARCHs explicitly where possible, i.e.> #if defined(__x86_64__) || definde (__sparc64__)> instead of> #if __WORDSIZE == 64 || ...
How about splitting this into a different config directory right now.
Maybe I will do this later today. This is what was needed when it was
merged into GCC rather than all of these #ifdef all over the code.
Look at how either libgomp or even glibc handles cases like this.
They have include directories which is based on the target and maybe
even a common directory which each target can over ride it (glibc is
the best at doing this).
The whole double review process is hard for the target maintainers of
GCC to work really. Target maintainers in GCC is not normally like an
extra review step as it does slow down the whole process of getting a
target patch reviewed.
Thanks,
Andrew Pinski
>> --kcc>>>>> What's happening here, frankly, is garbage.>>>> The current situation is unacceptable and HJ's fix should go into the>> GCC tree right now.>>>> The current situation is preventing people from getting work done, and>> unnecessarily consuming developer resources.

From: Andrew Pinski <pinskia@gmail.com>
Date: Sat, 17 Nov 2012 19:34:34 -0800
> (glibc is the best at doing this).
It also uses "make" in pretty much the most inefficient way possible,
by causing it to consider 10s of thousands of prefix rules for every
rule target.
GLIBC has the same ifdef check that is being suggested here in various
places.