No source available error in accessing shared library - c++

I have two project in my Eclipse IDE. My OS is Ubuntu. One is application project and another one is shared lib project. I have linked all paths and libs requirement as discussed in the link. But when I debug, I got error as No source available for "0x0". The error happened at iOCR* pOCR = (iOCR*)create(); when I access the shared library object. What is wrong with my linking?
My shared library codes and application codes are attached.
Shared library header file
#ifndef OCR_DLL_H_
#define OCR_DLL_H_
#include <opencv/cv.h>
#include <opencv2/highgui/highgui.hpp>
#include <opencv2/imgproc/imgproc.hpp>
#include <tesseract/baseapi.h>
#include <iostream>
#include "Define.h"
using namespace cv;
namespace VIDEOANALYTICS_PLATFORM {
class iOCR{
public:
virtual ~iOCR(){}
virtual int preProcessing(Mat &img) = 0;
virtual int textExtraction(Mat &img) = 0;
};
class OCR : public iOCR{
public:
OCR(){}
~OCR(){ ; }
int preProcessing(Mat &img);
int textExtraction(Mat &img);
private:
};
}
#endif /* OCR_DLL_H_ */
Shared library cpp
#include "OCR_dll.h"
namespace VIDEOANALYTICS_PLATFORM {
extern "C" iOCR* create_object(){
iOCR *p = new OCR();
return p;
}
extern "C" void destroy_object( iOCR* object )
{
delete object;
}
int OCR::preProcessing(Mat &img){
return SUCCESS;
}
int OCR::textExtraction(Mat &img){
return SUCCESS;
}
}
Application main.cpp
#include <stdio.h>
#include "OCR_dll.h"
#define SUCCESS 0
#define FILE_ERROR 1
#define HTTP_ERROR 2
#define THREAD_ERROR 3
using namespace VIDEOANALYTICS_PLATFORM;
using namespace cv;
void *readImage(void *ptr);
void *postHTTP(void *ptr);
int main(int argc, char *argv[])
{
// on Linux, use "./myclass.so"
void* handle = dlopen("OCR.so", RTLD_LAZY);
iOCR* (*create)();
void (*destroy)(iOCR*);
create = (iOCR* (*)())dlsym(handle, "create_object");
destroy = (void (*)(iOCR*))dlsym(handle, "destroy_object");
iOCR* pOCR = (iOCR*)create();
if(pOCR){
destroy( pOCR );
}//if(pOCR)
dlclose(handle);
return 0;
}
I checked with objdumb and the output is as follow
cdc#cdc-desktop:~/workspace/OCR/Debug$ objdump -TC libOCR.so
libOCR.so: file format elf32-i386
DYNAMIC SYMBOL TABLE:
00000000 DF *UND* 00000000 GLIBC_2.1.3 __cxa_atexit
00000000 w D *UND* 00000000 __gmon_start__
00000000 w D *UND* 00000000 _Jv_RegisterClasses
00000000 DF *UND* 00000000 GLIBCXX_3.4 operator delete(void*)
00000000 DF *UND* 00000000 GLIBCXX_3.4 std::ios_base::Init::Init()
00000000 DF *UND* 00000000 GLIBCXX_3.4 std::ios_base::Init::~Init()
00000000 w D *UND* 00000000 _ITM_deregisterTMCloneTable
00000000 w D *UND* 00000000 _ITM_registerTMCloneTable
00000000 DO *UND* 00000000 CXXABI_1.3 vtable for __cxxabiv1::__class_type_info
00000000 DF *UND* 00000000 CXXABI_1.3 __cxa_pure_virtual
00000000 DF *UND* 00000000 GLIBCXX_3.4 operator new(unsigned int)
00000000 DO *UND* 00000000 CXXABI_1.3 vtable for __cxxabiv1::__si_class_type_info
00000000 w DF *UND* 00000000 GLIBC_2.1.3 __cxa_finalize
00000c95 g DF .text 00000020 Base destroy_object
00000dc4 w DF .text 0000001e Base VIDEOANALYTICS_PLATFORM::OCR::~OCR()
00000de4 g DF .fini 00000000 Base _fini
00000d94 w DF .text 00000030 Base VIDEOANALYTICS_PLATFORM::OCR::~OCR()
00000d94 w DF .text 00000030 Base VIDEOANALYTICS_PLATFORM::OCR::~OCR()
00000d4c w DF .text 0000001e Base VIDEOANALYTICS_PLATFORM::iOCR::~iOCR()
00000cc0 g DF .text 0000000a Base VIDEOANALYTICS_PLATFORM::OCR::textExtraction(cv::Mat&)
00000d78 w DF .text 0000001c Base VIDEOANALYTICS_PLATFORM::OCR::OCR()
00000aec g DF .init 00000000 Base _init
00000e40 w DO .rodata 00000020 Base typeinfo name for VIDEOANALYTICS_PLATFORM::OCR
00000d78 w DF .text 0000001c Base VIDEOANALYTICS_PLATFORM::OCR::OCR()
00003018 g D .bss 00000000 Base __bss_start
00000d26 w DF .text 00000025 Base VIDEOANALYTICS_PLATFORM::iOCR::~iOCR()
00000d6a w DF .text 0000000e Base VIDEOANALYTICS_PLATFORM::iOCR::iOCR()
00000d26 w DF .text 00000025 Base VIDEOANALYTICS_PLATFORM::iOCR::~iOCR()
0000301c g D .bss 00000000 Base _end
00000e18 w DO .rodata 00000018 Base vtable for VIDEOANALYTICS_PLATFORM::iOCR
00000e30 w DO .rodata 0000000c Base typeinfo for VIDEOANALYTICS_PLATFORM::OCR
00000d6a w DF .text 0000000e Base VIDEOANALYTICS_PLATFORM::iOCR::iOCR()
00000cb6 g DF .text 0000000a Base VIDEOANALYTICS_PLATFORM::OCR::preProcessing(cv::Mat&)
00000e00 w DO .rodata 00000018 Base vtable for VIDEOANALYTICS_PLATFORM::OCR
00003018 g D .data 00000000 Base _edata
00000e84 w DO .rodata 00000008 Base typeinfo for VIDEOANALYTICS_PLATFORM::iOCR
00000c6c g DF .text 00000029 Base create_object
00000e60 w DO .rodata 00000021 Base typeinfo name for VIDEOANALYTICS_PLATFORM::iOCR

There are two possible problems that I see.
The first is, and for this I'm only guessing, that you put the shared object in the same path as the executable loading the shared object, and thought that dlopen would look in the process current directory. The manual page says that
If filename contains a slash ("/"), then it is interpreted as a (relative or absolute) pathname. Otherwise, the dynamic linker searches for the library as follows...
And then it lists where the function will look for the shared object, which includes e.g. /usr/lib.
If the library is not in the path that dlopen looks in, then the shared object will not be found.
The simple solution to this first problem is to use an absolute or relative path instead, e.g.
dlopen("./OCR.so", RTLD_LAZY);
This will look in the process current directory (which might not be the same directory as where the executable program is).
The second problem is that you named the shared object libOCR.so, and you ask dlopen to look for OCR.so. The dlopen does not automatically add the lib prefix when looking for files, you need to provide the actual file-name of the shared object.

Related

How to redefine symbol of object file from the arm-none-eabi compile with -flot flag?

I want redefine malloc symbol to own_malloc, so that I can know memory alloc details and print alloc-size.But I found it don't work when I excuting order:
arm-none-eabi-objcopy --redefine-sym malloc=own_malloc test.o
the test source:
#include <stdlib.h>
extern "C" void test();
void test(){
void* ptr = ::malloc(16);
free(ptr);
}
I exec objdump to look the symbol table
arm-none-eabi-objdump -t test.o
I fount there was not malloc/free symbol in symbols table.
SYMBOL TABLE:
00000000 l df *ABS* 00000000 test.cxx
00000000 l d .text 00000000 .text
00000000 l d .data 00000000 .data
00000000 l d .bss 00000000 .bss
00000000 l d .gnu.debuglto_.debug_info 00000000 .gnu.debuglto_.debug_info
00000000 l d .gnu.debuglto_.debug_abbrev 00000000 .gnu.debuglto_.debug_abbrev
00000000 l d .gnu.debuglto_.debug_line 00000000 .gnu.debuglto_.debug_line
00000000 l d .gnu.debuglto_.debug_str 00000000 .gnu.debuglto_.debug_str
00000000 l d .gnu.lto_.profile.7c13183f5b427e41 00000000 .gnu.lto_.profile.7c13183f5b427e41
00000000 l d .gnu.lto_.icf.7c13183f5b427e41 00000000 .gnu.lto_.icf.7c13183f5b427e41
00000000 l d .gnu.lto_.ipa_sra.7c13183f5b427e41 00000000 .gnu.lto_.ipa_sra.7c13183f5b427e41
00000000 l d .gnu.lto_.inline.7c13183f5b427e41 00000000 .gnu.lto_.inline.7c13183f5b427e41
00000000 l d .gnu.lto_.jmpfuncs.7c13183f5b427e41 00000000 .gnu.lto_.jmpfuncs.7c13183f5b427e41
00000000 l d .gnu.lto_.pureconst.7c13183f5b427e41 00000000 .gnu.lto_.pureconst.7c13183f5b427e41
00000000 l d .gnu.lto_.lto.7c13183f5b427e41 00000000 .gnu.lto_.lto.7c13183f5b427e41
00000000 l d .gnu.lto_test.0.7c13183f5b427e41 00000000 .gnu.lto_test.0.7c13183f5b427e41
00000000 l d .gnu.lto_.symbol_nodes.7c13183f5b427e41 00000000 .gnu.lto_.symbol_nodes.7c13183f5b427e41
00000000 l d .gnu.lto_.refs.7c13183f5b427e41 00000000 .gnu.lto_.refs.7c13183f5b427e41
00000000 l d .gnu.lto_.decls.7c13183f5b427e41 00000000 .gnu.lto_.decls.7c13183f5b427e41
00000000 l d .gnu.lto_.symtab.7c13183f5b427e41 00000000 .gnu.lto_.symtab.7c13183f5b427e41
00000000 l d .gnu.lto_.ext_symtab.7c13183f5b427e41 00000000 .gnu.lto_.ext_symtab.7c13183f5b427e41
00000000 l d .gnu.lto_.opts 00000000 .gnu.lto_.opts
00000000 l d .comment 00000000 .comment
00000000 l d .ARM.attributes 00000000 .ARM.attributes
00000000 w .gnu.debuglto_.debug_info 00000000 .hidden test.cxx.cee7ff5d
00000001 O *COM* 00000001 __gnu_lto_slim
I used the following compilation parameters:
arm-none-eabi-g++ -c -fno-common -nostdinc++ -Wall -Wshadow -Wundef -fno-exceptions -fcheck-new -fno-rtti -std=c++17 -pipe -Os -fno-strict-aliasing -fomit-frame-pointer -flto -fuse-linker-plugin -fno-builtin -ffunction-sections -fdata-sections -g -march=armv8-m.main+dsp -mtune=cortex-m33 -mthumb -mfpu=fpv5-sp-d16 -mfloat-abi=hard _ -Wno-cpp --std=c++17 -Werror test.cxx -o test.o
So how can I redefine malloc and free to own_malloc and own_free with lto flag ?

