Code-gen bugs compile Boost Regex with gcc/XCode Obj-C++ (3.1).
Code-gen bugs compile Boost Regex with gcc/XCode Obj-C++ (3.1).
- Subject: Code-gen bugs compile Boost Regex with gcc/XCode Obj-C++ (3.1).
- From: Tom Titchener <email@hidden>
- Date: Fri, 26 Sep 2008 17:06:05 -0400
Compiling with -Os caused problems with offsets from "this" to member
data for different routines in the the parse_extended routine vs. the
parse_literal. If anybody knows a way to compile boost regex with
objective-c++ then I'd like to hear about it, please. Otherwise, read
below to see what our experience and work-around.
Looking at the member offsets in the assembly and in the debugger for
parent class basic_regex_creator you can see the faulty code (in
parse_literal) adds a four-byte pad before 64-bit member
m_bad_repeats. There's no pad in the caller routine parse_extended,
so when parse_literal goes to use member data like m_position, located
in higher memory than m_bad_repeats, it finds and tries to dereference
invalid pointer values like 1 and 0. Here's what the call stack
looked like:
#0 0x0001456c in boost::re_detail::basic_regex_parser<char,
boost::regex_traits<char, boost::cpp_regex_traits<char> >
>::parse_literal at basic_regex_parser.hpp:339
#1 0x000a451e in boost::re_detail::basic_regex_parser<char,
boost::regex_traits<char, boost::cpp_regex_traits<char> >
>::parse_extended at basic_regex_parser.hpp:320
#2 0x000a151a in boost::re_detail::basic_regex_parser<char,
boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse_all
at basic_regex_parser.hpp:180
#3 0x000a151a in boost::re_detail::basic_regex_parser<char,
boost::regex_traits<char, boost::cpp_regex_traits<char> >
>::parse_open_paren at basic_regex_parser.hpp:389
#4 0x000a43ac in boost::re_detail::basic_regex_parser<char,
boost::regex_traits<char, boost::cpp_regex_traits<char> >
>::parse_extended at basic_regex_parser.hpp:250
#5 0x000a33fd in boost::re_detail::basic_regex_parser<char,
boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse_all
at basic_regex_parser.hpp:180
#6 0x000a33fd in boost::re_detail::basic_regex_parser<char,
boost::regex_traits<char, boost::cpp_regex_traits<char> > >::parse at
basic_regex_parser.hpp:132
#7 0x000a34d1 in boost::re_detail::basic_regex_implementation<char,
boost::regex_traits<char, boost::cpp_regex_traits<char> > >::assign at
basic_regex.hpp:103
#8 0x0009b3fc in boost::basic_regex<char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > >::do_assign at basic_regex.hpp:531
#9 0x00011913 in boost::basic_regex<char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > >::assign at basic_regex.hpp:262
#10 0x0001a575 in boost::basic_regex<char, boost::regex_traits<char,
boost::cpp_regex_traits<char> > >::basic_regex at basic_regex.hpp:216
Here's the code that generated the access violation. Member
m_position was set to value 1, so dereferencing it didn't work very
well:
if(
((this->flags()
& (regbase::main_option_type|regbase::mod_x|
regbase::no_perl_ex))
!= regbase::mod_x)
|| !this->m_traits.isctype(*m_position, this->m_mask_space))
this->append_literal(*m_position);
Compiling with -O2, like in the boost Mac makefile "solved" this
problem, but ran caused the regex code to throw error_space after
failing this comparison at line 175 of perl_matcher_non_recursive.hpp
because max_state_count was zero, which looks like a similar sort of
problem:
if(state_count > max_state_count)
raise_error(traits_inst, regex_constants::error_space);
The work-around was to create a simple wrapper API that called the
Boost regex code and export it from a context compiled strictly with c+
+ and not objective-c++. Even then we ran into some confusion due to
a second code path in a different c++ file that happened to #include
<boost/regex.hpp> and compile some regex code, even though the call
paths never traversed this branch. The active code path went through
the new API, but we still got the same code-generation problems,
probably because the names the objective-c++ code created for the
inactive branch superseded the names for the c++ code created as part
of the library compile from the c++ context. Once we conditionally-
compiled out the inactive path so the objective-c++ compiler (well,
"the" compiler with its objective-c++ hat), then we were finally able
to call into boost regex, even with -O2 optimization.
Part of what's confusing is all this code works fine built debug. But
if you want release mode code that reaches from objective-c++ into
boost regex, then then you'll need independent compile contexts:
objective-c++ for objective c++, c++ for boost regex (at least with
XCode 3.1).
Unless somebody else has a way to make this work. Otherwise we're
facing some refactoring work down the road....
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden