Help testing symbols with new Bochs disassembler module

[stlw]

Hello,

I am looking for a person who could take a look onto symbols implementation for Bochs new disassembly module.
I am personally not using Bochs debugger for real purposes (like debugging real stuff) and don’t even know if symbols are working well or not.
I tried to do some unit testing (on 64-bit code) and got very controversial results so even cannot confirm symbols stuff is working today.
I expect you guys are using it on more daily basis and could also complain if something is not working and also help to get it into perfection.

The old legacy disasm module is obsolete, it doesn't know to disassembly a lot of new instructions like AVX512 for example and also have bugs and issues.
New disasm method for Bochs is based Bochs internal decoder and will be able to handle any opcode Bochs know to execute.
It is going to replace the old disasm completely (so old one will be removed from the codebase).
The only reason it didn't happen today yet -> the old model is integrated with "symbols" while new is not yet.
It is quite easy to add symbol support for new disasm as well (already done in my local branch) but I cannot test it.
Is anyone willing to contribute ?

Thanks,
Stanislav

[xenos]

I haven't used the Bochs debugger for a while, but I would be curious to try it out and report any errors I find.

Is the new code in the current SVN and used by default, or does it need to be activated / configured to be used? Or just in your local branch? So I guess to test it, one needs to load a kernel and debug symbols?

[stlw]

Yes, it is mostly about loading your kernel with debug symbols and watching how they displayed in the disassembly.
The symbols in debugger displayed in many places, I am interested ONLY in ones that embedded in the instruction disasm now.
The current disasm supports symbolizing Jmp and Call targets (Jb/Jw/Jd and Ap handlers) and also Rip-Relative addressing.

I am not sure these symbols work correctly even today, I tried to create sort of unit test and was not able to see correct symbols according to my expectations for branch and call targets for example. Can you see if it works with SVN to begin with ? If yes -> I will roll out the new version and you will compare new output to old one in the same scenario.

Thanks,
Stanislav

[bzt]

I also would like to help. If you're interested, I've fixed some bugs in the debugger too (the ones I've run into, mostly printing debug information related). See here (sorry, quite old repo, fixes against version 2.6.8 ).

Yes, it is mostly about loading your kernel with debug symbols and watching how they displayed in the disassembly.

Well, loading debug symbols from the kernel never ever worked for me. Is this that has been implemented now? I've always created a textual symbol file with "<hex address> <space> <label> <newline>" lines (from nm's output) and added

Code: Select all

debug_symbols: file=kernel.sym, offset=0

to bochrc. Is this what you're asking about or reading the ELF debug sections and symbols?

Cheers,
bzt

[stlw]

Yes, I am asking about debug_symbols.
Because I don't have any kernel around with or without debug symbols I cannot even try to use this command ...

[bzt]

Yes, I am asking about debug_symbols.

Ok, I like that better anyway. That works for all executable formats and for kernels that are splitted into multiple files too (like a modular kernel).

Just an idea, but it would be great if that could also support an array indexed by CR3 values, like

Code: Select all

debug_symbols: ...           # (common, always used, no matter what's in CR3 or if paging is disabled, just like now)
debug_symbols[0x1000]: ...   # (additional symbols, only used when CR3==0x1000)
debug_symbols[0x2000]: ...   # (additional symbols, only used when CR3==0x2000)

That would allow using symbols with microkernels too (which typically use separate servers with separate address spaces).

Because I don't have any kernel around with or without debug symbols I cannot even try to use this command ...

I've downloaded the latest 2.6.11 source from bochs.sourceforge.net, I compiled it and it's looking good at first glance. (I hope I haven't mixed up the executable because I have quite a lot bochs variants on my machine...)

You can download a minimal bootable disk image that I've used (disk-x86.img.gz 184 Kb), and I've attached a debug_symbols file too so that you can test your bochs builds with. The well-commented Assembly source of the code is here. This has 16 bit, 32 bit and also 64 bit code labels, data labels, physical address as well as linear address labels, so it's good for testing all kinds of debug symbols. The kernel is a minimal, upper-half "Hello World" kernel, therefore most of the symbols are from the boot loader.

Cheers,
bzt

[stlw]

Thanks for the kernel, already used it, found and fixed first issues with symbols in new disassembly module.
Tested only 16-bit part for now. Do you have any magic BP or other way to fast jump to 32-bit and 64-bit code ?

Thanks,
Stanislav

[feryno]

Stanislav, I used your debugger a lot, it was extremely useful and helpful. Without symbols.
You have the magic breakpoint instruction xchg bx,bx but that did not work at me for unknown reason, so I used to add jmp $ instead, paused debugger after enough time, incremented instruction pointer by 2 or replaced the jmp $ with 2 NOP instructions or original 2 bytes if editing binary from someone else.

[bzt]

Do you have any magic BP or other way to fast jump to 32-bit and 64-bit code ?

Ok, I've added some breakpoints, one at realmode_start, one at protmode_start, also at longmode_start and finally one before the code jumps to the kernel entry point.
You can find the modified image and new symbol file here.

I've also added a Makefile to regenerate everything and update the loader in the image. This way you can add as many BPs as you'd like and it will also regenerate the symbol file for you. You'll need fasm and some standard Linux utilities (nm, dd, cat, printf etc.).

the magic breakpoint instruction xchg bx,bx but that did not work at me for unknown reason

You have to enable it in bochrc with

Code: Select all

magic_break: enabled=1

Cheers,
bzt

[stlw]

New disasm for Bochs was pushed into SVN replacing the old disasm.
We have lost symbol printing for RIP-relative addressing (not implemented yet in new disasm) but everything else should be fine.
Can everyone please test it with or without symbols, especially AT&T (GNU Asm) syntax which is less tested ?

Thanks
Stanislav