Why there is no .bss segment in COFF object file?

A simple hello world program:
#include <stdio.h>
int main(void)
{
printf("Hello, world!\n");
return 0;
}
After dumpbin it with /HEADERS flag, i get those segments:
8 .bss
A0 .debug$S
62 .drectve
F .rdata
8B .text$mn
If compile the program with /TC, so that it's a C program, i get those segments after the same use of a dumpbin:
2000 .data
1000 .gfids
7000 .rdata
1000 .reloc
10000 .text
point is:
How do i get this similar kind of output:
# objdump -hrt hello.o
hello.o: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000011 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 00000000 00000000 00000048 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000048 2**2
ALLOC
3 .rodata.str1.1 0000000d 00000000 00000000 00000048 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .comment 00000033 00000000 00000000 00000055 2**0
CONTENTS, READONLY
SYMBOL TABLE:
00000000 l df *ABS* 00000000 hello.c
00000000 l d .text 00000000
00000000 l d .data 00000000
00000000 l d .bss 00000000
00000000 l d .rodata.str1.1 00000000
00000000 l d .comment 00000000
00000000 g F .text 00000011 main
00000000 *UND* 00000000 puts

Huge program size C++ with std::regex

I want to compile a small C++ program with std::regex (standard regular expressions library).
Compiler: gcc/g++ 4.9.2 on Fedora 21.
#include <string.h>
#include <iostream>
#include <regex>
using namespace std;
int main () {
cout << "Content-Type: text/html\n\n";
std::string s ("there is a subsequence in the string\n");
std::regex e ("\\b(sub)([^ ]*)"); // matches words beginning by "sub"
std::cout << std::regex_replace (s,e,"sub-$2");
}
It's not possible to compile program with std::regex without -std=c++11, so the suitable instruction for compiling in terminal is:
g++ -std=c++11 code.cpp -o prog
My main question is: the source code is very small, but why is the final file size of the compiled program so huge: 480 kilobytes?
Is it because of the influence of -std=c++11?
What happened and how can I reduce the size of the final binary program?
UPD1.
Using -Os flag is actually good way to reduce program size with std::regex to 100-120 KB from 480 KB.
But it's strange, that even optimized file with std::regexp more than standart 7-12 kylobytes for C/C++ programs with few strings source code.
For example, it's possible to turn the same regex replace trick with RE2 regexp library (in Fedora 21 "yum install re2-devel") in 8.5 KB binary file:
#include <string.h>
#include <iostream>
#include "re2/re2.h"
using namespace std;
int main () {
cout << "Content-Type: text/html\n\n";
std::string s ("there is a subsequence in the string\n");
RE2::GlobalReplace(&s, "\\b(sub)([^ ]*)", "sub-\\2");
cout << s;
}
Compiled with:
g++ -lre2 code.cpp -o prog
UPD2.
objdump for std::regex program:
0 .interp 00000013 08048154 08048154 00000154 2**0
1 .note.ABI-tag 00000020 08048168 08048168 00000168 2**2
2 .note.gnu.build-id 00000024 08048188 08048188 00000188 2**2
3 .gnu.hash 000000b0 080481ac 080481ac 000001ac 2**2
4 .dynsym 000006c0 0804825c 0804825c 0000025c 2**2
5 .dynstr 00000b36 0804891c 0804891c 0000091c 2**0
6 .gnu.version 000000d8 08049452 08049452 00001452 2**1
7 .gnu.version_r 000000d0 0804952c 0804952c 0000152c 2**2
8 .rel.dyn 00000038 080495fc 080495fc 000015fc 2**2
9 .rel.plt 000002b8 08049634 08049634 00001634 2**2
10 .init 00000023 080498ec 080498ec 000018ec 2**2
11 .plt 00000580 08049910 08049910 00001910 2**4
12 .text 0001f862 08049e90 08049e90 00001e90 2**4
13 .fini 00000014 080696f4 080696f4 000216f4 2**2
14 .rodata 00000dc8 08069740 08069740 00021740 2**6
15 .eh_frame_hdr 00003ab4 0806a508 0806a508 00022508 2**2
16 .eh_frame 0000f914 0806dfbc 0806dfbc 00025fbc 2**2
17 .gcc_except_table 00000e00 0807d8d0 0807d8d0 000358d0 2**2
18 .init_array 00000008 0807feec 0807feec 00036eec 2**2
19 .fini_array 00000004 0807fef4 0807fef4 00036ef4 2**2
20 .jcr 00000004 0807fef8 0807fef8 00036ef8 2**2
21 .dynamic 00000100 0807fefc 0807fefc 00036efc 2**2
22 .got 00000004 0807fffc 0807fffc 00036ffc 2**2
23 .got.plt 00000168 08080000 08080000 00037000 2**2
24 .data 00000240 08080180 08080180 00037180 2**6
25 .bss 000001b4 080803c0 080803c0 000373c0 2**6
26 .comment 0000002c 00000000 00000000 000373c0 2**0
objdump for RE2 program:
0 .interp 00000013 08048154 08048154 00000154 2**0
1 .note.ABI-tag 00000020 08048168 08048168 00000168 2**2
2 .note.gnu.build-id 00000024 08048188 08048188 00000188 2**2
3 .gnu.hash 00000034 080481ac 080481ac 000001ac 2**2
4 .dynsym 00000180 080481e0 080481e0 000001e0 2**2
5 .dynstr 00000298 08048360 08048360 00000360 2**0
6 .gnu.version 00000030 080485f8 080485f8 000005f8 2**1
7 .gnu.version_r 000000a0 08048628 08048628 00000628 2**2
8 .rel.dyn 00000010 080486c8 080486c8 000006c8 2**2
9 .rel.plt 00000090 080486d8 080486d8 000006d8 2**2
10 .init 00000023 08048768 08048768 00000768 2**2
11 .plt 00000130 08048790 08048790 00000790 2**4
12 .text 00000332 080488c0 080488c0 000008c0 2**4
13 .fini 00000014 08048bf4 08048bf4 00000bf4 2**2
14 .rodata 00000068 08048c08 08048c08 00000c08 2**2
15 .eh_frame_hdr 00000044 08048c70 08048c70 00000c70 2**2
16 .eh_frame 0000015c 08048cb4 08048cb4 00000cb4 2**2
17 .gcc_except_table 00000028 08048e10 08048e10 00000e10 2**0
18 .init_array 00000008 08049ee4 08049ee4 00000ee4 2**2
19 .fini_array 00000004 08049eec 08049eec 00000eec 2**2
20 .jcr 00000004 08049ef0 08049ef0 00000ef0 2**2
21 .dynamic 00000108 08049ef4 08049ef4 00000ef4 2**2
22 .got 00000004 08049ffc 08049ffc 00000ffc 2**2
23 .got.plt 00000054 0804a000 0804a000 00001000 2**2
24 .data 00000004 0804a054 0804a054 00001054 2**0
25 .bss 00000090 0804a080 0804a080 00001058 2**6
26 .comment 0000002c 00000000 00000000 00001058 2**0
Main difference is in 12.text: in first case used size - 0001f862 (129122); second - only 00000332 (818).
In the case of RE2, most of the actual implementation is in a shared library, which doesn't become part of your executable file. It is loaded into memory separately when you run the program.
In the case of std::regex, this is actually just an alias for std::basic_regex<char>, which is a template. The compiler instantiates the template and builds it into your program directly. Although it is possible for templates to be instantiated inside shared libraries, they often aren't, and the std::basic_regex<char> is not in the shared library in your case.
As an example. Here is how to create a separate shared library with the regex instantiation:
main.cpp:
#include <iostream>
#include <string>
#include "regex.hpp"
int main () {
std::cout << "Content-Type: text/html\n\n";
std::string s {"There is a subsequence in the string\n"};
std::basic_regex<char> e {"\\b(sub)([^ ]*)"};
std::cout << std::regex_replace (s,e,"sub-$2");
}
regex.hpp:
#include <regex>
extern template class std::basic_regex<char>;
extern template std::string
std::regex_replace(
const std::string&,
const std::regex&,
const char*,
std::regex_constants::match_flag_type
);
regex.cpp:
#include "regex.hpp"
template class std::basic_regex<char>;
template std::string
std::regex_replace(
const std::string&,
const std::regex&,
const char*,
std::regex_constants::match_flag_type
);
build steps:
g++ -std=c++11 -Os -c -o main.o main.cpp
g++ -std=c++11 -Os -c -fpic regex.cpp
g++ -shared -o libregex.so regex.o
g++ -o main main.o libregex.so -Wl,-rpath,. -L. -lregex
On my system, the resulting file sizes are:
main: 13936
libregex.so: 196936
First, as it's already said in comments, you should measure the size of optimized binary after doing strip or using the size utility. Otherwise you pay too much attention to debug info stored in the binary. That info normally doesn't occupy the RAM even if you really run that binary.
Second, the actual answer — most of the binary size comes from regex itself and other things in std behind it. You can inspect this using readelf utility, like: readelf -sW prog | c++filt — shows all the functions in the binary with their sizes. It seems that quite a large portion of regex implementation is left as template functions which instantiated in your binary. GCC authors might instantiate more in libstdc++ instead, to allow sharing, like they do with some other things, e.g. some methods of string.
One more not very famous binary size optimization technique: ICF (identical code folding) implemented in gold of binutils. Add -fuse-ld=gold -Wl,--icf=safe to your linker flags.
You can reduce the size by setting optimization:
g++ -std=c++11 -O3 -o prog code.cpp
The -O3 flag means maximum optimization. In my machine that reduces the executable from 519K to 142K
You can also use -Os to optimize for size. On my machine that further reduces the size to 120k.
g++ -std=c++11 -Os -o prog code.cpp

