gdb: allow building on AArch64 systems
PATCH v2 1/1 gdb: allow building on AArch64 systems
gdb has had AArch64 support since 7.6 which is now the default minimum version of GDB in the tree. Older versions are now legacy.
---
v2:
- reword commit.
--- package/gdb/Config.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
package/gdb/Config.in +2 -2
@@ -1,5 +1,5 @@ comment "gdb/gdbserver needs a toolchain w/ threads, threads debug" - depends on !BR2_aarch64 && !BR2_nios2 + depends on !BR2_nios2 depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_TOOLCHAIN_HAS_THREADS_DEBUG config BR2_PACKAGE_GDB
@@ -10,7 +10,7 @@ config BR2_PACKAGE_GDB select BR2_PACKAGE_GDB_SERVER if \ (!BR2_PACKAGE_GDB_DEBUGGER && !BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY) depends on BR2_TOOLCHAIN_HAS_THREADS && BR2_TOOLCHAIN_HAS_THREADS_DEBUG - depends on !BR2_aarch64 && !BR2_nios2 + depends on !BR2_nios2 help GDB, the GNU Project debugger, allows you to see what is going on `inside' another program while it executes -- or
Signature · 1 line
2.0.4
Thomas Petazzoni
AppliedPATCH v2 1/1 gdb: allow building on AArch64 systems
Dear Alex Benn?e,
Quoted 4 lines · Alex Benn?e
gdb has had AArch64 support since 7.6 which is now the default minimum version of GDB in the tree. Older versions are now legacy.
Signed-off-by Alex Benn?e <[email protected]>
Applied, thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v2 1/1 gdb: allow building on AArch64 systems
Quoted 9 lines · Thomas Petazzoni
Dear Alex Benn?e,
Quoted 4 lines · Alex Benn?e
gdb has had AArch64 support since 7.6 which is now the default minimum version of GDB in the tree. Older versions are now legacy.
Signed-off-by Alex Benn?e <[email protected]>Applied, thanks!
How are you applying the patches? I'm curious because while my local patch shows up in the log with:
commit 0b729ce2baa9903e7d3520196f9fff16cdff24fa
Author: Alex Benn?e <[email protected]>
The one in upstream is:
commit 4372449a4f8e16f763c7d5a0c125ca015a7cbef6
Author: alex.bennee at linaro.org <[email protected]>
I'd usually assume utf-8 shenanigans tripping something up but I see the repo does have names with more accents than mine ;-)
Quoted 2 lines
Thomas
Signature · 1 line
Alex Benn?e
PATCH v2 1/1 gdb: allow building on AArch64 systems
Dear Alex Benn?e,
Quoted 14 lines · Alex Benn?e
Quoted 7 lines · Alex Benn?e
Quoted 4 lines
gdb has had AArch64 support since 7.6 which is now the default minimum version of GDB in the tree. Older versions are now legacy.
Signed-off-by Alex Benn?e <[email protected]>Applied, thanks!
How are you applying the patches? I'm curious because while my local patch shows up in the log with:
commit
0b729ce2baa9903e7d3520196f9fff16cdff24fa
Author: Alex Benn?e <[email protected]>
Quoted 7 lines
The one in upstream is:
commit
4372449a4f8e16f763c7d5a0c125ca015a7cbef6
Author: alex.bennee at linaro.org <[email protected]>I'd usually assume utf-8 shenanigans tripping something up but I see the repo does have names with more accents than mine ;-)
We're using pwclient, which downloads the patch from patchwork and applies it with "git am".
There's basically no chance for your local commit used to generate the patch to have the same SHA1 as the commit integrated in the official repository. Your commit applies on commit A, but it ends up applied on top of commit B. And since the SHA1 of the parent commit is part of what defines the next commit and therefore it's SHA1, there's no chance for your commit to have the same SHA1 in the official repo as in your local repo with the workflow we have.
SHA1 would be preserved if we were taking pull requests and merging those pull requests without rebasing them. But basically, by using "git am", we're rebasing all patches on top of the latest master when applying them, which changes their SHA1.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v2 1/1 gdb: allow building on AArch64 systems
Hi Thomas,
Quoted 35 lines · Thomas Petazzoni
Quoted 14 lines · Alex Benn?e
Quoted 7 lines · Alex Benn?e
Quoted 4 lines
gdb has had AArch64 support since 7.6 which is now the default minimum version of GDB in the tree. Older versions are now legacy.
Signed-off-by Alex Benn?e <[email protected]>Applied, thanks!
How are you applying the patches? I'm curious because while my local patch shows up in the log with:
commit
0b729ce2baa9903e7d3520196f9fff16cdff24fa
Author: Alex Benn?e <[email protected]>Quoted 7 lines
The one in upstream is:
commit
4372449a4f8e16f763c7d5a0c125ca015a7cbef6
Author: alex.bennee at linaro.org <[email protected]>I'd usually assume utf-8 shenanigans tripping something up but I see the repo does have names with more accents than mine ;-)
We're using pwclient, which downloads the patch from patchwork and applies it with "git am".
There's basically no chance for your local commit used to generate the patch to have the same SHA1 as the commit integrated in the official repository. Your commit applies on commit A, but it ends up applied on top of commit B. And since the SHA1 of the parent commit is part of what defines the next commit and therefore it's SHA1, there's no chance for your commit to have the same SHA1 in the official repo as in your local repo with the workflow we have.
Quoted 4 lines
SHA1 would be preserved if we were taking pull requests and merging those pull requests without rebasing them. But basically, by using "git am", we're rebasing all patches on top of the latest master when applying them, which changes their SHA1.
Alex was asking about author name, not commit ID. Compare:
Author: Alex Benn?e <[email protected]>
Author: alex.bennee at linaro.org <[email protected]>
I should note that the sign-off line preserves the name correctly.
baruch
Signature · 3 lines
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -PATCH v2 1/1 gdb: allow building on AArch64 systems
Dear Baruch Siach,
Quoted 16 lines · Baruch Siach
Quoted 11 lines
We're using pwclient, which downloads the patch from patchwork and applies it with "git am".
There's basically no chance for your local commit used to generate the patch to have the same SHA1 as the commit integrated in the official repository. Your commit applies on commit A, but it ends up applied on top of commit B. And since the SHA1 of the parent commit is part of what defines the next commit and therefore it's SHA1, there's no chance for your commit to have the same SHA1 in the official repo as in your local repo with the workflow we have.
Quoted 4 lines
SHA1 would be preserved if we were taking pull requests and merging those pull requests without rebasing them. But basically, by using "git am", we're rebasing all patches on top of the latest master when applying them, which changes their SHA1.
Quoted 7 lines
Alex was asking about author name, not commit ID. Compare:
Author: Alex Benn?e <[email protected]>
Author: alex.bennee at linaro.org <[email protected]>
I should note that the sign-off line preserves the name correctly.
Ah yes. Then, seems possibly like a patchwork issue, since from patchwork point of view, the author is alex.bennee at linaro.org. See
http://patchwork.ozlabs.org/patch/376942/. However, it does seem to handle non-ASCII characters in author names if you look at
http://patchwork.ozlabs.org/patch/377013/.
http://patchwork.ozlabs.org/patch/371846/ is another example.
If you look at
http://patchwork.ozlabs.org/project/buildroot/list/?state=*, you'll see that Alex's patch is the only case in recent times where the e-mail was used instead of the author name.
Not sure what happened.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH v2 1/1 gdb: allow building on AArch64 systems
In reply to Thomas PetazzoniQuoted 26 lines · Thomas Petazzoni
Dear Alex Benn?e,
Quoted 14 lines · Alex Benn?e
Quoted 7 lines · Alex Benn?e
Quoted 4 lines
gdb has had AArch64 support since 7.6 which is now the default minimum version of GDB in the tree. Older versions are now legacy.
Signed-off-by Alex Benn?e <[email protected]>Applied, thanks!
How are you applying the patches? I'm curious because while my local patch shows up in the log with:
commit
0b729ce2baa9903e7d3520196f9fff16cdff24fa
Author: Alex Benn?e <[email protected]>Quoted 7 lines
The one in upstream is:
commit
4372449a4f8e16f763c7d5a0c125ca015a7cbef6
Author: alex.bennee at linaro.org <[email protected]>I'd usually assume utf-8 shenanigans tripping something up but I see the repo does have names with more accents than mine ;-)
Quoted 6 lines
We're using pwclient, which downloads the patch from patchwork and applies it with "git am".
There's basically no chance for your local commit used to generate the patch to have the same SHA1 as the commit integrated in the official repository.
Sorry I was actually talking about the mangled Author field. The SHAs were just for reference. It looks like it gets mangled as it goes into patchwork. Compare:
From: =?UTF-8?q?Alex=20Benn=C3=A9e?= <[email protected]>
To: buildroot at busybox.net
Cc: =?UTF-8?q?Alex=20Benn=C3=A9e?= <[email protected]>
Subject: [PATCH V2] gdb: allow building on AArch64 systems
Date: Wed, 6 Aug 2014 09:42:14 +0100
Message-Id: <[email protected]>
to
Subject: [V2] gdb: allow building on AArch64 systems
From: [email protected]
X-Patchwork-Id: 376942
Message-Id: <[email protected]>
To: buildroot at busybox.net
Date: Wed, 6 Aug 2014 09:42:14 +0100
Signature · 1 line
Alex Benn?e