While using Application Verifier and windbg to debug one of my VSTO addins, I found out that on Word close I get the following stop:
VERIFIER STOP 00000902: pid 0x3F1C: An HKEY was leaked.
00000632 : Value of the leaked HKEY.
0422EA9C : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
1D3F6FE8 : Address of the owner dll name. Run du <address> to read the dll name.
74040000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
What is the best way to find out the cause of this stop?
Following the advice I did dps 0422EA9C
and the following was returned:
0422ea9c 0423f164
0422eaa0 0000e001
0422eaa4 001c0000
0422eaa8 740f3da0 vfbasics!AVrfpRegOpenKeyW+0xb0
0422eaac 74041e54 oledlg!CStringCache::Init+0x47
0422eab0 74041b51 oledlg!DllMain+0x2e
0422eab4 74041869 oledlg!_CRT_INIT+0x26d
0422eab8 7415c66d verifier!AVrfpStandardDllEntryPointRoutine+0x99
0422eabc 741c95fa vrfcore!VfCoreStandardDllEntryPointRoutine+0x12a
0422eac0 740e7904 vfbasics!AVrfpStandardDllEntryPointRoutine+0xa4
0422eac4 77698d04 ntdll!LdrpCallInitRoutine+0x14
0422eac8 7769c23d ntdll!LdrpRunInitializeRoutines+0x26f
0422eacc 7769aeb5 ntdll!LdrpLoadDll+0x453
0422ead0 7769afcc ntdll!LdrLoadDll+0xaa
0422ead4 740e7d2d vfbasics!AVrfpLdrLoadDll+0x5d
0422ead8 75072ca8 KERNELBASE!LoadLibraryExW+0x1f7
0422eadc 74e548f4 kernel32!LoadLibraryW+0x11
0422eae0 741a6871 vstoee!DllGetClassObject+0x4320
0422eae4 741a68a1 vstoee!DllGetClassObject+0x4350
0422eae8 6b5bfca5 mso!Ordinal4378+0x8dc
0422eaec 6ac85248 mso!MsoFLongSave+0xaa353
0422eaf0 6a686ddd mso!Ordinal9769+0x60b
0422eaf4 6a68667a mso!Ordinal1832+0x13b
0422eaf8 6be22bbb wwlib!DllGetClassObject+0x5dbef
0422eafc 6bdc7c2f wwlib!DllGetClassObject+0x2c63
0422eb00 6bdc4a4b wwlib!FMain+0x253
0422eb04 013815c4 winword+0x15c4
0422eb08 01381558 winword+0x1558
0422eb0c 74e5337a kernel32!BaseThreadInitThunk+0xe
0422eb10 776992b2 ntdll!__RtlUserThreadStart+0x70
0422eb14 77699285 ntdll!_RtlUserThreadStart+0x1b
0422eb18 00000000
Then du 1D3F6FE8
returned
1d3f6fe8 "oledlg.dll"
Interestingly, If I run Application Verifier / WinDbg on Word without my addin loaded I still get a stop:
APPLICATION_VERIFIER_LEAK_ALLOCATION (900)
A heap allocation was leaked.
This stop is generated if the owner dll of the allocation was dynamically unloaded while owning resources.
Arguments:
Arg1: 0b7e2fb8, Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
Arg2: 041495f4, Address to the allocation stack trace. Run dps <address> to view the allocation stack.
Arg3: 0c446fe4, Address of the owner dll name. Run du <address> to read the dll name.
Arg4: 70b50000, Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
GetPageUrlData failed, server returned HTTP status 404
URL requested: http://watson.microsoft.com/StageOne/winword_exe/15_0_4737_1003/559b7227/vrfcore_dll/10_0_15063_137/f4688fdb/80000003/00003809.htm?Retriage=1
Is this the same thing but reported differently?
I looked deeper into this as the very helpful comments above pointed me to think this is not an issue with my addin code but rather with the VSTO host application ie. Word.
So I created a simple VSTO addin with a one button ribbon that just opens a taskpane with a label which says “Hello!” (nothing else – no WPF) and I can confirm that even in this scenario I still get the HKEY Leak on shutdown…
For completeness, when no addins are loaded I get a different stop:
=======================================
VERIFIER STOP 0000000000000300: pid 0x4008: Invalid handle exception for current stack trace.
00000000C0000008 : Exception code.
000000000F9DE670 : Exception record. Use .exr to display it.
000000000F9DE180 : Context record. Use .cxr to display it.
0000000000000000 : Not used.
=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.
=======================================
ModLoad: 711a0000 711c5000 C:\windows\SysWOW64\POWRPROF.DLL
=======================================
VERIFIER STOP 00000900: pid 0x4008: A heap allocation was leaked.
0BDCCFB8 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
041D9C54 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
0C36AFE4 : Address of the owner dll name. Run du <address> to read the dll name.
749C0000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
=======================================
!avrf suggests a APPLICATION_VERIFIER_LEAK_ALLOCATION (900) so I don't think this is a problem with anything but Application Verifier.
Related
I'm currently trying to debug my kernel. My goal is to put a breakpoint in a new syscall that I am implementing. The kernel runs on a remote Imx6q board. I've setup the JTAG debugger and I can connect GDB to it and pause the execution.
My issue is whith debug symbols.
I've added those properties to my defconfig :
CONFIG_GDB_SCRIPTS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_RANDOMIZE_BASE=n
CONFIG_FRAME_POINTER=y
CONFIG_KGDB=y
CONFIG_DEBUG_INFO=y
When I start a session :
(gdb) tar ext :3333
Remote debugging using :3333
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0xa7780ef0 in ?? ()
(gdb) c
Continuing.
I can attach a symbol file by hand, but it is required to provide an address to attach it.
(gdb) add-symbol-file /home/tlavocat/development/android/out/target/product/wandboard_qca/kernel-imx/kernel/sys.o
The address where /home/tlavocat/development/android/out/target/product/wandboard_qca/kernel-imx/kernel/sys.o has been loaded is missing
The function I want to stop in is this one :
wandboard_qca:/ # cat /proc/kallsyms | grep sys_keeper_get_state
c003e0ac T sys_keeper_get_state
And it is implemented in kernel/sys.c.
My question is, how can I attach my symbols correctly to the right address ?
Thank's for your answers
I simply needed to load le kernel binary.
file .out/target/product/wandboard_qca/kernel-imx/vmlinux
And then connect to the remote target.
I am making an exe from an existing VB6 project. During Make, VB crashes with the following message
Visual Basic has stopped working
Problem Event Name: APPCRASH
Application Name: vb6.exe
Application Version: 6.0.97.82
Fault Module Name: ntdll.dll
Exception Code: c0000005
I am able to run the project from VB6 without any trouble. The problem occurs when I try to make the exe.
Please could you let me know what could be wrong?
Thanks!
This all needs to be done on the computer with the fault. I cannot load my ntdll.dll as it a different version and the addresses will be different to yours.
Download and install Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/hh852363
Install the Windows SDK but just choose the debugging tools.
Create a folder called Symbols in C:\
This allows WinDbg to get the symbols for your version of ntdll.dll. Start Windbg. File menu - Symbol File Path and enter
srv*C:\symbols*http://msdl.microsoft.com/download/symbols
then
Open ntdll in WinDbg as a crashdump.
It will show the load address.
Type in WinDbg
ln <modloadaddress> + 7c911780
This will give you the nearest symbol to the crash. It probably isn't useful but lets see.
You can also run VB6 under WinDbg (make sure WinDbg is run as admin). When you crash do a stack trace.
Also do an !Analyze when you crash. It is meant for blue screens but will give info on appcrash.
Type in the WinDbg command prompt
!analyze -v
-v stands for Verbose and if the crash was originated by a program, as opposed to hardware or a driver, it will appear in the middle of the listing.
eg
PROCESS_NAME: java.exe
IMAGE_NAME: ntkrnlmp.exe
PROCESS_NAME only appears in the analyze -v output and only if a program originated the call that faulted.
WinDbg Commands
Open as Executable.
windbg -o -g -G c:\windows\system32\cmd.exe /k batfile.bat
You can press F12 to stop it and kb will show the call stack (g continues the program). If there's errors it will also stop and show them.
There is a breakpoint after loading but before any code is run. Press g to continue. Likewise there is a breakpoint after all code has run but before it is unloaded.
Type lm to list loaded modules, x *!* to list the symbols and bp symbolname to set a breakpoint
If programming in VB6 then this environmental variable link=/pdb:none stores the symbols in the dll rather than separate files. Make sure you compile the program with No Optimisations and tick the box for Create Symbolic Debug Info. Both on the Compile tab in the Project's Properties.
Sample output from a nearest symbol search.
Loading Dump File [C:\Windows\System32\ntdll.dll] Symbol search path
is: srvc:\symbolshttp://msdl.microsoft.com/download/symbols
Executable search path is: ModLoad: 4b280000 4b3f9000
C:\Windows\System32\ntdll.dll eax=00000000 ebx=00000000 ecx=00000000
edx=00000000 esi=00000000 edi=00000000 eip=4b280000 esp=00000000
ebp=00000000 iopl=0 nv up di pl nz na pe nc cs=0000 ss=0000
ds=0000 es=0000 fs=0000 gs=0000 efl=00000000
ntdll!__guard_fids_table (ntdll+0x0): 4b280000 4d
dec ebp 0:000> ln 4b280000 + 65534 (4b2e5520)
ntdll!RtlInitializeBitMap+0x14 | (4b2e5540)
ntdll!TpCallbackUnloadDllOnCompletion
Sample stack trace.
You follow what function called what functions. So you read it from the bottom up. It has the first 4 parameters that were passed to the function. You find the debugger starts additional threads so we need to find our program's one.
~
Lists all threads
~<threadid> e <command>
Do a KB on all threads until you find the main one.
0:004> ~0 e kb
ChildEBP RetAddr Args to Child 04bdfc30
75ae325a 04bdfc70 00000000 00000000 USER32!NtUserGetMessage+0xc
04bdfc4c 00895eb6 04bdfc70 00000000 00000000 USER32!GetMessageW+0x2a
04bdfc8c 008a5b41 00890000 00000000 04e2336f notepad!WinMain+0xe6
04bdfd20 74ad3744 7f229000 74ad3720 10fde46e
notepad!WinMainCRTStartup+0x151 04bdfd34 7755a064 7f229000 b0c1107f
00000000 KERNEL32!BaseThreadInitThunk+0x24 04bdfd7c 7755a02f ffffffff
7757d7c9 00000000 ntdll!__RtlUserThreadStart+0x2f 04bdfd8c 00000000
008a59f0 7f229000 00000000 ntdll!_RtlUserThreadStart+0x1b
Assume that 04bdfc70 is an HWnd. Which it is because the documentation says so. But assume it an address of a string. This displays what is there.
ds 775a1300
or to look at the values
db 775a1300
Here is the crash i found in the log shown by Windbg. but not able to get anything out of it. please help.
00000000`0008ae08 00000000`76eb219e wow64cpu!CpupSyscallStub+0x2
00000000`0008ae10 00000000`76e7219a wow64cpu!Thunk0ArgReloadState+0x5
00000000`0008aec0 00000000`76e79b14 wow64!RunCpuSimulation+0xa
00000000`0008af10 00000000`76ed840f wow64!Wow64KiUserCallbackDispatcher+0x244
00000000`0008b270 00007ff9`ac2c3044 wow64win!whcbfnINOUTSTYLECHANGE+0xbf
00000000`0008bc50 00000000`76ee9a7a ntdll!KiUserCallbackDispatcherContinue
00000000`0008bcd8 00000000`76ed7a74 wow64win!NtUserSetWindowLongPtr+0xa
00000000`0008bce0 00000000`76e6a44b wow64win!whNtUserSetWindowLong+0x44
00000000`0008bd10 00000000`76eb1dc5 wow64!Wow64SystemServiceEx+0xfb
00000000`0008c5c0 00000000`76e7219a wow64cpu!ServiceNoTurbo+0xb
00000000`0008c670 00000000`76e79b14 wow64!RunCpuSimulation+0xa
00000000`0008c6c0 00000000`76ed880e wow64!Wow64KiUserCallbackDispatcher+0x244
00000000`0008ca20 00007ff9`ac2c3044 wow64win!whcbfnINOUTNCCALCSIZE+0x14e
00000000`0008d470 00000000`76eb2352 ntdll!KiUserCallbackDispatcherContinue
00000000`0008d558 00000000`76eb2318 wow64cpu!CpupSyscallStub+0x2
00000000`0008d560 00000000`76e7219a wow64cpu!Thunk0Arg+0x5
00000000`0008d610 00000000`76e79b14 wow64!RunCpuSimulation+0xa
00000000`0008d660 00000000`76ed5c0a wow64!Wow64KiUserCallbackDispatcher+0x244
00000000`0008d9c0 00007ff9`ac2c3044 wow64win!whcbfnDWORD+0x21a
00000000`0008e3c0 00000000`76ee5a3a ntdll!KiUserCallbackDispatcherContinue
00000000`0008e448 00000000`76ed6df2 wow64win!NtUserMessageCall+0xa
00000000`0008e450 00000000`76ed6b64 wow64win!whNT32NtUserMessageCallCB+0x32
00000000`0008e4a0 00000000`76e6a44b wow64win!whNtUserMessageCall+0xc4
00000000`0008e560 00000000`76eb1dc5 wow64!Wow64SystemServiceEx+0xfb
00000000`0008ee10 00000000`76e7219a wow64cpu!ServiceNoTurbo+0xb
00000000`0008eec0 00000000`76e720d2 wow64!RunCpuSimulation+0xa
00000000`0008ef10 00007ff9`ac2f3a15 wow64!Wow64LdrpInitialize+0x172
00000000`0008f450 00007ff9`ac2d2f1e ntdll!LdrpInitializeProcess+0x1591
00000000`0008f770 00007ff9`ac248ece ntdll!_LdrpInitialize+0x89ffe
00000000`0008f7e0 00000000`00000000 ntdll!LdrInitializeThunk+0xe
As others have mentioned, you have a 64 bit dump of a 32 bit process. We can see this because your excerpt shows 64 bit addresses and it has the wow64 module in the stack.
Typically you should try to get a dump of the correct bitness. The linked SO answer lists several options to get one.
Opening the dump file in the x86 version of WinDbg does not help. Even the x86 version can analyze 64 bit dumps:
The !sw command (load it with .load wow64exts) or the .effmach x86 command can switch the debugger to x86 mode. Note how the command prompt changes:
To show the call stack, you'll now need the wow64exts extension. Also be sure to have set the symbols:
.load wow64exts
.symfix
.reload
Note that there is one call stack per thread, so make sure you get the right one:
~#s
k
In case of a crash, look at the exception:
.exr -1
I have a few Windows 7 machines that I am not able to read their memory dumps. I found something that I suspect may be related, but am not positive:
https://twitter.com/aionescu/status/634028737458114560
I also found this: http://support.microsoft.com/kb/2528507
However, the scenario message regarding wow64exts given in the doc is not seen in any of my dumps. I also cannot apply that hotfix at this time to test it. So I'm just looking for some more information or opinions.
I'm able to open any other OS dump as well as my own system's Windows 7 dump, but there are 2 other machines that run Win 7 and it's telling me I have the wrong kernel symbols.
I have tried clearing out my symbol cache, reinstalled the Windows SDK, and also tried to open the dumps on two other machines with the same result. If it matters, the crash is manually created using the scroll lock method.
Symbol path: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;
Seeing these errors: followed by "Type referenced: nt!_KPRCB"
Does anyone know about the issue mentioned by Alex in the twitter link and if it's possibly related to what I'm seeing?
Update 2015-10-22:
With the Microsoft patch day (2015-10-13) and KB3088195, symbols are available again.
However, symbols for the broken version have not been provided, so below may still be useful.
Microsoft has already published "good" symbols for ntdll in the past, containing type information like _TEB or _KPRCB. Starting from mid of July 2015, Microsoft has still published symbols for ntdll, but not containing that information.
So it depends on the version of ntdll whether you get type information or not. Old dumps referencing an old version of ntdll will download old PDBs containing type information while new dumps reference new versions of ntdll and WinDbg (or any other debugger) downloads PDBs without type information.
Could Microsoft remove type information of "good" symbols retroactively, thus making them "bad"?
Yes. As described in this answer, there is a tool to remove type information from existing PDBs. Doing that and replacing the PDB would result in such an effect.
Can Microsoft publish the "good" version of those PDBs which are currently "bad"?
That's hard to tell, since we don't know whether Microsoft has kept a copy of the "good" version so they could replace the "bad" version on the symbol server with the "good" one. Rebuilding ntdll from the same source code and thus creating new PDBs sounds possible, but the PDB gets a new time stamp and checksum. This can potentially be corrected manually, especially be Microsoft, since they should have the knowledge about the PDB internal format, but IMHO it's unlikely they'll do that. Things may go wrong and MS will hardly have tests to guarantee the correctness of such a thing.
So what can I do?
IMHO you can do nothing to really correct the situation.
You could assume that the types in ntdll have not changed so much. This would allow you to take an older version of wntdll.pdb and the new version of ntdll.dll and apply ChkMatch -m to it. This will copy the timestamp and checksum from the DLL to the PDB. After you did that (in an empty folder), replace the existing wntdll.pdb in your symbols directory with the hacked one.
WinDbg walkthrough (with output shortened to relevant things). I am using the latest version of wntdll.pdb I could find on my PC.
WARNING: doing the following may fix the type information but will likely destroy the correctness of the callstacks. Since any changes in the implementation (which are likely for security fixes) will change the method offsets.
0:005> dt nt!_PEB
*************************************************************************
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
...
*** Type referenced: nt!_PEB ***
*** ***
*************************************************************************
Symbol nt!_PEB not found.
0:005> lm m ntdll
start end module name
773f0000 77570000 ntdll (pdb symbols) e:\debug\symbols\wntdll.pdb\FA9C48F9C11D4E0894B8970DECD92C972\wntdll.pdb
0:005> .shell cmd /c copy C:\Windows\SysWOW64\ntdll.dll e:\debug\temp\ntdllhack\ntdll.dll
1 file(s) copied.
0:005> .shell cmd /c copy "E:\Windows SDk\8.0\Debuggers\x86\sym\wntdll.pdb\B081677DFC724CC4AC53992627BEEA242\wntdll.pdb" e:\debug\temp\ntdllhack\wntdll.pdb
1 file(s) copied.
0:005> .shell cmd /c E:\debug\temp\ntdllhack\chkmatch.exe -m E:\debug\temp\ntdllhack\ntdll.dll E:\debug\temp\ntdllhack\wntdll.pdb
...
Executable: E:\debug\temp\ntdllhack\ntdll.dll
Debug info file: E:\debug\temp\ntdllhack\wntdll.pdb
Executable:
TimeDateStamp: 55a69e20
Debug info: 2 ( CodeView )
TimeStamp: 55a68c18 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 35 RVA: 000e63e0 FileOffset: 000d67e0
CodeView format: RSDS
Signature: {fa9c48f9-c11d-4e08-94b8-970decd92c97} Age: 2
PdbFile: wntdll.pdb
Debug info: 10 ( Unknown )
TimeStamp: 55a68c18 Characteristics: 0 MajorVer: 565 MinorVer: 6526
Size: 4 RVA: 000e63dc FileOffset: 000d67dc
Debug information file:
Format: PDB 7.00
Signature: {b081677d-fc72-4cc4-ac53-992627beea24} Age: 4
Writing to the debug information file...
Result: Success.
0:005> .shell cmd /c copy E:\debug\temp\ntdllhack\wntdll.pdb E:\debug\symbols\wntdll.pdb\FA9C48F9C11D4E0894B8970DECD92C972\wntdll.pdb
1 file(s) copied.
0:005> .reload
Reloading current modules
.............................
0:005> dt nt!_PEB
ntdll!_PEB
+0x000 InheritedAddressSpace : UChar
+0x001 ReadImageFileExecOptions : UChar
...
0:005> !heap -s
LFH Key : 0x219ab08b
Termination on corruption : DISABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
Virtual block: 00920000 - 00920000 (size 00000000)
Virtual block: 02c60000 - 02c60000 (size 00000000)
Virtual block: 02e10000 - 02e10000 (size 00000000)
...
Note: using ChkMatch like this has the benefit that you do not need to turn on .symopt- 100, since that option would affect all PDB files, and you would not find potential other symbol issues. If you don't mind using .symopt, you could simply copy an old wntdll.PDB over the new one.
The issue is now fixed according to Microsoft and Microsoft told me that you should clear your symbol cache to get the new PDBs, otherwise Windbg would use the old Symbols which miss the information.
I'm trying to start kernel debugging with this sytem:
Amontec JTAGkey2, openocd, gdb, eclipse.
At the end I would like to debug kernel and application that is running within.
I have few problems, and it seems that I need to solve them sequently.
Now I have CPU suspend/resume, read/write RAM
What is missing: Step into, Step over, C/C++ Level debugging.
I do following:
- Connect JTAG, Power up board, start uImage with Debug messages via Uboot
- start openocd:
# openocd -f /usr/share/openocd/scripts/interface/jtagkey2.cfg -f /usr/share/openocd/scripts/board/at91sam9g20-ek.cfg
Output:
jtag_nsrst_delay: 200
jtag_ntrst_delay: 200
RCLK - adaptive
TapName | Enabled | IdCode Expected IrLen IrCap IrMask Instr
---|--------------------|---------|------------|------------|------|------|------|---------
0 | at91sam9g20.cpu | Y | 0x00000000 | 0x0792603f | 0x04 | 0x01 | 0x0f | 0x0f
Info : max TCK change to: 30000 kHz
Info : RCLK (adaptive clock speed)
Info : JTAG tap: at91sam9g20.cpu tap/device found: 0x0792603f (mfg: 0x01f, part: 0x7926, ver: 0x0)
Info : Embedded ICE version 6
And problems starts here:
openocd:
Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
Warn : target not halted
eclipse:
symbol-file /opt/Tixi_Repos/KiwiG6v2/buildroot-2011.05/package_tixi/linux-2.6.39/arch/arm/boot/compressed/vmlinux
target remote localhost:3333
start () at arch/arm/boot/compressed/head.S:108
108 kphex r5, 8 /* end of kernel */
It seems also that JTAG is trying to load the code into 0x0, what is incorrect I suppose:
Update 1:
After analyzing some online tutorials for ARM:
Eclipse Reset and Halt commands doesn't work perfect. It is better to uncheck them and write into command window. Also load address can be add:
monitor halt
load arch/arm/boot/compressed/vmlinux 0x22000000
I don't use
monitor reset
I let Uboot start and initialize RAM and other peripherals. Then I stop Uboot by getting into shell. Then I let eclipse write linux into RAM, and start it. It takes very long, but works bit better. Kernel starts and stopps on RPC initialization without giving console back.
would it be possible to load kernel into RAM within Uboot console, and start JTAG session afterwards ?
What is the difference between [load ...] and [monitor load...] commands
Why do I need to load /compressed/vmlinux instead of uImage ?
in eclipse window I have two load fields: load image i load symbol. I disable both options but write only load arch/arm/boot/compressed/vmlinux 0x22000000. Is it maybe the reason for next problems ?
Update 2:
Ok. Thank you for hints.
I've made some progress. Could you give me some advices, maybe I'm still doing something wrong.
Now my kernel runs under JTAG control, but I still can't debug on source code level.
I do as follows:
Power up the board, go into uboot shell.
start openOCD session
Set Uboot breakpoint in bootm.c on theKernel call:
cleanup_before_linux ();
theKernel (0, machid, bd->bi_boot_params);
start eclipse debug session :
monitor halt
load uboot-a without offset
load u-boot-2010.06/u-boot
Loading section .text, size 0x349ec lma 0x26f00000
start uboot and let it run
uboot stopps on "theKernel" call
I know that kernel is located on address 0x20008000.
restart openOCD session
start ecipse debugger once more with kernel configuration:
monitor halt
load kernel on address 0x20008000
load arch/arm/boot/compressed/vmlinux 0x20008000
Loading section .text, size 0x8bdc7c lma 0x20008000
start debugg session
Everything works fine now, and kernel starts, but I still can't debug on source code level.
"symbol is not available"
DEBUG and DEBUG_INFO are on for kernel.
vmlinux screenshot
What seems starnge for me that there are around 50 function symbols in this file.