Function with weak atributte can not be overwritten

I would like to overwrite function (interupt handlers) with the weak attribute, but linker does not link my definition. Codes are shorted for better reading.
vectors.c
void NMI_Handler (void) __attribute__((weak));
void HardFault_Handler (void) __attribute__((weak));
__attribute__ ((section(".vectors"), used))
void (* const gVectors[])(void) =
{
NMI_Handler,
HardFault_Handler
};
void NMI_Handler (void) { while(1); }
void HardFault_Handler (void) { while(1); }
I redefine default definition in the file cpuexcept.cpp
extern "C" __attribute__((naked))
void NMI_Handler()
{
EXCEPT_ENTRY(CPUExcept);
}
extern "C" __attribute__((naked))
void HardFault_Handler()
{
EXCEPT_ENTRY(CPUExcept);
}
If I compile and dump it, output (library lib.a) is:
cpuexcept.oo: file format elf32-littlearm
rw-rw-rw- 0/0 4728 Jun 26 16:20 2012 cpuexcept.oo
architecture: arm, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
private flags = 5000000: [Version5 EABI]
Sections:
Idx Name Size VMA LMA File off Algn Flags
0 .text 0000051c 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000000 00000000 00000000 00000550 2**0 CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000550 2**0 ALLOC
3 .rodata 000001dc 00000000 00000000 00000550 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .comment 00000012 00000000 00000000 0000072c 2**0 CONTENTS, READONLY
5 .ARM.attributes 00000031 00000000 00000000 0000073e 2**0 CONTENTS, READONLY
SYMBOL TABLE:
00000000 l df *ABS* 00000000 cpuexcept.cpp
00000000 l d .text 00000000 .text
00000000 l d .data 00000000 .data
00000000 l d .bss 00000000 .bss
000004e0 g F .text 0000000a NMI_Handler
000004ec g F .text 0000000a HardFault_Handler
000004e0 <NMI_Handler>:
4e0: e92d 0ff0 stmdb sp!, {r4, r5, r6, r7, r8, r9, sl, fp}
4e4: 4668 mov r0, sp
4e6: f7ff fffe bl c0 <CPUExcept> 4e6: R_ARM_THM_CALL CPUExcept
4ea: bf00 nop
000004ec <HardFault_Handler>:
4ec: e92d 0ff0 stmdb sp!, {r4, r5, r6, r7, r8, r9, sl, fp}
4f0: 4668 mov r0, sp
4f2: f7ff fffe bl c0 <CPUExcept> 4f2: R_ARM_THM_CALL CPUExcept
4f6: bf00 nop
vectors.o: file format elf32-littlearm
rw-rw-rw- 0/0 4464 Jun 27 13:52 2012 vectors.o
architecture: arm, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000
private flags = 5000000: [Version5 EABI]
Sections:
Idx Name Size VMA LMA File off Algn Flags
0 .text 00000114 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000000 00000000 00000000 00000148 2**0 CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000148 2**0 ALLOC
3 .vectors 00000130 00000000 00000000 00000148 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
4 .comment 00000012 00000000 00000000 00000278 2**0 CONTENTS, READONLY
5 .ARM.attributes 00000031 00000000 00000000 0000028a 2**0 CONTENTS, READONLY
SYMBOL TABLE:
00000000 l df *ABS* 00000000 vectors.c
00000000 l d .text 00000000 .text
00000000 l d .data 00000000 .data
00000000 l d .bss 00000000 .bss
00000000 l d .vectors 00000000 .vectors
00000000 l d .comment 00000000 .comment
00000000 l d .ARM.attributes 00000000 .ARM.attributes
00000000 w F .text 00000002 NMI_Handler
00000004 w F .text 00000002 HardFault_Handler
00000000 <NMI_Handler>:
0: e7fe b.n 0 <NMI_Handler>
2: bf00 nop
00000004 <HardFault_Handler>:
4: e7fe b.n 4 <HardFault_Handler>
6: bf00 nop
Default function with the weak attribute is linked in to target application. My definition is linked correct, if I define function f() in cpuexcept.cpp and I use it in main function or if my definiton of handler is in other .c module.
I use arm-none-eabi-gcc 4.6.2 (YAGARTO) compiler in cygwin.
You could try to define your function like
void NMI_Handler(void)
and not as
void NMI_Handler()
As the weak definition is also void NMI_Handler (void) __attribute__((weak));
So the linker will not see any difference.

