This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 4 PR gdb/16959] gdb hangs in infinite recursion


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

Simon


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]