可钦：

除了Gnode在物理机上的调试外，花时间把下面的事情也调研、试一试。

* Fiasco.OC在物理机上的调试。

Jian LIU ---- email to: gjk.liu@...9...

2013/4/19 Keqin Sun <keqin@...189...>

Hi, I want to debug nic_drv on a real machine using gdb_monitor. But gdb showed this:

(gdb) target remote /dev/ttyS0 Remote debugging using /dev/ttyS0 Ignoring packet error, continuing... warning: unrecognized item "timeout" in "qSupported" response Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing...

and my run srcript is: # # Build #

build { core init drivers/timer drivers/pci app/gdb_monitor drivers/uart drivers/nic }

create_boot_directory

# # Generate config #

install_config {

<config verbose="yes"> <parent-provides> <service name="ROM"/> <service name="RAM"/> <service name="IRQ"/> <service name="IO_MEM"/> <service name="IO_PORT"/> <service name="CAP"/> <service name="PD"/> <service name="RM"/> <service name="CPU"/> <service name="LOG"/> <service name="SIGNAL"/> </parent-provides> <default-route> <any-service> <parent/> <any-child/> </any-service> </default-route> <start name="timer"> <resource name="RAM" quantum="1M"/> <provides> <service name="Timer"/> </provides> </start> <start name="uart_drv"> <resource name="RAM" quantum="2M"/> <provides> <service name="Terminal"/> </provides> #is that service name "Terminal" should be "/dev/ttyS0" ? <config> <policy label="gdb_monitor" uart="1"/> </config> </start> <start name="pci_drv"> <resource name="RAM" quantum="2M"/> <provides><service name="PCI"/></provides> </start> <start name="gdb_monitor"> <resource name="RAM" quantum="5M"/> <provides><service name="Nic" /></provides> <config> <target name="nic_drv"/> <preserve name="RAM" quantum="2M"/> </config> </start> </config>}

# # Boot image #

build_boot_image { core init timer ld.lib.so libc.lib.so libc_log.lib.so libc_lock_pipe.lib.so libc_terminal.lib.so uart_drv pci_drv gdb_monitor nic_drv }

set local_port 5555

#append qemu_args " -nographic " append qemu_args " -m 128 -nographic "

# connect comport 0 to stdio append qemu_args " -net nic,model=e1000 -net user " append qemu_args " -serial mon:stdio "

# connect comport 1 with TCP port $local_port append qemu_args " -serial chardev:uart " append qemu_args " -chardev socket,id=uart,port=$local_port,host=localhost,server,nowait "

#run_genode_until forever run_genode_until {.*Remote debugging using /dev/ttyS0.*} 30 #run_genode_until {.*Remote debugging using /dev/terminal.*} 30

#exec [terminal] -e "[gdb] bin/nic_drv -ex "target remote localhost:$local_port" " & #exec [terminal] -e "[gdb] bin/nic_drv -ex "target remote localhost:$local_port" " & interact

Is that correct?

Maybe the serial was occupied by the system output?

keqin

---

Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

Hi Keqin,

I suspect that you are mixing up the UART interfaces. The run script relies on two UARTs to be present. UART 0 is used for printing Genode's LOG messages and the kernel messages. The GDB monitor requires a separate channel of communication to the remote GDB. The run script uses UART 1 via the 'uart_drv' for that. UART 1 is then translated by qemu to a TCP connection.

When executing the script on real hardware, you need two UARTs as well. I suspect that you have connected only a single one. Connecting GDB to the UART 0 of the Genode system makes no sense because this one is unrelated to the GDB monitor.

<start name="uart_drv"> <resource name="RAM" quantum="2M"/> <provides> <service name="Terminal"/> </provides> #is that service name "Terminal" should be "/dev/ttyS0" ?

The service name denotes the type of the session. The UART driver provides sessions of type "Terminal" and "Uart". (the "Uart" type is a specialized kind of "Terminal", not important here) In the Genode world "/dev/ttyS0" has no meaning.

<config>
	<policy label="gdb_monitor" uart="1"/>
</config>

</start>

This configuration tells the UART driver to hand out the second UART (UART 1) to the gdb_monitor client. The numbering starts at 0. UART 0 is typically used by the kernel and Genode's core.

Is that correct?

Does the run script works as intended on Qemu?

Maybe the serial was occupied by the system output?

I guess, you are putting your finger exactly on the issue.

Do you have a way to connect a second UART to your PC? If you consider using a PCI card with additional comports, you will need to make sure that the UART driver uses the I/O ports of the card. (by modifying the function 'io_port_base' in 'os/src/drivers/uart/i8250/main.cc'. You may determine the right values by booting Linux once and executing 'lspci'.

I admit, that sounds a bit awkward and complicated. Normally, you could use the TCP terminal ('gems/src/server/tcp_terminal') as an alternative to an UART interface when using GDB monitor. So there would be no need for multiple UART interfaces. (the TCP terminal provides the "Terminal" interface but works over TCP) Unfortunately, that's not possible when debugging the NIC driver because TCP terminal requires a NIC driver to work.

Cheers Norman

Hi Norman, Can I just turn the Genode's LOG messages and the kernel messages off, then let the GDB monitor use the UART0 channel? If I can, how to do that?

Bests keqin

On ÐÇÆÚÁù, ËÄÔÂ 20, 2013 6:39 pm, Norman Feske wrote: ----------------------------------------------------------------------------------- Hi Keqin,

I suspect that you are mixing up the UART interfaces. The run script relies on two UARTs to be present. UART 0 is used for printing Genode's LOG messages and the kernel messages. The GDB monitor requires a separate channel of communication to the remote GDB. The run script uses UART 1 via the 'uart_drv' for that. UART 1 is then translated by qemu to a TCP connection.

When executing the script on real hardware, you need two UARTs as well. I suspect that you have connected only a single one. Connecting GDB to the UART 0 of the Genode system makes no sense because this one is unrelated to the GDB monitor.

<start name="uart_drv"> <resource name="RAM" quantum="2M"/> <provides> <service name="Terminal"/> </provides> #is that service name "Terminal" should be "/dev/ttyS0" ?

The service name denotes the type of the session. The UART driver provides sessions of type "Terminal" and "Uart". (the "Uart" type is a specialized kind of "Terminal", not important here) In the Genode world "/dev/ttyS0" has no meaning.

<config>
	<policy label="gdb_monitor" uart="1"/>
</config>

</start>

This configuration tells the UART driver to hand out the second UART (UART 1) to the gdb_monitor client. The numbering starts at 0. UART 0 is typically used by the kernel and Genode's core.

Is that correct?

Does the run script works as intended on Qemu?

Maybe the serial was occupied by the system output?

I guess, you are putting your finger exactly on the issue.

Do you have a way to connect a second UART to your PC? If you consider using a PCI card with additional comports, you will need to make sure that the UART driver uses the I/O ports of the card. (by modifying the function 'io_port_base' in 'os/src/drivers/uart/i8250/main.cc'. You may determine the right values by booting Linux once and executing 'lspci'.

I admit, that sounds a bit awkward and complicated. Normally, you could use the TCP terminal ('gems/src/server/tcp_terminal') as an alternative to an UART interface when using GDB monitor. So there would be no need for multiple UART interfaces. (the TCP terminal provides the "Terminal" interface but works over TCP) Unfortunately, that's not possible when debugging the NIC driver because TCP terminal requires a NIC driver to work.

Cheers Norman

Hi Norman, You are right. It works. But sometimes it is slow, I guess there also has some information mess up the GDB protocal. Thank you very much.

Bests keqin

On ÐÇÆÚÒ», ËÄÔÂ 22, 2013 5:20 pm, Norman Feske wrote: ----------------------------------------------------------------------------------- Hello Keqin,

Can I just turn the Genode's LOG messages and the kernel messages off, then letthe GDB monitor use the UART0 channel? If I can, how to do that?

I assume that you are using Fiasco.OC? If yes, you may find the so-called kdb_uart_drv (at 'os/src/drivers/uart/kdb') useful. This is a pseudo-UART driver that uses the Fiasco.OC kernel debugger as backend. So all in/output will go through the UART interface used by the kernel, which happens to be UART 0. This way, you can direct the "Terminal" session used for the GDB protocol to the kernel debugger. Just replace the 'uart_drv' with the 'kdb_uart_drv' in the run script. For an example, please have a look at 'run/kdb_uart_drv.run'.

With 'uart_kdb_drv' in place, we still have the problem of the debug output of the kernel and core's LOG service polluting the UART 0. To silence core, you may just modify the '_out_char' function in 'base-foc/src/base/console/core_console.h'. This function is the back end for all console messages produced by core (either directly or indirectly via the LOG service). By removing the call to 'Fiasco::outchar(c)', you can suppress all those messages.

However, there may still be messages printed by the kernel, for example warnings that occurring during unmap operations. Those messages will probably mess up the GDB protocol. But maybe you are lucky and GDB will deal gracefully with them? Just give it a try.

Good luck!

Norman

Hi Norman, Thank you for the information. This optimization seems very important, I'm willing to follow your work. But I'm afraid I do not fully understand how the entire system working. Where can I get some detailed documentations about how does gdb_monitor work and how does fiasco.OC or Genode map memory for each app? I have been read several docs on the Genode website but still puzzled.

Regards keqin

On ÐÇÆÚ¶þ, ËÄÔÂ 23, 2013 5:47 pm, Norman Feske wrote: -----------------------------------------------------------------------------------

----------------------------------------------------------------------------------- Hi Keqin,

 You are right. It works. But sometimes it is slow, I guess there also has some

information mess up the GDB protocal. Thank you very much.

congratulations that you got it working!

Regarding the slowness, I can partially explain the current state. The main reason lies in the way how GDB monitor peeks and pokes in the target's address space. For each individual memory access, we traverse the target's memory-mapping structures, locally map the corresponding memory into the GDB monitor's address space, perform the access, and revert the mapping. When doing a debug operation such as a backtrace or memory dump, this sequence is performed over and over again. Consequently a lot of superfluous (and costly) map and unmap operations are performed. Obviously, there is the opportunity to optimize those memory accesses by the means of caching. I actually started to implement this optimization via a so-called 'Memory_model' in GDB monitor:

https://github.com/genodelabs/genode/blob/master/ports/src/app/gdb_monitor/g...

However, the implementation is not complete, yet. I.e., the cache gets not flushed when needed, which leads to coherency problems. For this reason, I have set NUM_MAPPED_REGIONS to just 1, effectively disabling the optimization. If you like to pick up the work where I left, you are more than welcome to increase the value and try to fix the remaining inconsistency issues. ;-)

Cheers Norman

Hi Keqin,

 Thank you for the information. This optimization seems very important, I'm

willing to follow your work. But I'm afraid I do not fully understand how the entire system working. Where can I get some detailed documentations about how does gdb_monitor work and how does fiasco.OC or Genode map memory for each app? I have been read several docs on the Genode website but still puzzled.

Indeed, the inner workings of GDB monitor requires a profound understanding of how Genode works. So maybe, from your perspective, it is not the most suitable topic to start right now. Anyway, I'd like to give to some pointers to start an investigation.

In Genode, the address-space layout of each process is represented by a Region-Manager session (RM session) provided by core. A RM session is similar to a page table but works on a higher level of abstraction. The RM service is briefly described in the documentation:

http://genode.org/documentation/architecture/core#RM_-_managing_address_spac...

However, this description to a bit sparse, in the mailing-list archive, you will find better coverage. I.e., the following thread is insightful:

http://sourceforge.net/mailarchive/forum.php?thread_name=007b01cc29fc%24d2b6...

The GDB monitor works by virtualizing the RM service that is normally provided by core using a local implementation. So all interactions of the debugging target with core can be monitored (and manipulated) by GDB monitor. We call this technique process-level virtualization. The concept is described in the release notes of version 11.11:

http://genode.org/documentation/release-notes/11.11#GDB_debugging_via_applic...

To get the big picture, it is certainly worthwhile to also skim over the surrounding text. The release notes are actually the best resource of documentation about Genode. To get an overview of all the topics covered, you may review the respective introduction sections of the least recent (let's say 8) releases. If a mentioned topic catches your interest, you can decide read the specific section. Btw, all release notes are present in the 'doc/' directory of Genode. So you can grep for the topics of your particular interest.

Have fun with exploring!

Cheers Norman