I encountered some strange errors when I added my own IPC messages in xxx_messages.h like:
IPC_ENUM_TRAITS(xxx)
IPC_MESSAGE_CONTROL1(xxxx, std::string)
the first encountered compile error like:
undefined "IPC_MESSAGE_START"
fix solution:
#include "ipc/ipc_message_start.h" // define the message start XXXMsgStart here
#define IPC_MESSAGE_START XXXMsgStart
the second encoutered compile error again:
undefined reference to 'IPC::ParamTraits<xxx>::Read(IPC::Message const*, base::PickleIterator*, xxx*)'
fix solution:
touch
xxx_message_generator.cc file for a component xxx would contain
// the following code:
// Get basic type definitions.
#define IPC_MESSAGE_IMPL
#include "path/to/YYY_message_generator.h"
// Generate constructors.
#include "ipc/struct_constructor_macros.h"
#include "path/to/YYY_message_generator.h"
// Generate destructors.
#include "ipc/struct_destructor_macros.h"
#include "path/to/YYY_message_generator.h"
// Generate param traits write methods.
#include "ipc/param_traits_write_macros.h"
namespace IPC {
#include "path/to/YYY_message_generator.h"
} // namespace IPC
// Generate param traits read methods.
#include "ipc/param_traits_read_macros.h"
namespace IPC {
#include "path/to/YYY_message_generator.h"
} // namespace IPC
// Generate param traits log methods.
#include "ipc/param_traits_log_macros.h"
namespace IPC {
#include "path/to/YYY_message_generator.h"
} // namespace IPC
Refer solution from
ipc/ipc_message_macros.h
// Defining IPC Messages
//
// Your IPC messages will be defined by macros inside of an XXX_messages.h
// header file. Most of the time, the system can automatically generate all
// of messaging mechanism from these definitions, but sometimes some manual
// coding is required. In these cases, you will also have an XXX_messages.cc
// implementation file as well.
//
// The senders of your messages will include your XXX_messages.h file to
// get the full set of definitions they need to send your messages.
//
// Each XXX_messages.h file must be registered with the IPC system. This
// requires adding two things:
// - An XXXMsgStart value to the IPCMessageStart enum in ipc_message_start.h
// - An inclusion of XXX_messages.h file in a message generator .h file
//
// The XXXMsgStart value is an enumeration that ensures uniqueness for
// each different message file. Later, you will use this inside your
// XXX_messages.h file before invoking message declaration macros:
// #define IPC_MESSAGE_START XXXMsgStart
// ( ... your macro invocations go here ... )
//
// Message Generator Files
//
// A message generator .h header file pulls in all other message-declaring
// headers for a given component. It is included by a message generator
// .cc file, which is where all the generated code will wind up. Typically,
// you will use an existing generator (e.g. common_message_generator.cc
// in /chrome/common), but there are circumstances where you may add a
// new one.
//
// In the rare circumstances where you can't re-use an existing file,
// your YYY_message_generator.cc file for a component YYY would contain
// the following code:
// // Get basic type definitions.
// #define IPC_MESSAGE_IMPL
// #include "path/to/YYY_message_generator.h"
// // Generate constructors.
// #include "ipc/struct_constructor_macros.h"
// #include "path/to/YYY_message_generator.h"
// // Generate destructors.
// #include "ipc/struct_destructor_macros.h"
// #include "path/to/YYY_message_generator.h"
// // Generate param traits write methods.
// #include "ipc/param_traits_write_macros.h"
// namespace IPC {
// #include "path/to/YYY_message_generator.h"
// } // namespace IPC
// // Generate param traits read methods.
// #include "ipc/param_traits_read_macros.h"
// namespace IPC {
// #include "path/to/YYY_message_generator.h"
// } // namespace IPC
// // Generate param traits log methods.
// #include "ipc/param_traits_log_macros.h"
// namespace IPC {
// #include "path/to/YYY_message_generator.h"
// } // namespace IPC
//
// In cases where manual generation is required, in your XXX_messages.cc
// file, put the following after all the includes for param types:
// #define IPC_MESSAGE_IMPL
// #include "XXX_messages.h"
// (... implementation of traits not auto-generated ...)
//
// Multiple Inclusion
//
// The XXX_messages.h file will be multiply-included by the
// YYY_message_generator.cc file, so your XXX_messages file can't be
// guarded in the usual manner. Ideally, there will be no need for any
// inclusion guard, since the XXX_messages.h file should consist solely
// of inclusions of other headers (which are self-guarding) and IPC
// macros (which are multiply evaluating).
//
// Note that #pragma once cannot be used here; doing so would mark the whole
// file as being singly-included. Since your XXX_messages.h file is only
// partially-guarded, care must be taken to ensure that it is only included
// by other .cc files (and the YYY_message_generator.h file). Including an
// XXX_messages.h file in some other .h file may result in duplicate
// declarations and a compilation failure.
//
// Type Declarations
//
// It is generally a bad idea to have type definitions in a XXX_messages.h
// file; most likely the typedef will then be used in the message, as opposed
// to the struct itself. Later, an IPC message dispatcher will need to call
// a function taking that type, and that function is declared in some other
// header. Thus, in order to get the type definition, the other header
// would have to include the XXX_messages.h file, violating the rule above
// about not including XXX_messages.h file in other .h files.
//
// One approach here is to move these type definitions to another (guarded)
// .h file and include this second .h in your XXX_messages.h file. This
// is still less than ideal, because the dispatched function would have to
// redeclare the typedef or include this second header. This may be
// reasonable in a few cases.
//
// Failing all of the above, then you will want to bracket the smallest
// possible section of your XXX_messages.h file containing these types
// with an include guard macro. Be aware that providing an incomplete
// class type declaration to avoid pulling in a long chain of headers is
// acceptable when your XXX_messages.h header is being included by the
// message sending caller's code, but not when the YYY_message_generator.c
// is building the messages. In addition, due to the multiple inclusion
// restriction, these type ought to be guarded. Follow a convention like:
// #ifndef SOME_GUARD_MACRO
// #define SOME_GUARD_MACRO
// class some_class; // One incomplete class declaration
// class_some_other_class; // Another incomplete class declaration
// #endif // SOME_GUARD_MACRO
// #ifdef IPC_MESSAGE_IMPL
// #include "path/to/some_class.h" // Full class declaration
// #include "path/to/some_other_class.h" // Full class declaration
// #endif // IPC_MESSAGE_IMPL
// (.. IPC macros using some_class and some_other_class ...)
//
// Macro Invocations
//
// You will use IPC message macro invocations for three things:
// - New struct definitions for IPC
// - Registering existing struct and enum definitions with IPC
// - Defining the messages themselves
//
// New structs are defined with IPC_STRUCT_BEGIN(), IPC_STRUCT_MEMBER(),
// IPC_STRUCT_END() family of macros. These cause the XXX_messages.h
// to proclaim equivalent struct declarations for use by callers, as well
// as later registering the type with the message generation. Note that
// IPC_STRUCT_MEMBER() is only permitted inside matching calls to
// IPC_STRUCT_BEGIN() / IPC_STRUCT_END(). There is also an
// IPC_STRUCT_BEGIN_WITH_PARENT(), which behaves like IPC_STRUCT_BEGIN(),
// but also accommodates structs that inherit from other structs.
//
// Externally-defined structs are registered with IPC_STRUCT_TRAITS_BEGIN(),
// IPC_STRUCT_TRAITS_MEMBER(), and IPC_STRUCT_TRAITS_END() macros. These
// cause registration of the types with message generation only.
// There's also IPC_STRUCT_TRAITS_PARENT, which is used to register a parent
// class (whose own traits are already defined). Note that
// IPC_STRUCT_TRAITS_MEMBER() and IPC_STRUCT_TRAITS_PARENT are only permitted
// inside matching calls to IPC_STRUCT_TRAITS_BEGIN() /
// IPC_STRUCT_TRAITS_END().
//
// Enum types are registered with a single IPC_ENUM_TRAITS_VALIDATE() macro.
// There is no need to enumerate each value to the IPC mechanism. Instead,
// pass an expression in terms of the parameter |value| to provide
// range-checking. For convenience, the IPC_ENUM_TRAITS() is provided which
// performs no checking, passing everything including out-of-range values.
// Its use is discouraged. The IPC_ENUM_TRAITS_MAX_VALUE() macro can be used
// for the typical case where the enum must be in the range 0..maxvalue
// inclusive. The IPC_ENUM_TRAITS_MIN_MAX_VALUE() macro can be used for the
// less typical case where the enum must be in the range minvalue..maxvalue
// inclusive.
//
// Do not place semicolons following these IPC_ macro invocations. There
// is no reason to expect that their expansion corresponds one-to-one with
// C++ statements.
//
// Once the types have been declared / registered, message definitions follow.
// "Sync" messages are just synchronous calls, the Send() call doesn't return
// until a reply comes back. To declare a sync message, use the IPC_SYNC_
// macros. The numbers at the end show how many input/output parameters there
// are (i.e. 1_2 is 1 in, 2 out). Input parameters are first, followed by
// output parameters. The caller uses Send([route id, ], in1, &out1, &out2).
// The receiver's handler function will be
// void OnSyncMessageName(const type1& in1, type2* out1, type3* out2)
//
// A caller can also send a synchronous message, while the receiver can respond
// at a later time. This is transparent from the sender's side. The receiver
// needs to use a different handler that takes in a IPC::Message* as the output
// type, stash the message, and when it has the data it can Send the message.
//
// Use the IPC_MESSAGE_HANDLER_DELAY_REPLY macro instead of IPC_MESSAGE_HANDLER
// IPC_MESSAGE_HANDLER_DELAY_REPLY(ViewHostMsg_SyncMessageName,
// OnSyncMessageName)
//
// The handler function will look like:
// void OnSyncMessageName(const type1& in1, IPC::Message* reply_msg);
//
// Receiver stashes the IPC::Message* pointer, and when it's ready, it does:
// ViewHostMsg_SyncMessageName::WriteReplyParams(reply_msg, out1, out2);
// Send(reply_msg);
// Files that want to export their ipc messages should do
// #undef IPC_MESSAGE_EXPORT
// #define IPC_MESSAGE_EXPORT VISIBILITY_MACRO
// after including this header, but before using any of the macros below.
// (This needs to be before the include guard.)
❤️ Support This Blog
If this post helped you, you can support my writing with a small donation.
Thank you for reading.
Comments
Post a Comment