2015-10-02 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.dwarf2/staticvirtual.exp: Generalize regexp so it can match
whether or not address 0x1000 is mapped on the target.
bfd/ChangeLog:
* targets.c (enum bfd_flavour): Add comment.
(bfd_flavour_name): New function.
* bfd-in2.h: Regenerate.
gdb/ChangeLog:
* findvar.c (default_read_var_value) <LOC_UNRESOLVED>: Include the
kind of minimal symbol in the error message.
* objfiles.c (objfile_flavour_name): New function.
* objfiles.h (objfile_flavour_name): Declare.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-bad-unresolved.c: New file.
* gdb.dwarf2/dw2-bad-unresolved.exp: New file.
Here, in dwarfread.c:process_full_comp_unit:
/* Set symtab language to language from DW_AT_language. If the
compilation is from a C file generated by language preprocessors, do
not set the language if it was already deduced by start_subfile. */
if (!(cu->language == language_c
&& COMPUNIT_FILETABS (cust)->language != language_c))
COMPUNIT_FILETABS (cust)->language = cu->language;
in case start_subfile doesn't manage to deduce a language
COMPUNIT_FILETABS(cust)->language ends up as language_unknown, not
language_c. So the condition above evals false and we never set the
language from the cu's language.
gdb/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* dwarf2read.c (process_full_comp_unit): To tell whether
start_subfile managed to deduce a language, test for
language_unknown instead of language_c.
gdb/testsuite/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* gdb.dwarf2/comp-unit-lang.exp: New file.
* gdb.dwarf2/comp-unit-lang.c: New file.
This change introduces a new function, dwarf2_string_attr(), which is
a wrapper for dwarf2_attr(). dwarf2read.c has been updated to
call dwarf2_string_attr in most instances where a string-valued
attribute is decoded to produce a string value. In most cases, it
simplifies the code; in some instances, the complexity of the code
remains unchanged.
I performed this change by looking for instances where the
result of DW_STRING was used in an assignment. Many of these
had a pattern which (roughly) looks something like this:
struct attribute *attr = NULL;
attr = dwarf2_attr (die, name, cu);
if (attr != NULL && DW_STRING (attr))
{
const char *str;
...
str = DW_STRING (attr);
... /* Use str in some fashion. */
}
Code of this form is transformed to look like this instead:
const char *str;
str = dwarf2_string_attr (die, name, cu)
if (str != NULL)
{
...
/* Use str in some fashion. */
...
}
In addition to invoking dwarf2_attr() and DW_STRING(),
dwarf2_string_attr() checks to make sure that the attribute's
`form' field matches one of DW_FORM_strp, DW_FORM_string, or
DW_FORM_GNU_strp_alt. If it does not match one of these forms,
it will return a NULL value in addition to calling complaint().
An earlier version of this patch did this type checking for one
particular instance where a string attribute was being decoded.
The situation that I was attempting to handle in that earlier patch is
this:
The Texas Instruments compiler uses the encoding for
DW_AT_MIPS_linkage_name for other purposes. TI uses the encoding,
0x2007, for TI_AT_TI_end_line which, unlike DW_AT_MIPS_linkage_name,
does not have a string-typed value. In this instance, GDB was attempting
to use an integer value as a string pointer, with predictable results.
(GDB would die with a segmentation fault.)
I've added a test which reproduces the problem that I was orignally
wanting to fix. It uses DW_AT_MIPS_linkage name with an associate
value which is a string, and again, where the value is a small
integer.
My test case causes GDB to segfault in an unpatched GDB. There
will be two PASSes in a patched GDB.
Unpatched GDB:
(gdb) ptype f
ERROR: Process no longer exists
UNRESOLVED: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f
ERROR: Couldn't send ptype g to GDB.
UNRESOLVED: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g
Patched GDB:
(gdb) ptype f
type = bool ()
(gdb) PASS: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f
ptype g
type = bool ()
(gdb) PASS: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g
I see no regressions on an x86_64 native target.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_string_attr): New function.
(lookup_dwo_unit, process_psymtab_comp_unit_reader)
(dwarf2_compute_name, dwarf2_physname, find_file_and_directory)
(read_call_site_scope, namespace_name, guess_full_die_structure_name)
(anonymous_struct_prefix, prepare_one_comp_unit): Use
dwarf2_string_attr in place of dwarf2_attr and DW_STRING.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-bad-mips-linkage-name.c: New file.
* gdb.dwarf2/dw2-bad-mips-linkage-name.exp: New file.
Dummy CUs are used by the incremental linker to pre-allocate space
in the output file. They have a DWARF header but no contents.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_per_cu_data): Add comment.
(load_cu): Handle dummy CUs.
(dw2_do_instantiate_symtab, process_queuef): Ditto.
(dwarf2_fetch_die_loc_sect_off, dwarf2_fetch_constant_bytes): Ditto.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-dummy-cu.S: New file.
* gdb.dwarf2/dw2-dummy-cu.exp: New file.
I see many fails in gdb.dwarf2/dynarr-ptr.exp on arm-linux target,
started from this
print foo.three_ptr.all^M
Cannot access memory at address 0x107c8^M
(gdb) FAIL: gdb.dwarf2/dynarr-ptr.exp: print foo.three_ptr.all
print foo.three_ptr.all(1)^M
Cannot access memory at address 0x107c8
It turns out that ":$ptr_size" is used incorrectly.
array_ptr_label: DW_TAG_pointer_type {
{DW_AT_byte_size :$ptr_size }
^^^^^^^^^^
{DW_AT_type :$array_label}
}
Since the FORM isn't given, and it starts with the ":", it is regarded
as a label reference by dwarf assembler. The generated asm file on
x86_64 is
.uleb128 6 /* Abbrev (DW_TAG_pointer_type) */
.4byte 8 - .Lcu1_begin <----- WRONG
.4byte .Llabel2 - .Lcu1_begin
Looks .Lcu1_begin is 0 on x86_64 and that is why this test passes on
x86_64. On arm, .Lcu1_begin is an address somewhere, and the value
of DW_AT_byte_size is a very large number, so memory read request
of such large length failed.
This patch is to remove ":" and set the form explicitly. The generated
asm file on x86_64 becomes
.uleb128 6 /* Abbrev (DW_TAG_pointer_type) */
.byte 8
.4byte .Llabel2 - .Lcu1_begin
gdb/testsuite:
2015-04-15 Yao Qi <yao.qi@linaro.org>
* gdb.dwarf2/dynarr-ptr.exp (assemble): Use $ptr_size instead
of ":$ptr_size" and set its form explicitly.
Variables with a DW_AT_const_value but without a DW_AT_location were not
getting added to the partial symbol table. They are added to the full
symbol table, however, when the compilation unit's psymtabs are
expanded.
Before:
(gdb) p one
No symbol "one" in current context.
(gdb) mt flush-symbol-cache
(gdb) mt expand one.c
(gdb) p one
$1 = 1
After:
(gdb) p one
$1 = 1
To the user it's pretty strange, as depending on whether tab completion
has forced expansion of all CUs or not the lookup might succeed, or not
if the failure was already added to the symbol cache.
This commit simply makes sure to add constants to the partial symbol
tables.
gdb/testsuite/ChangeLog:
PR symtab/18148
* gdb.dwarf2/dw2-intercu.S (one, two): Add variables that have a
const_value but not a location.
* gdb.dwarf2/dw2-intercu.exp: Add tests that constants without
location defined in non-main CUs are visible.
gdb/ChangeLog:
PR symtab/18148
* dwarf2read.c (struct partial_die_info): Add has_const_value
member.
(add_partial_symbol): Don't punt on symbols that have const_value
attributes.
(read_partial_die): Detect DW_AT_const_value.
This bug appears to be caused by bad debuginfo. The method
causing the sefault in the reporter's test case is marked both static
and virtual.
This patch simply safegaurds against this case in dwarf2_add_member_fn,
where the code assumes that there is a `this' pointer when a virtual method
is seen (more specifically, when DW_AT_vtable_elem is seen).
It previously dereferenced the first formal parameter
(`this' pointer), which in this case doesn't exist. GDB consequently
segfaulted dereferencing a NULL pointer.
gdb/ChangeLog
PR gdb/18021
* dwarf2read.c (dwarf2_add_member_fn): Issue a complaint
if we find a static method with DW_AT_vtable_elem_location.
gdb/testsuite/ChangeLog
PR gdb/18021
* gdb.dwarf2/staticvirtual.exp: New test.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (Dwarf): Flag an error if a numeric attribute value
is given without an explicit form.
* gdb.dwarf2/arr-subrange.exp: Specify forms for all numeric
attributes.
* gdb.dwarf/corrupt.exp: Ditto.
* gdb.dwarf2/enum-type.exp: Ditto.
* gdb.trace/entry-values.exp: Ditto.
* gdb.trace/unavailable-dwarf-piece.exp: Ditto.
Address issues triggered by the MIPS ISA bit handling change, usually in
tests that make artificial DWARF-2 records:
* gdb.cp/expand-psymtabs-cxx.exp -- this test is debugging an object file
and assuming addresses will be 0; with the ISA bit set code addresses
are 1 instead:
(gdb) PASS: gdb.cp/expand-psymtabs-cxx.exp: set language c++
p 'method(long)'
$1 = {void (long)} 0x1 <method(long)>
(gdb) FAIL: gdb.cp/expand-psymtabs-cxx.exp: before expand
p method
$2 = {void (long)} 0x1 <method(long)>
(gdb) FAIL: gdb.cp/expand-psymtabs-cxx.exp: force expand
p 'method(long)'
$3 = {void (long)} 0x1 <method(long)>
(gdb) FAIL: gdb.cp/expand-psymtabs-cxx.exp: after expand
Fix by matching any hex number, there's no value AFAICT for the test
in matching 0 exactly, and I suppose the method's offset within
section can be non-zero for some other reasons on other targets too.
* gdb.cp/nsalias.exp -- this assumes instructions can be aligned
arbitrarily and places code labels at odd addreses, setting the ISA
bit and wreaking havoc:
(gdb) PASS: gdb.cp/nsalias.exp: print outer::inner::innermost::x
list outer::inner::innermost::foo
Function "outer::inner::innermost::foo" not defined.
(gdb) FAIL: gdb.cp/nsalias.exp: list outer::inner::innermost::foo
break *outer::inner::innermost::foo
No symbol "foo" in namespace "outer::inner::innermost".
(gdb) FAIL: gdb.cp/nsalias.exp: setting breakpoint at
*outer::inner::innermost::foo
delete $bpnum
No breakpoint number 6.
(gdb) FAIL: gdb.cp/nsalias.exp: (outer::inner::innermost): delete $bpnum
-- etc., etc... Fix by aligning labels to 4; required by many
processors.
* gdb.dwarf2/dw2-canonicalize-type.exp, gdb.dwarf2/dw2-empty-pc-range.exp,
gdb.dwarf2/pr11465.exp -- these assume an instruction and consequently
a function can take as little as 1 byte, which makes it impossible to
look up a code symbol by an address with the ISA bit set as the
address is already beyond the end of the function:
(gdb) ptype f
No symbol "f" in current context.
(gdb) FAIL: gdb.dwarf2/dw2-canonicalize-type.exp: ptype f
(gdb) PASS: gdb.dwarf2/dw2-empty-pc-range.exp: empty range before CU load
ptype realrange
No symbol "realrange" in current context.
(gdb) FAIL: gdb.dwarf2/dw2-empty-pc-range.exp: valid range after CU load
(gdb) p N::c.C
Cannot take address of method C.
(gdb) FAIL: gdb.dwarf2/pr11465.exp: p N::c.C
-- fix by increasing the size of the function to 4 (perhaps code in
gdb/mips-tdep.c could look up code symbols up to twice, with and
failing that without the ISA bit set, but it seems wrong to me to
implement specific handling for invalid code just to satisfy test
cases that assume too much about the target).
* gdb.dwarf2/dw2-case-insensitive.exp -- an artificial code label is
created, but does not work because data (a `.align' pseudo-op in this
case) follows and as a result the label has no MIPS16 or microMIPS
annotation in the symbol table:
(gdb) PASS: gdb.dwarf2/dw2-case-insensitive.exp: set case-sensitive off
info functions fUnC_lang
All functions matching regular expression "fUnC_lang":
File file1.txt:
foo FUNC_lang(void);
Non-debugging symbols:
0x004006e0 FUNC_lang_start
(gdb) FAIL: gdb.dwarf2/dw2-case-insensitive.exp: regexp case-sensitive off
-- fix by adding a `.insn' pseudo-op on MIPS targets; the pseudo-op
marks data as instructions.
* gdb.dwarf2/dw2-stack-boundary.exp -- the test case enables complaints
and assumes none will be issued beyond ones explicitly arranged by the
test case, however overlapping sections are noticed while minimal
symbols are looked up by `mips_adjust_dwarf2_addr' in DWARF-2 record
processing:
(gdb) set complaints 100
(gdb) PASS: gdb.dwarf2/dw2-stack-boundary.exp: set complaints 100
file ./dw2-stack-boundary
Reading symbols from ./dw2-stack-boundary...location description stack
underflow...location description stack overflow...unexpected overlap
between:
(A) section `.reginfo' from `.../gdb.dwarf2/dw2-stack-boundary' [0x0, 0x18)
(B) section `*COM*' from `.../gdb.dwarf2/dw2-stack-boundary' [0x0, 0x0).
Will ignore section B...unexpected overlap between:
(A) section `.reginfo' from `.../gdb.dwarf2/dw2-stack-boundary' [0x0, 0x18)
(B) section `*UND*' from `.../gdb.dwarf2/dw2-stack-boundary' [0x0, 0x0).
Will ignore section B...unexpected overlap between:
(A) section `.reginfo' from `.../gdb.dwarf2/dw2-stack-boundary' [0x0, 0x18)
(B) section `*ABS*' from `.../gdb.dwarf2/dw2-stack-boundary' [0x0, 0x0).
Will ignore section B...done.
(gdb) FAIL: gdb.dwarf2/dw2-stack-boundary.exp: check partial symtab errors
-- fix by ignoring any extra noise as long as what we look for is
found.
* gdb.cp/expand-psymtabs-cxx.exp: Accept any address of
`method(long)', not just 0x0.
* gdb.cp/nsalias.exp: Align code labels to 4.
* gdb.dwarf2/dw2-canonicalize-type.S (main): Expand to 4-bytes.
* gdb.dwarf2/dw2-empty-pc-range.S (main): Likewise.
* gdb.dwarf2/pr11465.S (_ZN1N1cE): Likewise.
* gdb.dwarf2/dw2-case-insensitive.c (START_INSNS): New macro.
(cu_text_start, FUNC_lang_start): Use `START_INSNS'.
* gdb.dwarf2/dw2-stack-boundary.exp: Accept noise in complaints.
Python 3's print requires to use parentheses, so this patch adds them
where they were missing.
gdb/testsuite/ChangeLog:
* gdb.ada/py_range.exp: Add parentheses to calls to print.
* gdb.dwarf2/symtab-producer.exp: Same.
* gdb.gdb/python-interrupts.exp: Same.
* gdb.gdb/python-selftest.exp: Same.
* gdb.python/py-linetable.exp: Same.
* gdb.python/py-type.exp: Same.
* gdb.python/py-value-cc.exp: Same.
* gdb.python/py-value.exp: Same.
This patch fixes two fails in dw2-compdir-oldgcc.exp I've seen on arm
target thumb mode.
FAIL: gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc42
FAIL: gdb.dwarf2/dw2-compdir-oldgcc.exp: info source gcc43
When fill in DW_AT_low_pc, the label should be used rather than the
function, otherwise, the LSB bit of the address in DW_AT_low_pc is
set and the debug info is wrong. This patch is to add two labels for
functions gcc42 and gcc43 respectively, and use them. These two
fails are fixed.
gdb/testsuite:
2014-11-22 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-compdir-oldgcc.S: Define label .Lgcc42_procstart
and .Lgcc43_procstart. Use .Lgcc42_procstart instead of gcc42.
Use .Lgcc43_procstart instead of gcc43.
The patch <https://sourceware.org/ml/gdb-patches/2014-03/msg00202.html>
fixed dw2-ifort-parameter.exp on powerpc64 by adding some labels to
get the start and end address of function func. This should also fix the
fail on thumb mode, however, this style is quite specific to gcc, and
other compiler, such as clang, may not guarantee the order of global
asms and functions. The test fails with clang:
$ make check RUNTESTFLAGS='dw2-ifort-parameter.exp CC_FOR_TARGET=clang'
(gdb) p/x param^M
No symbol "param" in current context.^M
(gdb) FAIL: gdb.dwarf2/dw2-ifort-parameter.exp: p/x param
With this patch applied, dw2-ifort-parameter.exp still passes for gcc
on arm thumb mode and popwerpc64, and it also passes for clang on
x86_linux.
gdb/testsuite:
2014-11-14 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-ifort-parameter.c: Remove inline asm.
(func): Add label func_label.
* gdb.dwarf2/dw2-ifort-parameter.exp (Dwarf::assemble):
Replace low_pc and high_pc with MACRO_AT_range.
Replace name, low_pc and high_pc with MACRO_AT_func.
Hi,
I see the fail in gdb.dwarf2/implptr-optimized-out.exp in thumb mode
(gdb) p p->f^M
No symbol "p" in current context.^M
(gdb) FAIL: gdb.dwarf2/implptr-optimized-out.exp: p p->f
and the crash on powerpc64
(gdb) continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0x7d82100810000828 in ?? ()
The cause of both is that we incorrectly set attribute low_pc, since
main isn't resolved to function start address on these targets.
In this patch, we replace attributes name, low_pc and high_pc with
MACRO_AT_func. The fail on thumb mode is fixed, and crash on
powerpc64 is fixed too.
gdb/testsuite:
2014-11-14 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/implptr-optimized-out.exp (Dwarf::assemble):
Replace name, low_pc and high_pc with MACRO_AT_func.
This patch is to use dwarf::assemble to generate debug information, and
remove implptr-optimized-out.S as a result.
gdb/testsuite:
2014-11-14 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/implptr-optimized-out.exp: Use Dwarf::assemble to
produce debug information.
* gdb.dwarf2/implptr-optimized-out.S: Removed.
On arm-none-eabi target thumb mode, I see the following fail,
p the_int^M
$2 = 99^M
(gdb) FAIL: gdb.dwarf2/dwz.exp: p the_int
and on powerpc64 target, we even can't get function main from object
file,
disassemble main^M
No function contains specified address.^M
(gdb) FAIL: gdb.dwarf2/dwz.exp: disassemble main
This patch is to use MACRO_AT_func attribute to get the main's start
address and end address correctly, and also remove some code dwz.exp
getting main's length. This patch fixes fails on both thumb mode and
powerpc64 target.
PASS: gdb.dwarf2/dwz.exp: p other_int
PASS: gdb.dwarf2/dwz.exp: p the_int
gdb/testsuite:
2014-11-14 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwz.exp: Remove the code to compile main.c to
object and get function length.
(Dwarf::assemble): Replace name, low_pc and high_pc attributes
with MACRO_AT_func.
(top-level): Replace gdb_compile and clean_restart with
prepare_for_testing.
* gdb.dwarf2/main.c (main): Add label main_label.
Nowadays, if we do in-tree build and run tests sequentially, some source
files are removed, due to the following pattern:
set pi_txt [gdb_remote_download host ${srcdir}/${subdir}/pi.txt]
remote_exec host "rm -f $pi_txt"
If testing is run sequentially, file ${srcdir}/${subdir}/pi.txt is
copied to ${objdir}/${subdir}/pi.txt. However, ${objdir} is ${srcdir}
in the in-tree build/test, so the file is coped to itself, as a nop.
As a result, the file in source is removed at the end of test.
This patch fixes this problem by not removing files copied to host in
each test. This patch also addresses the question we've had that why
don't we keep files copied to host because they are needed to reproduce
certain fails.
gdb/testsuite:
2014-10-20 Yao Qi <yao@codesourcery.com>
* gdb.base/checkpoint.exp: Don't remove file copied on host.
* gdb.base/step-line.exp: Likewise.
* gdb.dwarf2/dw2-anonymous-func.exp: Likewise.
* gdb.dwarf2/dw2-basic.exp: Likewise.
* gdb.dwarf2/dw2-compressed.exp: Likewise.
* gdb.dwarf2/dw2-filename.exp: Likewise.
* gdb.dwarf2/dw2-intercu.exp: Likewise.
* gdb.dwarf2/dw2-intermix.exp: Likewise.
* gdb.dwarf2/dw2-producer.exp: Likewise.
* gdb.dwarf2/mac-fileno.exp: Likewise.
* gdb.python/py-frame-args.exp: Likewise.
* gdb.python/py-framefilter.exp: Likewise.
* gdb.python/py-mi.exp: Likewise.
* gdb.python/py-objfile-script.exp: Likewise
* gdb.python/py-pp-integral.exp: Likewise.
* gdb.python/py-pp-re-notag.exp: Likewise.
* gdb.python/py-prettyprint.exp: Likewise.
* gdb.python/py-section-script.exp: Likewise.
* gdb.python/py-typeprint.exp: Likewise.
* gdb.python/py-xmethods.exp: Likewise.
* gdb.stabs/weird.exp: Likewise.
* gdb.xml/tdesc-regs.exp: Likewise.
This patch fixes the failures that occur with the
gdb.dwarf2/dw2-dir-file-name.exp test on 64-bit MIPS and compressed
MIPS ISAs (i.e. MIPS16 and microMIPS).
The failures on 64-bit occur because the generated DWARF address
information is always 32-bit, which causes the upper 32-bits of
addresses to be truncated and causes breakpoints to be set on the
wrong address if any of the upper 32-bits are non-zero. I suspect
that other 64-bit architectures get away with it because they
place all their instructions at a VMA lower than 2^32 by default.
This patch causes 64-bit addresses to be generated if a 64-bit
target is detected.
The failures on MIPS16 and microMIPS occur because the breakpoint
address needs to have the LSB set to 1 (used to indicate that the
code is compressed). However, the function name is interpreted as
a data label, causing GDB to set breakpoints at even addresses.
This is fixed by explicitly adding a '.insn' directive (see
https://sourceware.org/binutils/docs/as/MIPS-insn.html) after the
label on MIPS only.
gdb/testsuite/
2014-10-18 Kwok Cheung Yeung <kcy@codesourcery.com>
* gdb.dwarf2/dw2-dir-file-name.exp (addr_len): New.
(out_cu): Use addr_len for the size of addresses.
(out_line): Likewise. Size DW_LNE_set_address instruction
according to addr_len.
* gdb.dwarf2/dw2-dir-file-name.c (START_INSNS): New.
(FUNC): Add START_INSNS to definition.
This test will pass if the CU is the first CU in the binary.
If libc debugging info is installed it may not be, in which case
the CU offset values are wrong.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-op-out-param.S: Make DW_FORM_ref4 values be the offset
from the start of the CU.
This patch is to extend dw2-var-zero-add.exp to cover the case that
partial symtabl is not used while full symtab is used, in order to
cover the changes in patch 2/3. This patch restarts GDB with
--readnow and does the same test again.
gdb/testsuite:
2014-09-19 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-var-zero-addr.exp: Move test into new proc test.
Invoke test. Restart GDB with --readnow and invoke test again.
Trying to print the bounds or the length of a pointer to an array
whose bounds are dynamic results in the following error:
(gdb) p foo.three_ptr.all'first
Location address is not set.
(gdb) p foo.three_ptr.all'length
Location address is not set.
This is because, after having dereferenced our array pointer, we
use the type of the resulting array value, instead of the enclosing
type. The former is the original type where the bounds are unresolved,
whereas we need to get the actual array bounds.
Similarly, trying to apply those attributes to the array pointer
directly (without explicitly dereferencing it with the '.all'
operator) yields the same kind of error:
(gdb) p foo.three_ptr'first
Location address is not set.
(gdb) p foo.three_ptr'length
Location address is not set.
This is caused by the fact that the dereference was done implicitly
in this case, and perform at the type level only, which is not
sufficient in order to resolve the array type.
This patch fixes both issues, thus allowing us to get the expected output:
(gdb) p foo.three_ptr.all'first
$1 = 1
(gdb) p foo.three_ptr.all'length
$2 = 3
(gdb) p foo.three_ptr'first
$3 = 1
(gdb) p foo.three_ptr'length
$4 = 3
gdb/ChangeLog:
* ada-lang.c (ada_array_bound): If ARR is a TYPE_CODE_PTR,
dereference it first. Use value_enclosing_type instead of
value_type.
(ada_array_length): Likewise.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.exp: Add 'first, 'last and 'length tests.
Consider a pointer to an array which dynamic bounds, described in
DWARF as follow:
<1><25>: Abbrev Number: 4 (DW_TAG_array_type)
<26> DW_AT_name : foo__array_type
[...]
<2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type)
[...]
<40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4
(DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus;
DW_OP_deref_size: 4)
<46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4
(DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus;
DW_OP_deref_size: 4)
GDB is now able to correctly print the entire array, but not one
element of the array. Eg:
(gdb) p foo.three_ptr.all
$1 = (1, 2, 3)
(gdb) p foo.three_ptr.all(1)
Cannot access memory at address 0xfffffffff4123a0c
The problem occurs because we are missing a dynamic resolution of
the variable's array type when subscripting the array. What the current
code does is "fix"-ing the array type using the GNAT encodings, but
that operation ignores any of the array's dynamic properties.
This patch fixes the issue by using ada_value_ind to dereference
the array pointer, which takes care of the array type resolution.
It also continues to "fix" arrays described using GNAT encodings,
so backwards compatibility is preserved.
gdb/ChangeLog:
* ada-lang.c (ada_value_ptr_subscript): Remove parameter "type".
Adjust function implementation and documentation accordingly.
(ada_evaluate_subexp) <OP_FUNCALL>: Only assign "type" if
NOSIDE is EVAL_AVOID_SIDE_EFFECTS.
Update call to ada_value_ptr_subscript.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.exp: Add subscripting tests.
Consider the following declaration:
type Array_Type is array (Natural range <>) of Integer;
type Array_Ptr is access all Array_Type;
for Array_Ptr'Size use 64;
Three_Ptr : Array_Ptr := new Array_Type'(1 => 1, 2 => 2, 3 => 3);
This creates a pointer to an array where the bounds are stored
in a memory region just before the array itself (aka a "thin pointer").
In DWARF, this is described as a the usual pointer type to an array
whose subrange has dynamic values for its bounds:
<1><25>: Abbrev Number: 4 (DW_TAG_array_type)
<26> DW_AT_name : foo__array_type
[...]
<2><3b>: Abbrev Number: 5 (DW_TAG_subrange_type)
[...]
<40> DW_AT_lower_bound : 5 byte block: 97 38 1c 94 4
(DW_OP_push_object_address; DW_OP_lit8; DW_OP_minus;
DW_OP_deref_size: 4)
<46> DW_AT_upper_bound : 5 byte block: 97 34 1c 94 4
(DW_OP_push_object_address; DW_OP_lit4; DW_OP_minus;
DW_OP_deref_size: 4)
GDB is currently printing the value of the array incorrectly:
(gdb) p foo.three_ptr.all
$1 = (26629472 => 1, 2,
value.c:819: internal-error: value_contents_bits_eq: [...]
The dereferencing (".all" operator) is done by calling ada_value_ind,
which itself calls value_ind. It first produces a new value where
the bounds of the array were correctly resolved to their actual value,
but then calls readjust_indirect_value_type which replaces the resolved
type by the original type.
The problem starts when ada_value_print does not take this situation
into account, and starts using the type of the resulting value, which
has unresolved array bounds, instead of using the value's enclosing
type.
After fixing this issue, the debugger now correctly prints:
(gdb) p foo.three_ptr.all
$1 = (1, 2, 3)
gdb/ChangeLog:
* ada-valprint.c (ada_value_print): Use VAL's enclosing type
instead of VAL's type.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dynarr-ptr.c: New file.
* gdb.dwarf2/dynarr-ptr.exp: New file.
See the description here:
https://sourceware.org/ml/gdb-patches/2014-08/msg00283.html
This patch keeps track of whether the current line has seen a
non-zero discriminator, and if so coalesces consecutive entries
for the same line (by ignoring all entries after the first).
gdb/ChangeLog:
PR 17276
* dwarf2read.c (dwarf_record_line_p): New function.
(dwarf_decode_lines_1): Ignore subsequent line number entries
for the same line if any entry had a non-zero discriminator.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-single-line-discriminators.S: New file.
* gdb.dwarf2/dw2-single-line-discriminators.c: New file.
* gdb.dwarf2/dw2-single-line-discriminators.exp: New file.
Consider an array described in the debugging information as being
a typedef of an array type for which there is a DW_AT_data_location
attribute. Trying to print the value of that array currently yields
incorrect element values. For instance:
(gdb) print foo.three_tdef
$1 = (6293760, 0, 6293772)
The problem occurs because we check for the data_location attribute
only on the typedef type, whereas we should be checking for the
typedef's target type. As a result, GDB erroneously thinks that
there is no data_location, and therefore starts reading the array's
content from the address of the descriptor instead of the data_location
address.
gdb/ChangeLog:
* value.c (value_from_contents_and_address): Strip resolved_type's
typedef layers before checking its TYPE_DATA_LOCATION.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/data-loc.exp: Add additional tests exercising
the handling of variables declared as a typedef to an array
which a DW_AT_data_location attribute.
This fixes PR symtab/14604, PR symtab/14605, and Jan's test at
https://sourceware.org/ml/gdb-patches/2014-07/msg00158.html, in a tree
with bddbbed reverted:
2014-07-22 Pedro Alves <palves@redhat.com>
* value.c (allocate_optimized_out_value): Don't mark value as
non-lazy.
The PRs are about variables described by the DWARF as being split over
multiple registers using DWARF piece information, but some of those
registers being marked as optimised out (not saved) by a later frame.
GDB currently incorrectly mishandles these partially-optimized-out
values.
Even though we can usually tell from the debug info whether a local or
global is optimized out, handling the case of a local living in a
register that was not saved in a frame requires fetching the variable.
GDB also needs to fetch a value to tell whether parts of it are
"<unavailable>". Given this, it's not worth it to try to avoid
fetching lazy optimized-out values based on debug info alone.
So this patch makes GDB track which chunks of a value's contents are
optimized out like it tracks <unavailable> contents. That is, it
makes value->optimized_out be a bit range vector instead of a boolean,
and removes the struct lval_funcs check_validity and check_any_valid
hooks.
Unlike Andrew's series which this is based on (at
https://sourceware.org/ml/gdb-patches/2013-08/msg00300.html, note some
pieces have gone in since), this doesn't merge optimized out and
unavailable contents validity/availability behind a single interface,
nor does it merge the bit range vectors themselves (at least yet).
While it may be desirable to have a single entry point that returns
existence of contents irrespective of what may make them
invalid/unavailable, several places want to treat optimized out /
unavailable / etc. differently, so each spot that potentially could
use it will need to be careful considered on case-by-case basis, and
best done as a separate change.
This fixes Jan's test, because value_available_contents_eq wasn't
considering optimized out value contents. It does now, and because of
that it's been renamed to value_contents_eq.
A new intro comment is added to value.h describing "<optimized out>",
"<not saved>" and "<unavailable>" values.
gdb/
PR symtab/14604
PR symtab/14605
* ada-lang.c (coerce_unspec_val_to_type): Use
value_contents_copy_raw.
* ada-valprint.c (val_print_packed_array_elements): Adjust.
* c-valprint.c (c_val_print): Use value_bits_any_optimized_out.
* cp-valprint.c (cp_print_value_fields): Let the common printing
code handle optimized out values.
(cp_print_value_fields_rtti): Use value_bits_any_optimized_out.
* d-valprint.c (dynamic_array_type): Use
value_bits_any_optimized_out.
* dwarf2loc.c (entry_data_value_funcs): Remove check_validity and
check_any_valid fields.
(check_pieced_value_bits): Delete and inline ...
(check_pieced_synthetic_pointer): ... here.
(check_pieced_value_validity): Delete.
(check_pieced_value_invalid): Delete.
(pieced_value_funcs): Remove check_validity and check_any_valid
fields.
(read_pieced_value): Use mark_value_bits_optimized_out.
(write_pieced_value): Switch to use
mark_value_bytes_optimized_out.
(dwarf2_evaluate_loc_desc_full): Copy the value contents instead
of assuming the whole value is optimized out.
* findvar.c (read_frame_register_value): Remove special handling
of optimized out registers.
(value_from_register): Use mark_value_bytes_optimized_out.
* frame-unwind.c (frame_unwind_got_optimized): Use
mark_value_bytes_optimized_out.
* jv-valprint.c (java_value_print): Adjust.
(java_print_value_fields): Let the common printing code handle
optimized out values.
* mips-tdep.c (mips_print_register): Remove special handling of
optimized out registers.
* opencl-lang.c (lval_func_check_validity): Delete.
(lval_func_check_any_valid): Delete.
(opencl_value_funcs): Remove check_validity and check_any_valid
fields.
* p-valprint.c (pascal_object_print_value_fields): Let the common
printing code handle optimized out values.
* stack.c (read_frame_arg): Remove special handling of optimized
out values. Fetch both VAL and ENTRYVAL before comparing
contents. Adjust to value_available_contents_eq rename.
* valprint.c (valprint_check_validity)
(val_print_scalar_formatted): Use value_bits_any_optimized_out.
(val_print_array_elements): Adjust.
* value.c (struct value) <optimized_out>: Now a VEC(range_s).
(value_bits_any_optimized_out): New function.
(value_entirely_covered_by_range_vector): New function, factored
out from value_entirely_unavailable.
(value_entirely_unavailable): Reimplement.
(value_entirely_optimized_out): New function.
(insert_into_bit_range_vector): New function, factored out from
mark_value_bits_unavailable.
(mark_value_bits_unavailable): Reimplement.
(struct ranges_and_idx): New struct.
(find_first_range_overlap_and_match): New function, factored out
from value_available_contents_bits_eq.
(value_available_contents_bits_eq): Rename to ...
(value_contents_bits_eq): ... this. Check both unavailable
contents and optimized out contents.
(value_available_contents_eq): Rename to ...
(value_contents_eq): ... this.
(allocate_value_lazy): Remove reference to the old optimized_out
boolean.
(allocate_optimized_out_value): Use
mark_value_bytes_optimized_out.
(require_not_optimized_out): Adjust to check whether the
optimized_out vec is empty.
(ranges_copy_adjusted): New function, factored out from
value_contents_copy_raw.
(value_contents_copy_raw): Also copy the optimized out ranges.
Assert the destination ranges aren't optimized out.
(value_contents_copy): Update comment, remove call to
require_not_optimized_out.
(value_contents_equal): Adjust to check whether the optimized_out
vec is empty.
(set_value_optimized_out, value_optimized_out_const): Delete.
(mark_value_bytes_optimized_out, mark_value_bits_optimized_out):
New functions.
(value_entirely_optimized_out, value_bits_valid): Delete.
(value_copy): Take a VEC copy of the 'optimized_out' field.
(value_primitive_field): Remove special handling of optimized out.
(value_fetch_lazy): Assert that lazy values have no unavailable
regions. Use value_bits_any_optimized_out. Remove some special
handling for optimized out values.
* value.h: Add intro comment about <optimized out> and
<unavailable>.
(struct lval_funcs): Remove check_validity and check_any_valid
fields.
(set_value_optimized_out, value_optimized_out_const): Remove.
(mark_value_bytes_optimized_out, mark_value_bits_optimized_out):
New declarations.
(value_bits_any_optimized_out): New declaration.
(value_bits_valid): Delete declaration.
(value_available_contents_eq): Rename to ...
(value_contents_eq): ... this, and extend comments.
gdb/testsuite/
PR symtab/14604
PR symtab/14605
* gdb.dwarf2/dw2-op-out-param.exp: Remove kfail branches and use
gdb_test.
The testcase generates an assembly file where a second DW_AT_upper_bound
attribute gets generated in the array range. This was definitely
unintentional, and I only noticed this after pushing the testcase,
when dumping one more time the DWARF data using readelf.
This patch fixes it.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/data-loc.exp: Remove second DW_AT_upper bound
attribute in array range.
This testcase allows us to test the proper processing of both
DW_AT_data_location and DW_OP_push_object_address using a hand-crafted
testcase duplicating how we expect the Ada compiler to represent
unbounded arrays.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/data-loc.c, gdb.dwarf2/data-loc.exp: New files.
On x86_64 with -m32 or on i686 it will:
Running ./gdb.arch/amd64-stap-special-operands.exp ...
gdb compile failed, amd64-stap-triplet.c: Assembler messages:
amd64-stap-triplet.c:35: Error: bad register name `%rbp'
amd64-stap-triplet.c:38: Error: bad register name `%rsp'
amd64-stap-triplet.c:40: Error: bad register name `%rbp)'
amd64-stap-triplet.c:41: Error: bad register name `%rsi'
amd64-stap-triplet.c:42: Error: bad register name `%rbp)'
/tmp/ccjOdmpl.s:63: Error: bad register name `%rbp'
2014-06-23 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/amd64-stap-special-operands.exp: Use is_lp64_target.
* gdb.arch/amd64-stap-optional-prefix.exp: Likewise.
* gdb.dwarf2/dw2-error.exp: Use istarget and is_lp64_target.
Message-ID: <20140622211401.GA3716@host2.jankratochvil.net>
Some gdb.dwarf2/*.exp tests copy file1.txt to host via gdb_remote_download
but dw2-filename.exp and dw2-anonymous-func.exp don't do that. Looks like
an oversight in this patch
https://sourceware.org/ml/gdb-patches/2013-08/msg00365.html
There are some fails in remote host testing.
FAIL: gdb.dwarf2/dw2-anonymous-func.exp: list file1.txt
FAIL: gdb.dwarf2/dw2-filename.exp: interpreter-exec mi -file-list-exec-source-files
FAIL: gdb.dwarf2/dw2-filename.exp: info sources
This patch is to invoke gdb_remote_download to copy file1.txt to host
and remote it at the end. This patch fixes these fails above.
gdb/testsuite:
2014-05-16 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dw2-filename.exp: Copy file1.txt to host. Remove
file1.txt from host at the end.
* gdb.dwarf2/dw2-anonymous-func.exp: Likewise.
Since we're not compiling with gcc, we don't know where the
DWO file will ultimately be built. It could be built in
testsuite/gdb.dwarf2/foo (non-parallel mode) or
testsuite/outputs/gdb.dwarf2/foo (parallel mode).
* gdb.dwarf2/fission-reread.S: Remove directory from .dwo file path.
* gdb.dwarf2/fission-reread.exp: Set debug-file-directory before
loading file. Add test for TU lookup.
Hi,
I recently see the fail in dwzbuildid.exp below on some targets,
(gdb) print the_int
No symbol "the_int" in current context.
(gdb) FAIL: gdb.dwarf2/dwzbuildid.exp: mismatch: print the_int
Looks the pattern expects to see "No symbol table is loaded", which
is emitted in c-exp.y,
variable: name_not_typename
....
if (msymbol.minsym != NULL)
write_exp_msymbol (pstate, msymbol);
else if (!have_full_symbols () && !have_partial_symbols ())
error (_("No symbol table is loaded. Use the \"file\" command."));
else
error (_("No symbol \"%s\" in current context."),
copy_name ($1.stoken));
it is expected to have no full symbols nor partial symbols, but something
brings full symbols or partial symbols in. I added "maint info symtabs"
and "maint info psymtabs" in dwzbuildid.exp, and it shows symbols are from
ld.so, which has debug information. Then, I reproduce the fail like this,
$ make check RUNTESTFLAGS="CFLAGS_FOR_TARGET='-Wl,-rpath=${glibc_build}:${glibc_build}/math -Wl,--dynamic-linker=${glibc_build}/elf/ld.so' dwzbuildid.exp"
${glibc_build} is the glibc build tree. Debug information is not striped,
so the test fail. However, if I strip debug information from libc.so, libm.so
and ld.so. The test passes.
This patch is to relax the pattern to match the both cases that glibc build
has and has not debug information.
gdb/testsuite:
2014-05-07 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwzbuildid.exp: Match output "No symbol "the_int" in
current context" too.
In Dwarf::assemble in dwz.exp, 10 is hard-coded in it,
subprogram {
{name main}
{low_pc main addr}
{high_pc "main + 10" addr}
}
however, the length of main function varies on architectures. The
hard-coded 10 here causes dwz.exp fails on some targets, such as
nios2.
This patch is to add some code to compute the length of function main,
which is similar to what we are doing in entry-values.exp.
gdb/testsuite:
2014-04-26 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwz.exp: Compile main.c to object. Restart GDB
and compute the length of function main. Save it in
$main_length.
(Dwarf::assemble): Use $main_length instead of hard-coded 10.
(top-level): Use gdb_compile to compile objects into
executable and restart GDB. Remove invocation to
prepare_for_testing.
I happen to see that 'double_label' isn't used in dwz.exp dwarf assembler.
Similarly, partial_label and double_label aren't used in dwzbuildid.exp.
This patch is to remove them.
gdb/testsuite:
2014-04-25 Yao Qi <yao@codesourcery.com>
* gdb.dwarf2/dwz.exp (Dwarf::assemble): Remove unused
double_label.
* gdb.dwarf2/dwzbuildid.exp (Dwarf::assemble): Remove
partial_label and double_label.
Install some sanity checks that sibling DIE offsets are not beyond the
defined limits of the DWARF input buffer in read_partial_die and skip_one_die.
2014-03-20 Keith Seitz <keiths@redhat.com>
PR gdb/15827
* dwarf2read.c (skip_one_die): Check that all relative-offset
sibling DIEs fall within range of the current reader's buffer.
(read_partial_die): Likewise.
2014-03-20 Keith Seitz <keiths@redhat.com>
PR gdb/15827
* gdb.dwarf2/corrupt.c: New file.
* gdb.dwarf2/corrupt.exp: New file.
PR c++/16253.
symbol_matches_domain was permitting searches for a VAR_DOMAIN
symbol to also match STRUCT_DOMAIN symbols for languages like C++
where STRUCT_DOMAIN symbols also define a typedef of the same name,
e.g., "struct foo {}" introduces a typedef of the name "foo".
Problems occur if there exists both a VAR_DOMAIN and STRUCT_DOMAIN
symbol of the same name. Then it is essentially a race between which
symbol is found first. The other symbol is obscurred.
[This is a relatively common idiom: enum e { ... } e;]
This patchset moves this "language defines a typedef" logic to
lookup_symbol[_in_language], looking first for a symbol in the given
domain and falling back to searching STRUCT_DOMAIN when/if appropriate.
2014-04-14 Keith Seitz <keiths@redhat.com>
PR c++/16253
* ada-lang.c (ada_symbol_matches_domain): Moved here and renamed
from symbol_matches_domain in symtab.c. All local callers
of symbol_matches_domain updated.
(standard_lookup): If DOMAIN is VAR_DOMAIN and no symbol is found,
search STRUCT_DOMAIN.
(ada_find_any_type_symbol): Do not search STRUCT_DOMAIN
independently. standard_lookup will do that automatically.
* cp-namespace.c (cp_lookup_symbol_nonlocal): Explain when/why
VAR_DOMAIN searches may return a STRUCT_DOMAIN match.
(cp_lookup_symbol_in_namespace): Likewise.
If no VAR_DOMAIN symbol is found, search STRUCT_DOMAIN.
(cp_lookup_symbol_exports): Explain when/why VAR_DOMAIN searches
may return a STRUCT_DOMAIN match.
(lookup_symbol_file): Search for the class name in STRUCT_DOMAIN.
* cp-support.c: Include language.h.
(inspect_type): Explicitly search STRUCT_DOMAIN before searching
VAR_DOMAIN.
* psymtab.c (match_partial_symbol): Compare the requested
domain with the symbol's domain directly.
(lookup_partial_symbol): Likewise.
* symtab.c (lookup_symbol_in_language): Explain when/why
VAR_DOMAIN searches may return a STRUCT_DOMAIN match.
If no VAR_DOMAIN symbol is found, search STRUCT_DOMAIN for
appropriate languages.
(symbol_matches_domain): Renamed `ada_symbol_matches_domain'
and moved to ada-lang.c
(lookup_block_symbol): Explain that this function only returns
symbol matching the requested DOMAIN.
Compare the requested domain with the symbol's domain directly.
(iterate_over_symbols): Compare the requested domain with the
symbol's domain directly.
* symtab.h (symbol_matches_domain): Remove.
2014-04-14 Keith Seitz <keiths@redhat.com>
PR c++/16253
* gdb.cp/var-tag.cc: New file.
* gdb.cp/var-tag.exp: New file.
* gdb.dwarf2/dw2-ada-ffffffff.exp: Set the language to C++.
* gdb.dwarf2/dw2-anon-mptr.exp: Likewise.
* gdb.dwarf2/dw2-double-set-die-type.exp: Likewise.
* gdb.dwarf2/dw2-inheritance.exp: Likewise.
This adds support for the C++11 "enum class" feature. This is
PR c++/15246.
I chose to use the existing TYPE_DECLARED_CLASS rather than introduce
a new type code. This seemed both simple and clear to me.
I made overloading support for the new enum types strict. This is how
it works in C++; and it didn't seem like an undue burden to keep this,
particularly because enum constants are printed symbolically by gdb.
Built and regtested on x86-64 Fedora 20.
2014-04-14 Tom Tromey <tromey@redhat.com>
PR c++/15246:
* c-exp.y (type_aggregate_p): New function.
(qualified_name, classify_inner_name): Use it.
* c-typeprint.c (c_type_print_base): Handle TYPE_DECLARED_CLASS
and TYPE_TARGET_TYPE of an enum type.
* dwarf2read.c (read_enumeration_type): Set TYPE_DECLARED_CLASS on
an enum type.
(determine_prefix) <case DW_TAG_enumeration_type>: New case;
handle TYPE_DECLARED_CLASS.
* gdbtypes.c (rank_one_type): Handle TYPE_DECLARED_CLASS on enum
types.
* gdbtypes.h (TYPE_DECLARED_CLASS): Update comment.
* valops.c (enum_constant_from_type): New function.
(value_aggregate_elt): Use it.
* cp-namespace.c (cp_lookup_nested_symbol): Handle
TYPE_CODE_ENUM.
2014-04-14 Tom Tromey <tromey@redhat.com>
* gdb.cp/classes.exp (test_enums): Handle underlying type.
* gdb.dwarf2/enum-type.exp: Add test for enum with underlying
type.
* gdb.cp/enum-class.exp: New file.
* gdb.cp/enum-class.cc: New file.
Doug Evans
Jan Kratochvil
Sandra Loosemore
Doug Evans
Pedro Alves
Kevin Buettner
Yao Qi
Pierre-Marie de Rodat
Andy Wingo
Keith Seitz
Mark Wielaard
Joel Brobecker
Maciej W. Rozycki
Simon Marchi
Yao Qi
Kwok Cheung Yeung
Tom Tromey