public inbox for gdb-testers@sourceware.org help / color / mirror / Atom feed
From: sergiodj+buildbot@sergiodj.net To: gdb-testers@sourceware.org Subject: [binutils-gdb] Make sect_offset and cu_offset strong typedefs instead of structs Date: Tue, 04 Apr 2017 21:06:00 -0000 [thread overview] Message-ID: <9c5417255690af00751c7d506172459afe856894@gdb-build> (raw) *** TEST RESULTS FOR COMMIT 9c5417255690af00751c7d506172459afe856894 *** Author: Pedro Alves <palves@redhat.com> Branch: master Commit: 9c5417255690af00751c7d506172459afe856894 Make sect_offset and cu_offset strong typedefs instead of structs A while ago, back when GDB was a C program, the sect_offset and cu_offset types were made structs in order to prevent incorrect mixing of those offsets. Now that we require C++11, we can make them integers again, while keeping the safety, by exploiting "enum class". We can add a bit more safety, even, by defining operators that the types _should_ support, helping making the suspicious uses stand out more. Getting at the underlying type is done with the new to_underlying function added by the previous patch, which also helps better spot where do we need to step out of the safety net. Mostly, that's around parsing the DWARF, and when we print the offset for complaint/debug purposes. But there are other occasional uses. Since we have to define the sect_offset/cu_offset types in a header anyway, I went ahead and generalized/library-fied the idea of "offset" types, making it trivial to add more such types if we find a use. See common/offset-type.h and the DEFINE_OFFSET_TYPE macro. I needed a couple generaly-useful preprocessor bits (e.g., yet another CONCAT implementation), so I started a new common/preprocessor.h file. I included units tests covering the "offset" types API. These are mostly compile-time tests, using SFINAE to check that expressions that shouldn't compile (e.g., comparing unrelated offset types) really are invalid and would fail to compile. This same idea appeared in my pending enum-flags revamp from a few months ago (though this version is a bit further modernized compared to what I had posted), and I plan on reusing the "check valid expression" bits added here in that series, so I went ahead and defined the CHECK_VALID_EXPR macro in its own header -- common/valid-expr.h. I think that's nicer regardless. I was borderline between calling the new types "offset" types, or "index" types, BTW. I stuck with "offset" simply because that's what we're already calling them, mostly. gdb/ChangeLog: 2017-04-04 Pedro Alves <palves@redhat.com> * Makefile.in (SUBDIR_UNITTESTS_SRCS): Add unittests/offset-type-selftests.c. (SUBDIR_UNITTESTS_OBS): Add offset-type-selftests.o. * common/offset-type.h: New file. * common/preprocessor.h: New file. * common/traits.h: New file. * common/valid-expr.h: New file. * dwarf2expr.c: Include "common/underlying.h". Adjust to use sect_offset and cu_offset strong typedefs throughout. * dwarf2expr.h: Adjust to use sect_offset and cu_offset strong typedefs throughout. * dwarf2loc.c: Include "common/underlying.h". Adjust to use sect_offset and cu_offset strong typedefs throughout. * dwarf2read.c: Adjust to use sect_offset and cu_offset strong typedefs throughout. * gdbtypes.h: Include "common/offset-type.h". (cu_offset): Now an offset type (strong typedef) instead of a struct. (sect_offset): Likewise. (union call_site_parameter_u): Rename "param_offset" field to "param_cu_off". * unittests/offset-type-selftests.c: New file.
next reply other threads:[~2017-04-04 21:06 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-04 21:06 sergiodj+buildbot [this message] 2017-04-04 21:06 ` Failures on Fedora-s390x-m64, branch master sergiodj+buildbot 2017-04-04 22:07 ` *** COMPILATION FAILED *** Failures on Ubuntu-AArch64-native-gdbserver-m64, branch master *** BREAKAGE *** sergiodj+buildbot 2017-04-04 22:16 ` *** COMPILATION FAILED *** Failures on Ubuntu-AArch64-m64, " sergiodj+buildbot 2017-04-04 23:54 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-m64, " sergiodj+buildbot 2017-04-04 23:57 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot 2017-04-05 0:00 ` *** COMPILATION FAILED *** Failures on Ubuntu-AArch32-native-gdbserver-m32, " sergiodj+buildbot 2017-04-05 0:01 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot 2017-04-05 0:06 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-cc-with-index, " sergiodj+buildbot 2017-04-05 0:10 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-m32, " sergiodj+buildbot 2017-04-05 0:10 ` *** COMPILATION FAILED *** Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot 2017-04-05 0:14 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-native-extended-gdbserver-m32, " sergiodj+buildbot 2017-04-05 0:16 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot 2017-04-05 0:20 ` *** COMPILATION FAILED *** Failures on Ubuntu-AArch32-m32, " sergiodj+buildbot 2017-04-05 0:27 ` Failures on Fedora-i686, branch master sergiodj+buildbot 2017-07-25 11:16 ` Failures on Fedora-ppc64le-native-extended-gdbserver-m64, " sergiodj+buildbot 2017-07-25 13:04 ` Failures on Fedora-ppc64le-m64, " sergiodj+buildbot 2017-07-25 22:57 ` Failures on Fedora-ppc64le-native-gdbserver-m64, " sergiodj+buildbot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=9c5417255690af00751c7d506172459afe856894@gdb-build \ --to=sergiodj+buildbot@sergiodj.net \ --cc=gdb-testers@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).