On Thu, 24 Feb 2011 20:32:51 +0100, Mathew Yeates wrote:
> Okay. I'll bite. Why is this not yet merged in FSF GDB?
That is why archer-jankratochvil-vla is not merged.
I have other bugs and other branches much easier to merge and they are also
not merged. While I understand it is better for all the sides to merge them
these branches currently live in Fedora (and Archer) and if anyone needs the
functionality it is Freely available so I find other serious bugs as a more
urgent problem myself.
Specifically from http://sourceware.org/gdb/wiki/ArcherBranchManagement:
archer-jankratochvil-ifunc: This should get merged soon / these days, I hope
still for gdb-7.3.
archer-jankratochvil-watchpoint3: Upon Pedro's reply
http://sourceware.org/ml/gdb-patches/2010-12/msg00348.htmlhttp://sourceware.org/ml/gdb-patches/2011-01/msg00561.html
I find it now waiting on some merge of linux-nat and gdbserver code which
seems to be continually being worked on by Yao Qi. As I have other work to
do I find it OK to just delay the merge after it.
There are other patches which are very small compared to VLA and which I would
also like to also merge, which suggest me they could be merged before VLA.
Some of them fix linux-nat which should be soon superseded by some form of
remote stub (gdbserver or ugdb or etc.). Which makes them a bit useless after
the switch but currently gdbserver is not a full replacement for linux-nat. It
is all related to the Yao's merges mentioned above.
[patch 3/4]#3 linux-nat: Do not respawn signals
http://sourceware.org/ml/gdb-patches/2010-09/msg00360.html
[patch] Fix syscall restarts for amd64->i386 biarch
http://sourceware.org/ml/gdb-patches/2009-11/msg00592.html
[patch] Fix hang on the thread leader exit
http://sourceware.org/ml/gdb-patches/2007-07/msg00136.html
SIGSTOP which need first an upstream kernel support discussed now on lkml.
various other
archer-jankratochvil-vla:
The patches exist since Mar 2008, currently I believe most of the code should
be rewritten rather than merged. There was an unsuccessful attempt to merge
it early and I later gave up on its merge and developed it rather maintainable
standalone. Currently it became no longer meaningfully extensible as such
non-integrated add-on patches.
Currently the dynamic types to static types are converted during
check_typedef. I believe check_typedef should be removed. For storing
dynamic variables into convenience variables $foo there should just be stored
all the parts of memory needed to evaluate the dynamic bounds into `struct
value' (that is to support discontiguous value->contents). In early VLA
patchset versions the macros accessing struct main_type evaluated the values
dynamically.
With check_typedef the GDB code is known to sometimes forget to call it.
Moreover with dynamic types sometimes one wants to call it only for a single
"type layer" (and no longer for its TYPE_TARGET_TYPE), in other cases one
wants to call it for the type and all its subtypes.
There were patches for type reference counting / garbage collecting - those
were needed for the check_typedef dynamic->static variant. The types life
cycle management should not be needed for VLAs with dynamic check_typedef.
As with VLA even TYPE_HIGH_BOUND and other fields of main_type get runtime
modified no longer makes any distinction the struct type vs. struct main_type.
Therefore they should be merged. struct type was separate so that it could be
modified as there was a limited number of its variants and so it does not
matter they can never be freed. With proper life cycle managemement there can
be single struct type/main_type.
struct value needs to be simplified. At least for lval_memory the fields like
OFFSET, ENCLOSING_TYPE, EMBEDDED_OFFSET and POINTED_TO_OFFSET cannot be used
as the memory accessed by the type is no longer contiguous anyway (value
address is a pointer to the descriptor where are contained the type's
boundaries and also pointer to the real data).
There should be provided some sharing of value->contents to make the code for
dereferencing each dimension simple and bug-free. Fetching of the
discontiguous content can be made more by virtual methods with in-GDB cache,
where record_latest_value will fetch everything.
I wrote it just off the top of my head now without any patches but sure some
comments are welcome.
Thanks,
Jan