This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
[RFC] read_tag_string_type is broken
- From: Carlos Eduardo Seo <cseo at linux dot vnet dot ibm dot com>
- To: GDB Mailing List <gdb at sourceware dot org>
- Date: Tue, 30 Oct 2007 19:19:54 -0200
- Subject: [RFC] read_tag_string_type is broken
- Openpgp: id=8BFFA900
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all
Discussing with Ulrich Weigand, we found out that
dwarf2read.c:read_tag_string_type is broken because it is considering
DW_AT_string_length to be a scalar value, not a location description.
This impacts directly dealing with Fortran strings.
We also agreed that this is a situation not covered by any set of
routines so far. I'm pasting here Ulrich's comments:
"It seems that this is a fundamentally new situation that is not covered
by the existing set of routines. We would need to separate the two
phases: the actual evaluation of the value needs to be performed at run
time (outside of the dwarf handler routines); during symbol reading, we
only need to save enough statically-available information to allow that
later processing to take place.
Note that the existing dwarf2loc.c logic *does* exactly that -- but it
supports only symbol addresses at this point. The static part of the
symbol reader marks the symbol as "computed" and remembers the necessary
data (see dwarf2_symbol_mark_computed); at some later time the address
can be evaluated in the context of a frame by calling the SYMBOL_OPS
callbacks that were installed at the time.
We'd need to establish a similar mechanism for the *size* of
dynamically-sized Fortran variables ..."
So, what are your thoughts about this?
Thanks and regards,
- --
Carlos Eduardo Seo
Software Engineer
IBM Linux Technology Center
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHJ5/6qvq7Aov/qQARAswHAJ49/AK+hKk57BIVYGDNnWwtI4XUbgCfbm2K
F1EEMY6Re4+pZv30xltbANg=
=W4sH
-----END PGP SIGNATURE-----