I'm looking at this drivers/net/wireless/ti/wl18xx driver module.
The traditional module_init() is not in the source code. Yet the trace dump shows a wl18xx_driver_init() is called, though that function again is not in the source code.
I can see the wl18xx_driver_init() in the objdump of main.o in that driver directory.
Is it that in late versions of kernels those functions/macros are automatically generated? How is that done?
wl18xx_driver_init is generated here with the expansion of module_platform_driver(wl18xx_driver) macro.
It expands roughly to smth like:
static int __init wl18xx_driver_init(void) {
return platform_driver_register(&(wl18xx_driver));
}
static initcall_t __initcall_wl18xx_driver_init6 __used __attribute__((__section__(".initcall" "6" ".init"))) = wl18xx_driver_init;
static void __exit wl18xx_driver_exit(void) {
platform_driver_unregister(&(wl18xx_driver));
}
static exitcall_t __exitcall_wl18xx_driver_exit __exit_call = wl18xx_driver_exit;
See module_platform_driver macro and module driver macro.
# It would be best to post some source code or links the next time, it would make it easier. Including kernel version would be also a good idea.
Related
I am following the foo example given in the wireshark documentation.
I am able to build the foo code plugin. I am using wireshark 3.0.1 version. In the workroot folder, I have updated the target - PLUGIN_SRC_DIRS - plugins/epan/foo just before gryphon.
I can see that my code builds because I got some compilation error which I was able to fix it.
My foo code lives inside the plugins/epan folder.
I am running custom wireshark - sudo ./run/wireshark
There is a surprise here that I can't see even gryphon protocol field in the running wireshark. So in order to test this, I am typing foo or gryphon in that display filter and it turns red and it say foo is neither a protocol nor a protocol field. I am using Ubuntu 16.04 LTS to build it. The build goes fine.
Here is packet-foo.c
#include "config.h"
#include <epan/packet.h>
#include "packet-foo.h"
static int proto_foo = -1;
static int dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree _U_, void *data _U_);
void
proto_register_foo(void)
{
proto_foo = proto_register_protocol (
"FOO Protocol", /* name */
"FOO", /* short name */
"foo" /* abbrev */
);
}
void
proto_reg_handoff_foo(void)
{
static dissector_handle_t foo_handle;
foo_handle = create_dissector_handle(dissect_foo, proto_foo);
dissector_add_uint("udp.port", FOO_PORT, foo_handle);
}
static int
dissect_foo(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree _U_, void *data _U_)
{
col_set_str(pinfo->cinfo, COL_PROTOCOL, "FOO");
/* Clear out stuff in the info column */
col_clear(pinfo->cinfo,COL_INFO);
return tvb_captured_length(tvb);
}
Here is the packet-foo.h
#define FOO_PORT 1234
The CMakeLists.txt is here, this is actually a copy of gryphon.
So, I am wondering if gryphon wasn't recognised that means foo won't be recognised too. So, this file might be a source of problem.
include(WiresharkPlugin)
# Plugin name and version info (major minor micro extra)
set_module_info(foo 0 0 4 0)
set(DISSECTOR_SRC
packet-foo.c
)
set(PLUGIN_FILES
plugin.c
${DISSECTOR_SRC}
)
set_source_files_properties(
${PLUGIN_FILES}
PROPERTIES
COMPILE_FLAGS "${WERROR_COMMON_FLAGS}"
)
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
register_plugin_files(plugin.c
plugin
${DISSECTOR_SRC}
)
add_plugin_library(foo epan)
target_link_libraries(foo epan)
install_plugin(foo epan)
file(GLOB DISSECTOR_HEADERS RELATIVE "${CMAKE_CURRENT_SOURCE_DIR}" "*.h")
CHECKAPI(
NAME
foo
SWITCHES
-g abort -g termoutput -build
SOURCES
${DISSECTOR_SRC}
${DISSECTOR_HEADERS}
)
Merely changing the plugin isn't sufficient.
You need to modify the top make file so that foo is actually installed.
vim CMakeListsCustom.txt.example
Firstly, uncomment - line number 16
plugins/epan/foo
Since your foo lives inside plugins/epan/foo
Now, rename this example to
mv CMakeListsCustom.txt.example CMakeListsCustom.txt
vim CMakeLists.txt
Insert a line number around 1408-
plugins/epan/foo
After that, do make
and then sudo make install
Here is the working copy -
https://github.com/joshis1/WiresharkDissectorFoo
My question is about a crypto++ constructor and why it is in the state of being "implicitly deleted" even though it follows the examples provided in the documentation.
I am trying to go off of the code provided by the example on Crypto++'s documentation to create a digital signature key pair, but I am having trouble calling the constructor for AutoSeededRandomPool objects.
Here is the command I am calling to the terminal:
g++ -I /usr/local/include/ -l cryptopp -std=c++11 -c -o build/account.o src/account.cpp
I am getting the following error:
error: call to implicitly-deleted copy constructor of 'CryptoPP::AutoSeededRandomPool',
note: copy constructor of 'AutoSeededRandomPool' is implicitly deleted because base
class 'CryptoPP::RandomPool' has a deleted copy constructor
Additionally, I get this unusual message:
clang: warning: -lcryptopp: 'linker' input unused [-Wunused-command-line-argument]
Here is are the files I use to generate the public/private key pair. They pretty much follow the example:
DSA::PrivateKey create_private_key(AutoSeededRandomPool rng) {
DSA::PrivateKey private_Key;
private_Key.GenerateRandomWithKeySize(rng, 1024);
return private_Key;
}
DSA::PublicKey create_public_key(DSA::PrivateKey private_key, AutoSeededRandomPool rng) {
DSA::PublicKey public_Key;
public_Key.AssignFrom(private_key);
if (!private_key.Validate(rng, 3) || !public_Key.Validate(rng, 3))
{
throw std::runtime_error("DSA key generation failed");
}
return public_Key;
}
I declare and initialize the AutoSeededRandomPool object in a constructor as follows:
account::account() {
balance = 0;
AutoSeededRandomPool rng;
private_key = utils::create_private_key(rng);
public_key = utils::create_public_key(private_key, rng);
}
I have linked in the libraries necessary for this, and I am linking them in when I call g++. Additionally, if anyone knows if there are any more detailed examples of Crypto++ code, those resources would be greatly appreciated.
g++ -I /usr/local/include/ -l cryptopp -std=c++11 -c -o build/account.o src/account.cpp
clang: warning: -lcryptopp: 'linker' input unused
Try:
g++ ... src/account.cpp -c -o build/account.o
Omit -l cryptopp. It is only needed during link.
DSA::PrivateKey create_private_key(AutoSeededRandomPool rng) {
DSA::PrivateKey private_Key;
private_Key.GenerateRandomWithKeySize(rng, 1024);
return private_Key;
}
error: call to implicitly-deleted copy constructor of
'CryptoPP::AutoSeededRandomPool', note: copy constructor of
'AutoSeededRandomPool' is implicitly deleted because base class
'CryptoPP::RandomPool' has a deleted copy constructor
Pass rng by reference:
DSA::PrivateKey create_private_key(AutoSeededRandomPool& rng) {
...
}
Do it in both create_private_key and create_public_key.
The reason is, AutoSeededRandomPool base class is RandomPool, and RandomPool base class is NotCopyable. NotCopyable hides copy and assignment by making them private. I guess that's where the "implicit" part comes from the compiler error.
class RandomPool : public RandomNumberGenerator, public NotCopyable
{
...
}
IF you don't want to pass by reference, then create one locally. There are certain reasons why you want to do this when generating a private key. See Cryptography Engineering: Design Principles and Practical Applications for more details.
DSA::PrivateKey create_private_key() {
AutoSeededRandomPool rng;
DSA::PrivateKey private_Key;
private_Key.GenerateRandomWithKeySize(rng, 1024);
return private_Key;
}
Related, when you link, place -lcryptopp at the end of the command. Something like:
g++ -o myprog -std=c++11 build/account.o build/some-other-object.o -lcryptopp -pthread
Order matters because LD is a single pass linker. Libraries always go at the end. You can work around it with options like -( and --start-group, but its easy to remember to place libraries at the end.
Some more of the C++11 backstory is, when you experience copy constructor implicitly deleted, you usually define one in your class. See, for example, Use of deleted function error.
However, in the case of AutoSeededRandomPool, we don't want them copied for several reasons. The Crypto++ Algorithm class, which is a base class of AutoSeededRandomPool, has a Clone. However, we don't want the generator cloned, either. Again, see Cryptography Engineering: Design Principles and Practical Applications.
When I really should call refresh function manually in module Curses in Ruby? I think that it's unclear in the docs.
Thanks in advance.
The refresh method points out to the external function refresh():
static VALUE
curses_refresh(VALUE obj)
{
curses_stdscr();
refresh();
return Qnil;
}
And you can see the documentation of that refresh() method in the curs_refresh manual:
The refresh and wrefresh routines (or wnoutrefresh and doupdate) must
be called to get actual output to the terminal, as other routines mere‐
ly manipulate data structures. The routine wrefresh copies the named
window to the physical terminal screen, taking into account what is al‐
ready there to do optimizations. The refresh routine is the same, us‐
ing stdscr as the default window. Unless leaveok has been enabled, the
physical cursor of the terminal is left at the location of the cursor
for that window.
In modern Linux you can see the declaration of that function or macros in /usr/include/ncurses.h or /usr/include/curses.h. Example:
extern NCURSES_EXPORT(int) refresh (void); /* generated */
#define refresh() wrefresh(stdscr)
And this is the part of Ruby's curses.c that refers to the header files:
#if defined(HAVE_NCURSES_H)
# include <ncurses.h>
#elif defined(HAVE_NCURSES_CURSES_H)
# include <ncurses/curses.h>
#elif defined(HAVE_CURSES_COLR_CURSES_H)
# ifdef HAVE_STDARG_PROTOTYPES
# include <stdarg.h>
# else
# include <varargs.h>
# endif
# include <curses_colr/curses.h>
#else
# include <curses.h>
...
# endif
#endif
The following program is based on the example in the v8 Getting Started page. I have made three changes to demonstrate a problem I am encountering:
I create an empty array put it into the global context.
The script being run references the zeroth element in the array, which should return undefined.
I run the compiled script twice.
The first run works fine. The second fails: v8 calls V8_Fatal() in Deoptimizer::DoComputeCompiledStubFrame() because descriptor->register_param_count_ == -1.
Am I doing something wrong here? How can I fix it?
Isolate* isolate = Isolate::New();
Isolate::Scope isolate_scope(isolate);
HandleScope handle_scope(isolate);
Local<Context> context = Context::New(isolate);
Context::Scope context_scope(context);
Local<Array> a = Array::New(isolate);
context->Global()->Set(String::NewFromUtf8(isolate, "a"), a);
Local<String> source = String::NewFromUtf8(isolate, "a[0];");
Local<Script> script = Script::Compile(source);
Local<Value> result = script->Run();
Local<Value> result2 = script->Run();
return 0;
NOTES:
This is the entire body of main().
Other fragments of JavaScript code run twice without a problem. Somehow this relates to the out-of-bound array reference, which is perhaps triggering deoptimization.
I do not want to recompile the script from scratch each time because I am typically running these scripts thousands of times, and sometimes millions of times.
I have tried compiling the script as an UnboundScript and then binding it for each execution, but the result is the same.
I have reported this as a v8 issue, but nobody has responded so I'm hoping that the StackOverflow community can help.
I am seeing this on VS2012 Update 4, but I also see it on VS2008, and in both x64 and x86 and in both Debug and Release builds.
OK, found it. The problem is an uninitialized code stub for dictionary loads - your use case triggers this as a failure as the stub isn't initialized through other means, eg compilation.
Below is a patch against v8 trunk revision 22629 that fixes the problem for me, tested on Windows with VS 2010 and Linux with g++ 4.9. Please let me know how you go with this:
Index: src/code-stubs.cc
===================================================================
--- src/code-stubs.cc (revision 22629)
+++ src/code-stubs.cc (working copy)
## -236,6 +236,8 ##
CODE_STUB_LIST(DEF_CASE)
#undef DEF_CASE
case UninitializedMajorKey: return "<UninitializedMajorKey>Stub";
+ case NoCache:
+ return "<NoCache>Stub";
default:
if (!allow_unknown_keys) {
UNREACHABLE();
## -939,6 +941,13 ##
// static
+void KeyedLoadDictionaryElementStub::InstallDescriptors(Isolate* isolate) {
+ KeyedLoadDictionaryElementStub stub(isolate);
+ InstallDescriptor(isolate, &stub);
+}
+
+
+// static
void KeyedLoadGenericElementStub::InstallDescriptors(Isolate* isolate) {
KeyedLoadGenericElementStub stub(isolate);
InstallDescriptor(isolate, &stub);
Index: src/code-stubs.h
===================================================================
--- src/code-stubs.h (revision 22629)
+++ src/code-stubs.h (working copy)
## -1862,6 +1862,8 ##
virtual void InitializeInterfaceDescriptor(
CodeStubInterfaceDescriptor* descriptor) V8_OVERRIDE;
+ static void InstallDescriptors(Isolate* isolate);
+
private:
Major MajorKey() const { return KeyedLoadElement; }
int NotMissMinorKey() const { return DICTIONARY_ELEMENTS; }
Index: src/isolate.cc
===================================================================
--- src/isolate.cc (revision 22629)
+++ src/isolate.cc (working copy)
## -2000,6 +2000,7 ##
NumberToStringStub::InstallDescriptors(this);
StringAddStub::InstallDescriptors(this);
RegExpConstructResultStub::InstallDescriptors(this);
+ KeyedLoadDictionaryElementStub::InstallDescriptors(this);
KeyedLoadGenericElementStub::InstallDescriptors(this);
}
As a workaround if you don't want to compile your own V8 for now, you could execute some code on each Isolate that uses the KeyedLoadDictionaryElementStub directly, prior to running your code --- this should initialize the stub. Something like the following works for me:
Isolate* isolate = Isolate::New();
Isolate::Scope isolate_scope(isolate);
HandleScope handle_scope(isolate);
Local<Context> context = Context::New(isolate);
Context::Scope context_scope(context);
Local<Array> a = Array::New(isolate);
context->Global()->Set(String::NewFromUtf8(isolate, "a"), a);
// Workaround code for initializing KeyedLoadDictionaryElementStub
Local<String> workaround_source = String::NewFromUtf8(isolate, "Math.random()");
Local<Script> workaround_script = Script::Compile(workaround_source);
Local<Value> workaround_value = workaround_script->Run();
// End workaround
Local<String> source = String::NewFromUtf8(isolate, "a[0]");
Local<Script> script = Script::Compile(source);
// ...and so on
When trying to compile a g++ project with the clang compiler, there is a strange error showing up.
Here is the snippet of the source file:
std::set<TTransportNetworkId> l_transportNetworkIds;
SelectionResultContainer l_searchResult = p_repo.rootMoc() / LnAny("LNBTS") / LnAny("LNMME");
BOOST_FOREACH(const SelectionResult & l_lnmmeSR, l_searchResult)
{
const MoLnmme & l_lnmme = l_lnmmeSR;
l_transportNetworkIds.insert(*l_lnmme.transportNwId);
}
The error message is:
conditional expression is ambiguous; 'rvalue_probe<Rrom::DataRep::SelectionResultContainer>' can be converted to 'Rrom::DataRep::SelectionResultContainer' and vice versa
BOOST_FOREACH(const SelectionResult & l_lnmmeSR, l_searchResult)
Conditions are:
The file compiles fine with gcc_4.3.2
clang in version 3.2 throws the above error
Already tried to include the latest boost library which results in the same error
My guess is that clang handles rvalue conditions differently than this gcc version does.
clang is supposed to be a drop-in-replacement for gcc, so how can one get rid of this error without touching the source file?
Are there any options in clang which somehow disables these kind of errors?!
UPDATE:
I could create an example source file, which you can reproduce for yourself:
#include <vector>
#include <boost/foreach.hpp>
class A : public std::vector<int>
{
public:
template <class T>
operator const T &() const;
};
void foo(){
A colA;
int b = 1;
BOOST_FOREACH(b, colA)
{
;
}
}
When compiled with clang 3.2 the above error is raised, with some additional insights to where exactly the error occurs:
error: conditional expression is ambiguous; 'rvalue_probe<A>' can be converted to 'A' and vice versa BOOST_FOREACH(b, colA)
expanded from macro 'BOOST_FOREACH' f (boost::foreach_detail_::auto_any_t BOOST_FOREACH_ID(_foreach_col) = BOOST_FOREACH_CONTAIN(COL))
expanded from macro 'BOOST_FOREACH_CONTAIN' BOOST_FOREACH_EVALUATE(COL)
expanded from macro 'BOOST_FOREACH_EVALUATE' (true ? boost::foreach_detail_::make_probe((COL), BOOST_FOREACH_ID(_foreach_is_rvalue)) : (COL))
This code is compiled without errors with gcc_4.7.2.
Any ideas why the two compilers behave differently?
I found the solution in this document, see http://www.boost.org/doc/libs/1_43_0/boost/foreach.hpp
Snippet:
// Some compilers do not correctly implement the lvalue/rvalue conversion
// rules of the ternary conditional operator.
# if defined(BOOST_FOREACH_NO_RVALUE_DETECTION)
So, when providing a -DBOOST_FOREACH_NO_RVALUE_DETECTION definition option to clang, the error disappears.
Still the question remains whether gcc or clang is right or wrong on this point.