We are currently assuming that regcache->ptid is equal to inferior_ptid
when we call target_fetch/store_registers. These asserts just validate
that assumption. Also, since the following patches will change target
code to use regcache->ptid instead of inferior_ptid, asserting that they
are the same should ensure that our changes don't have any unintended
consequences.
gdb/ChangeLog:
* target.c (target_fetch_registers, target_store_registers): Add
assert.
This patch introduces the regcache_get_ptid function, which can be used
to retrieve the ptid a regcache is connected to. It is used in
subsequent patches.
gdb/ChangeLog:
* regcache.h (regcache_get_ptid): New function.
* regcache.c (regcache_get_ptid): New function.
I noticed that backslash_in_multi_line_command_test in
gdb.base/commands.exp failed on our RHEL6 servers. I traced it to the
old version of DejaGnu (1.4.4). I have found that instead of receiving
the expected:
"print \\\nargc\n"
gdb received:
"print argc\n"
thus breaking the test and its purpose. Versionof DejaGnu < 1.5 mess
up sending "\\\n", it somehow gets replaced with a space. I found that
the following commit in DejaGnu fixed the issue:
http://git.savannah.gnu.org/cgit/dejagnu.git/commit/lib/remote.exp?id=3f39294f5cd6802858838d3bcc0ccce847ae17f2
Even though the commit is almost 10 years old, the following release of
DejaGnu was only in 2013, which is why we still have systems with the
old code.
If the DejaGnu version is < 1.5, we just skip the test.
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp (backslash_in_multi_line_command_test):
Skip for versions of DejaGnu < 1.5.
The next patch will require checking the DejaGnu version. There is
already a test that does this,
gdb.threads/attach-many-short-lived-threads.exp. This patch introduces
a new procedure, dejagnu_version, and makes that test use it.
The version number is "right-padded" with zeroes, to make sure that we
always return a triplet (major, minor, patch).
The procedure does not consider the DejaGnu versions from git. For
example, if you used DejaGnu from its current master branch, the version
would be "1.6.1-git", meaning that 1.6.1 will be the next release. I
figured we'll cross that bridge when (and if) we get there.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (dejagnu_version): New proc.
* gdb.threads/attach-many-short-lived-threads.exp (bad_dejagnu):
Use dejagnu_version.
While integrating the d_printing recursion guard change into gdb I
noticed we forgot to initialize the demangle_component d_printing
field in cplus_demangle_fill_{name,extended_operator,ctor,dtor}.
As is done in cplus_demangle_fill_{component,builtin_type,operator}.
It happened to work because in gcc all demangle_components were
allocated through d_make_empty. But gdb has its own allocation
mechanism (as might other users).
libiberty/ChangeLog:
* cp-demangle.c (cplus_demangle_fill_name): Initialize
demangle_component d_printing.
(cplus_demangle_fill_extended_operator): Likewise.
(cplus_demangle_fill_ctor): Likewise.
(cplus_demangle_fill_dtor): Likewise.
gdb/ChangeLog:
* cp-name-parser.y (make_empty): Initialize d_printing to zero.
If the source file is more recent than the object file, line number
information in the object may no longer match the source. So print a
warning message.
* objdump.c (update_source_path): Add abfd param. Add struct
stat vars. Pass to try_print_file_open. Warn if source is more
recent than object.
(try_print_file_open, slurp_file): Add struct stat param to
return fstat.
(show_line): Call update_source_path with bfd.
ld/
* ldlang.c (lang_check_section_addresses): Check for address space
overflow.
* testsuite/ld-checks/checks.exp (overflow_check): New procedure
* testsuite/ld-checks/over.s: New test source.
* testsuite/ld-checks/over.d: New test.
* testsuite/ld-checks/over2.s: New test source.
* testsuite/ld-checks/over2.d: New test.
First, need to match against just the CPU name, not the whole triplet.
Otherwise, the test picks up "*le-*" pattern from x86_64-apple-darwin
triplet.
Second, it should be testing for $target, not $host. Host may be
little endian by default, and the sysroot directory layout shouldn't
depend on whether it is built on LE or BE machine.
* emulparams/elf32ppccommon.sh (LIBPATH_SUFFIX): Set from target
cpu, not host.
Relative paths shouldn't have the sysroot prefix added. The patch
also makes some attempt at supporting DOS paths, and tidies code using
the new add_sysroot.
* emultempl/elf32.em (gld${EMULATION_NAME}_add_sysroot): Rewrite.
Only prefix absolute paths with sysroot. Handle DOS paths.
(gld${EMULATION_NAME}_check_ld_elf_hints): Constify variable.
(gld${EMULATION_NAME}_check_ld_so_conf): Likewise.
(gld${EMULATION_NAME}_after_open): Short-circuit NULL path
searches. Rename variable. Simplify get_runpath search.
This gcc option isn't well supported, so use the actual linker option
we want to test.
* testsuite/ld-elf/shared.exp: Use -Wl,-export-dynamic rather
than -rdynamic.
These targets use the generic ELF support, so don't handle orphans
well. The patch also updates the orphan doco to reflect this fact,
and deletes some ELF details that don't really add anything.
* ld.texinfo (Orphan Sections): Mention that not all targets
handle orphans well. Delete ELF details.
* testsuite/ld-elf/orphan-9.d: Don't run for i860 and i960.
* testsuite/ld-elf/orphan-10.d: Likewise.
For a long time now, c++/8218 has noted that GDB is printing argument types
for destructors:
(gdb) ptype A
type = class A {
public:
~A(int);
}
This happens because cp_type_print_method_args doesn't ignore artificial
arguments. [It ignores the first `this' pointer because it simply skips
the first argument for any non-static function.]
This patch fixes this:
(gdb) ptype A
type = class A {
public:
~A();
}
I've adjusted gdb.cp/templates.exp to account for this and added a new
passing regexp.
gdb/ChangeLog
PR c++/8218
* c-typeprint.c (cp_type_print_method_args): Skip artificial arguments.
gdb/testsuite/ChangeLog
PR c++/8128
* gdb.cp/templates.exp (test_ptype_of_templates): Remove argument
type from destructor regexps.
Add a branch which actually passes the test.
Adjust "ptype t5i" test names.
Given a linker script fragment like this:
SECTIONS {
. = 0x1000;
.text : AT(0x100) { *(.text) }
.data : AT(0x200) { *(.data) }
.rodata : AT(0x300) { *(.rodata) }
}
and an input file containing sections, '.text', '.data.1', and
'.rodata', then we'd expect the linker to place '.text' and '.rodata' in
the obvious way, and the '.data.1' orphan section would be located after
the '.data' section (assuming similar section properties).
Further, I believe that the expectation would be that the LMA for the
orphan '.data.1' section would start from 0x200 (as there is no '.data'
content).
However, right now, the LMA for '.data.1' would be 0x101, following on
from the '.text' section, this is because the change in LMA for the
'.data' section is not noticed by the linker, if there's no content in
the '.data' section.
What can be even more confusing to a user (though the cause is obvious
once you understand what's going on) is that adding some content to
'.data' will cause the orphan '.data.1' to switch to an LMA based off of
0x200.
This commit changes the behaviour so that an empty section that is in
the default lma region, and sets its lma, will adjust the lma of the
default region, this change will then be reflected in following sections
within the default lma memory region.
There's a new test to cover this issue that passes on a range of
targets, however, some targets generate additional sections, or have
stricter memory region size requirements that make it harder to come
up with a generic pass pattern, that still tests the required
features. For now I've set the test to ignore these targets.
ld/ChangeLog:
* ldlang.c (lang_size_sections_1): Shortcut loop only after
tracking changes to the default regions LMA.
* testsuite/ld-elf/orphan-9.ld: Extend header comment.
* testsuite/ld-elf/orphan-10.d: New file.
* testsuite/ld-elf/orphan-10.s: New file.
* NEWS: Mention change in behaviour.
When picking an lma_region for an orphan section we currently create a
new lang_output_section_statement_type and then populate this with the
orphan section.
The problem is that the lang_output_section_statement_type has a prev
pointer that links back to the previous output section. For non-orphan
output sections, that are created in linker script order, the prev
pointer will point to the output section that appears previous in linker
script order, as you'd probably expect.
The problem is that orphan sections are placed after processing the
linker script, and so, in the case of an output section created for an
orphan input section, the prev pointer actually points to the last
output section created.
This causes some unexpected behaviour when the orphan section is not
placed after the last non-orphan section that was created.
For example, consider this linker script:
MEMORY {
TEXT : ORIGIN = 0x200, LENGTH = 0x10
RODATA : ORIGIN = 0x400, LENGTH = 0x10
}
SECTIONS {
.text : {*(.text) } AT>TEXT
.data : AT(0x300) { *(.data) }
.rodata : { *(.rodata) } AT>RODATA
}
If we are processing an orphan section '.data.1' and decide to place
this after '.data', then the output section created will have a prev
pointer that references the '.rodata' output section. The result of
this is that '.data.1' will actually be assigned to the RODATA lma
region, which is probably not the expected behaviour.
The reason why '.data.1' is placed into the lma region of the '.rodata'
section is that lma region propagation is done at the time we create the
output section, based on the previous output section pointer, which is
really just a last-output-section-created pointer at that point in time,
though the prev point is fixed up later to reflect the true order of the
output sections.
The solution I propose in this commit is to move the propagation of lma
regions into a separate pass of the linker, rather than performing this
as part of the enter/exit of output sections during linker script
parsing.
During this later phase we have all of the output sections to hand, and
the prev/next points have been fixed up by this point to reflect the
actual placement ordering.
There's a new test to cover this issue that passes on a range of
targets, however, some targets generate additional sections, or have
stricter memory region size requirements that make it harder to come
up with a generic pass pattern, that still tests the required
features. For now I've set the test to ignore these targets.
ld/ChangeLog:
* ldlang.c (lang_leave_output_section_statement): Move lma_region
logic to...
(lang_propagate_lma_regions): ...this new function.
(lang_process): Call new function.
* testsuite/ld-elf/orphan-9.d: New file.
* testsuite/ld-elf/orphan-9.ld: New file.
* testsuite/ld-elf/orphan-9.s: New file.
* NEWS: Mention change in behaviour.
Make more explicit mention of the fact that orphan sections can cause a
new output section to be created. Though this information is clearly
implied in the manual it might not be clear enough.
A user _might_ (incorrectly) think that orphan sections can only be
inserted into an existing output section.
ld/ChangeLog:
* ld.texinfo (Orphan Sections): Add more detail.
Many x86 instructions have more than one encodings. Assembler picks
the default one, usually the shortest one. Although the ".s", ".d8"
and ".d32" suffixes can be used to swap register operands or specify
displacement size, they aren't very flexible. This patch adds pseudo
prefixes, {xxx}, to control instruction encoding. The available
pseudo prefixes are {disp8}, {disp32}, {load}, {store}, {vex2}, {vex3}
and {evex}. Pseudo prefixes are preferred over the ".s", ".d8" and
".d32" suffixes, which are deprecated.
gas/
* config/tc-i386.c (_i386_insn): Add dir_encoding and
vec_encoding. Remove swap_operand and need_vrex.
(extra_symbol_chars): Add '}'.
(md_begin): Mark '}' with LEX_BEGIN_NAME. Allow '}' in
mnemonic.
(build_vex_prefix): Don't use 2-byte VEX encoding with
{vex3}. Check dir_encoding and load.
(parse_insn): Check pseudo prefixes. Set dir_encoding.
(VEX_check_operands): Likewise.
(match_template): Check dir_encoding and load.
(parse_real_register): Set vec_encoding instead of need_vrex.
(parse_register): Likewise.
* doc/c-i386.texi: Document {disp8}, {disp32}, {load}, {store},
{vex2}, {vex3} and {evex}. Remove ".s", ".d8" and ".d32"
* testsuite/gas/i386/i386.exp: Run pseudos and x86-64-pseudos.
* testsuite/gas/i386/pseudos.d: New file.
* testsuite/gas/i386/pseudos.s: Likewise.
* testsuite/gas/i386/x86-64-pseudos.d: Likewise.
* testsuite/gas/i386/x86-64-pseudos.s: Likewise.
opcodes/
* i386-gen.c (opcode_modifiers): Replace S with Load.
* i386-opc.h (S): Removed.
(Load): New.
(i386_opcode_modifier): Replace s with load.
* i386-opc.tbl: Add {disp8}, {disp32}, {swap}, {vex2}, {vex3}
and {evex}. Replace S with Load.
* i386-tbl.h: Regenerated.
Currently, the -maltivec and -mvsx GAS options enable *all* of the altivec
and vsx instructions respecitively that have ever been added. This is in
constract to GCC's -maltivec and -mvsx options, which only enable the oldest
(ie, first) set of altivec and vsx instructions. This patch changes GAS to
mimic GCC's behaviour with respect to -maltivec and -mvsx and it solves a
problem with trying to assemble the lxvx instruction which is different
between POWER8 and POWER9.
opcodes/
* ppc-dis.c (ppc_opts) <altivec>: Do not use PPC_OPCODE_ALTIVEC2;
<vsx>: Do not use PPC_OPCODE_VSX3;
gas/
* testsuite/gas/ppc/altivec2.d (as): Use the -mpower8 option.
(objdump): Use the -Mpower8 option.
Currently diffing testrun results shows:
-PASS: gdb.base/step-over-exit.exp: break *0x7ffff77e18c6 if main == 0
+PASS: gdb.base/step-over-exit.exp: break *0x2aaaab0988c6 if main == 0
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.base/step-over-exit.exp: Add explicit test message.
If you do "interrupt -a" just while some thread is stepping over a
breakpoint, gdb trips on an internal error.
The test added by this patch manages to trigger this consistently by
spawning a few threads that are constantly tripping on a conditional
breakpoint whose condition always evaluates to false. With current
gdb, you get:
~~~
interrupt -a
.../src/gdb/inline-frame.c:343: internal-error: void skip_inline_frames(ptid_t): Assertion `find_inline_frame_state (ptid) == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/interrupt-while-step-over.exp: displaced-stepping=on: iter=0: interrupt -a (GDB internal error)
[...]
.../src/gdb/inline-frame.c:343: internal-error: void skip_inline_frames(ptid_t): Assertion `find_inline_frame_state (ptid) == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/interrupt-while-step-over.exp: displaced-stepping=off: iter=0: wait for stops (GDB internal error)
~~~
The assertion triggers because we're processing a stop for a thread
that had already stopped before and thus had already its inline-frame
state filled in.
Calling handle_inferior_event_1 directly within a
"thread_stop_requested" observer is something that I've wanted to get
rid of before, for being fragile. Nowadays, infrun is aware of
threads with pending events, so we can use that instead, and let the
normal fetch_inferior_event -> handle_inferior_event code path handle
the forced stop.
The change to finish_step_over is necessary because sometimes a thread
that was told to PTRACE_SINGLESTEP reports back a SIGSTOP instead of a
SIGTRAP (i.e., we tell it to single-step, and then interrupt it quick
enough that on the kernel side the thread dequeues the SIGTOP before
ever having had a chance of executing the instruction to be stepped).
SIGSTOP gets translated to a GDB_SIGNAL_0. And then finish_step_over
would miss calling clear_step_over_info, and thus miss restarting the
other threads (which in this case of threads with pending events,
means setting their "resumed" flag, so their pending events can be
consumed).
And now that we always restart threads in finish_step_over, we no
longer need to do that in handle_signal_stop.
Tested on x86_64 Fedora 23, native and gdbserver.
gdb/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR gdb/18360
* infrun.c (start_step_over, do_target_resume, resume)
(restart_threads): Assert we're not resuming a thread that is
meant to be stopped.
(infrun_thread_stop_requested_callback): Delete.
(infrun_thread_stop_requested): If the thread is internally
stopped, queue a pending stop event and clear the thread's
inline-frame state.
(handle_stop_requested): New function.
(handle_syscall_event, handle_inferior_event_1): Use
handle_stop_requested.
(handle_stop_requested): New function.
(handle_signal_stop): Set the thread's stop_signal here instead of
at caller.
(finish_step_over): Clear step over info unconditionally.
(handle_signal_stop): If the user had interrupted the event
thread, consider the stop a random signal.
(handle_signal_stop) <signal arrived while stepping over
breakpoint>: Don't restart threads here.
(stop_waiting): Don't clear step-over info here.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR gdb/18360
* gdb.threads/interrupt-while-step-over.c: New file.
* gdb.threads/interrupt-while-step-over.exp: New file.
Should fix the build failure with Clang mentioned at
<https://sourceware.org/bugzilla/show_bug.cgi?id=21206#c2>:
In file included from ../../binutils-gdb/gdb/dwarf2read.c:72:
../../binutils-gdb/gdb/common/gdb_unlinker.h:35:35: error: '__nonnull__' attribute is invalid for the implicit this argument
unlinker (const char *filename) ATTRIBUTE_NONNULL (1)
^ ~
../../binutils-gdb/gdb/../include/ansidecl.h:169:48: note: expanded from macro 'ATTRIBUTE_NONNULL'
# define ATTRIBUTE_NONNULL(m) __attribute__ ((__nonnull__ (m)))
gdb/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR 21206
* common/gdb_unlinker.h (unlinker::unlinker): Attribute nonnull
goes to argument 2, not 1.
Property type and datasz are always 4 bytes for both 32-bit and 64-bit
objects. Property values for GNU_PROPERTY_X86_ISA_1_USED and
GNU_PROPERTY_X86_ISA_1_NEEDED are 4 bytes for both i386 and x86-64
objects. We should also check GNU_PROPERTY_LOPROC and
GNU_PROPERTY_LOUSER.
binutils/
PR binutils/21231
* readelf.c (decode_x86_isa): Change argument to unsigned int.
(print_gnu_property_note): Retrieve property type and datasz as
4-byte integer. Consolidate property datasz check. Check
GNU_PROPERTY_LOPROC and GNU_PROPERTY_LOUSER.
* testsuite/binutils-all/i386/pr21231a.d: New file.
* testsuite/binutils-all/i386/pr21231a.s: Likewise.
* testsuite/binutils-all/i386/pr21231b.d: Likewise.
* testsuite/binutils-all/i386/pr21231b.s: Likewise.
* testsuite/binutils-all/x86-64/pr21231a.d: Likewise.
* testsuite/binutils-all/x86-64/pr21231a.s: Likewise.
* testsuite/binutils-all/x86-64/pr21231b.d: Likewise.
* testsuite/binutils-all/x86-64/pr21231b.s: Likewise.
include/
PR binutils/21231
* elf/common.h (GNU_PROPERTY_LOPROC): New.
(GNU_PROPERTY_HIPROC): Likewise.
(GNU_PROPERTY_LOUSER): Likewise.
(GNU_PROPERTY_HIUSER): Likewise.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.arch/amd64-entry-value-param-dwarf5.exp: Use with_test_prefix.
* gdb.arch/amd64-entry-value-param.exp: Use with_test_prefix.
Currently I get:
(gdb) print have_pkru()
$1 = 0
(gdb) FAIL: gdb.arch/i386-pkru.exp: probe PKRU support
UNSUPPORTED: gdb.arch/i386-pkru.exp: processor does not support protection key feature.
Probing suceeded, so that should be a PASS -> UNSUPPORTED.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.arch/i386-pkru.exp (probe PKRU support): Handle detecting
PKRU as not supported as a PASS.
Avoid putting unstable path names in test messages, in order to avoid
spurious testrun result diffs like:
[....]
-PASS: gdb.base/break-fun-addr.exp: /home/pedro/gdb/test-build1/gdb/testsuite/outputs/gdb.base/break-fun-addr/break-fun-addr1: break *main
+PASS: gdb.base/break-fun-addr.exp: /home/pedro/gdb/test-build2/gdb/testsuite/outputs/gdb.base/break-fun-addr/break-fun-addr1: break *main
[....]
gdb/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
* gdb.base/break-fun-addr.exp: Use $testfile1/$testfile2 for test
prefix instead of $binfile1/$binfile2.
* gdb.btrace/gcore.exp: Use "core" instead of unstable path name
in test message.
* gdb.python/py-completion.exp: Use "load python file" as test
messages instead of unstable path names.
With commit 3b12939dfc ("Replace the sync_execution global with a
new enum prompt_state tristate"), GDB started aborting if you try
splitting an input line with a continuation char (backslash) while in
a multi-line command:
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>print \
(gdb) 1 # note "(gdb)" incorrectly printed here.
>end
readline: readline_callback_read_char() called with no handler!
$
That abort is actually a symptom of an old problem introduced when
gdb_readline_wrapper was rewritten to use asynchronous readline, back
in 2007. Note how the "(gdb)" prompt is printed above in the "(gdb)
1" line. Clearly it shouldn't be there, but it already was before the
commit mentioned above. Fixing that also fixes the readline abort
shown above.
The problem starts when command_line_input passes a NULL prompt to
gdb_readline_wrapper when it finds previous incomplete input due to a
backslash, trying to fetch more input without printing another ">"
secondary prompt. That itself should not be a problem, because
passing NULL to gdb_readline_wrapper has the same meaning as passing a
pointer to empty string, since gdb_readline_wrapper exposes the same
interface as 'readline(char *)'. However, gdb_readline_wrapper passes
the prompt argument directly to display_gdb_prompt, and for the
latter, a NULL prompt argument has a different meaning - it requests
printing the primary prompt.
Before commit 782a7b8ef9c096 (which rewrote gdb_readline_wrapper to
use asynchronous readline), GDB behaved like this:
(gdb) commands
[....]
>print \
1
>end
(gdb)
The above is what this commit restores GDB back to.
New test included.
gdb/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR cli/21218
* top.c (gdb_readline_wrapper): Avoid passing NULL to
display_gdb_prompt.
(command_line_input): Add comment.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
PR cli/21218
* gdb.base/commands.exp (backslash_in_multi_line_command_test):
New proc.
(top level): Call it.
Commit d7e747318f ("Eliminate make_cleanup_ui_file_delete / make
ui_file a class hierarchy") regressed the TUI's command window.
Newlines miss doing a "carriage return", resulting in output like:
~~~~~~~~~~~~~~~~~~
(gdb) helpList of classes of commands:
aliases -- Aliases of other commands
breakpoints -- Making program stop at certain points
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Before the commit mentioned above, the default ui_file->to_write
implementation had a hack that would defer into the ui_file->to_fputs
method. The TUI's ui_file did not implement the to_write method, so
all writes would end up going to the ncurses window via tui_file_fputs
-> tui_puts.
After the commit above, the hack is gone, but the TUI's ui_file still
does not implement the ui_file::write method. Since tui_file inherits
from stdio_file, writing to a tui_file ends up doing fwrite on the
FILE stream the TUI is "associated" with, via stdio_file::write,
instead of writing to the ncurses window.
The fix is to have tui_file override the "write" method.
New test included.
gdb/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR tui/21216
* tui/tui-file.c (tui_file::write): New.
* tui/tui-file.h (tui_file): Override "write".
* tui/tui-io.c (do_tui_putc, update_start_line): New functions,
factored out from ...
(tui_puts): ... here.
(tui_putc): Use them.
(tui_write): New function.
* tui/tui-io.h (tui_write): Declare.
gdb/testsuite/ChangeLog:
2017-03-08 Pedro Alves <palves@redhat.com>
PR tui/21216
* gdb.tui/tui-nl-filtered-output.exp: New file.
Simon Marchi
Simon Marchi
mark
Nick Clifton
Alan Modra
Tristan Gingold
Alexey Neyman
GDB Administrator
Keith Seitz
Chia-Hao Lo
Andrew Burgess
H.J. Lu
Sam Thursfield
Peter Bergner
Pedro Alves
Jiong Wang