windbg coredump analysis address with "bad"

I have a corruption memory heap problem with an application.
by using windbg and a dump file of the crash as an input I have the following output with dd esp command
0:002> dd esp
00000000`03e3e490 14badf55 00000000 03e3e8c0 00000000
00000000`03e3e4a0 00000000 00000000 03e3e8c0 00000000
00000000`03e3e4b0 03e3e8c0 00000000 6b0064f2 00000000
00000000`03e3e4c0 03e3f030 00000000 6b002510 00000000
00000000`03e3e4d0 00000000 00000000 03dfede8 00000000
00000000`03e3e4e0 c0000005 00000000 00000000 7d6210e8
00000000`03e3e4f0 00000002 00000000 00000000 00000000
00000000`03e3e500 00000000 00001000 78b83980 036b0000
There is this adress : 14badf55
I really don't know how to interpret this "bad"..
Is anyone have an idea of the meaning of this bad ?
EDIT:
when I try to use this command :
u 14badf55
the following output comes :
00000000`14badf55 ?? ???
^ Memory access error in 'u 14badf55'
The .ecxr command give me :
rax=0000000003e3e488 rbx=0000000003e3e8c0 rcx=0000000003e3dfb0
rdx=0000000000000000 rsi=000000006b005a17 rdi=0000000000000000
rip=000000006b006369 rsp=0000000003e3e490 rbp=0000000003dfede8
r8=000000006b00254a r9=0000000003e3e4d8 r10=0000000000000007
r11=0000000000000000 r12=000000006b01fe90 r13=0000000000000000
r14=0000000003e3f110 r15=0000000078b83980
iopl=0 nv up ei pl nz na po nc
cs=0033 ss=002b ds=0000 es=0000 fs=0000 gs=0000 efl=00000204
wow64!Wow64NotifyDebugger+0x9:
00000000`6b006369 b001 mov al,1
You can see the c0000005 output in the file. This is the sign of a access violation.
Run the following:
- .cxr 00000000`03e3e4e0 (To set the exception context)
- kL (to get a stack trace)