On 2018-03-27 15:53, Weimin Pan wrote:
On 3/26/2018 8:28 PM, Simon Marchi wrote:
On 2018-03-26 17:54, Weimin Pan wrote:
@@ -658,15 +659,14 @@ cp_print_static_field (struct type *type,
addr = value_address (val);
obstack_grow (&dont_print_statmem_obstack, (char *) &addr,
sizeof (CORE_ADDR));
- type = check_typedef (type);
- cp_print_value_fields (type, value_enclosing_type (val),
+ cp_print_value_fields (real_type, value_enclosing_type (val),
As discussed previously, here we should pass the original type.
Hi Simon,
OK, just made the change to pass the original type to
cp_print_value_fields()
which in turn calls check_typedef() to get the real type.
Btw, if you now have push access to the git repo, you should add
yourself in the "Write After Approval" section of the
gdb/MAINTAINERS file. This will help you make sure everything is
set up correctly. Don't forget to include a ChangeLog entry for it
and post the patch on the mailing list afterwards (mentioning that
you have pushed it), you can inspire yourself from how people have
done it in the past.
Is there any document or instructions that I can access to understand
the whole process better?
I am not sure there is such a document, but there isn't that much to
the process. We should probably have a little something on the wiki
though, if there isn't already.
To setup your git repo, see here, in the section "Read-write git":
https://www.gnu.org/software/gdb/current/
The important part is using the ssh:// address. After that, it's like
any other git repo. It will use the public key you provided while
registering for your account. In my local repo, I added it as a
different remote with a special name (other than origin) to help
prevent pushing things accidentally. So, for example:
$ git remote add upstream ssh://sourceware.org/git/binutils-gdb.git
You can then check that your access work by doing
$ git fetch upstream
Then:
1. While on the master branch, make sure you only have the patch (or
patches) you intend to push applied on top of upstream/master.
2. Make sure you inserted the ChangeLog entries in the actual
ChangeLog files and amended your commit
3. Push with "git push upstream master:master"
4. Notify the mailing list that you have pushed the patch.
For the patch adding yourself as a write-after-approval maintainer,
you can see how Pedro did it recently:
The commit:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=7eb2418fa4641c60f6713986de7d3a50fd7a22c0
The mailing list message:
https://sourceware.org/ml/gdb-patches/2018-03/msg00391.html