Archive for the 'Q&A' Category

Browsing the PCI bus

Gilad Ben-Yossef May 20th, 2008

Another letter from one of our students, this time from Ami Givati from Intel:

Hello Gilad,

Knowing your Linux expertise (from Intel Network training last month, and a Linux debug class), I think you should be able to help me with this:

I am looking for a Linux tool which will allow me to browse the PCI (and mainly PCI Express) hierarchy. I need to view the hierarchy tree, and to read and modify values in the PCI Config space of various devices. A GUI tool is preferred, but also a command line would be of value. Are you familiar with such a tool?

Appreciate your help…

Well Ami, the answer is easier then you might think - you can simply use one of the Linux shells.

You see, Linux exposes the PCI (actually all hardware buses) hierarchy as simple files and directories udner the sysfs virtual file system and let you access them simply from the shell.

Of course, you can easily wrap a GUI around it but access via the Linux shell is easy enough, for example:

gby@voyager:~$ cd /sys/
gby@voyager:/sys$ cd devices/
gby@voyager:/sys/devices$ ls
acpi_system:00  pci0000:00  platform  pnp0  system
gby@voyager:/sys/devices$ cd pci0000\:00/
gby@voyager:/sys/devices/pci0000:00$ ls
0000:00:00.0  0000:00:1a.1  0000:00:1c.2  0000:00:1d.2  0000:00:1f.3
0000:00:02.0  0000:00:1a.7  0000:00:1c.3  0000:00:1d.7  power
0000:00:02.1  0000:00:1b.0  0000:00:1c.4  0000:00:1e.0  uevent
0000:00:19.0  0000:00:1c.0  0000:00:1d.0  0000:00:1f.0
0000:00:1a.0  0000:00:1c.1  0000:00:1d.1  0000:00:1f.2
gby@voyager:/sys/devices/pci0000:00$ cd 0000:00:1d.0
gby@voyager:/sys/devices/pci0000:00/0000:00:1d.0$ ls
broken_parity_status  enable      pools             subsystem_vendor
bus                   irq         power             uevent
class                 local_cpus  resource          usb3
config                modalias    resource4         usb_host:usb_host3
device                msi_bus     subsystem         vendor
driver                numa_node   subsystem_device
gby@voyager:/sys/devices/pci0000:00/0000:00:1d.0$ hexdump config
0000000 8086 2830 0005 0280 0003 0c03 0000 0080
0000010 0000 0000 0000 0000 0000 0000 0000 0000
0000020 18a1 0000 0000 0000 0000 0000 17aa 20aa
0000030 0000 0000 0000 0000 0000 0000 010a 0000
0000040

For more details about the PCI sections of sysfs, check out the sysfs-pci.txt file in the Linux documentation.

And anyone else has a question, don’t hesitate to let us know.

Hope this helps,
Gilad

Reducing the size of dynamic libraries

Gilad Ben-Yossef May 15th, 2008

Today we have a special reader request from an anonymous reader (slightly edited):


Hello,

Can you help me with some link issue which I face?

I need to compile tree of c-sources which produce .so files and exe
files. I want to decrease the sizes of .so by throwing away unused symbols.

I can compile my tree statically and used as compiler flags –static -ffunction-sections -fdata-sections and link with –gc-sections option and it reduces all the unneeded symbols but I want to achieve the same effect in dynamic linking.

Do you know some efficient way to do it?

Thanks,
Anonymous Reader

So the question is: how to make a minimal set of dynamic libraries for a known set of executables that only contain the code for those symbols which the executables actually use, thus saving expensive storage?

The quite simple answer is that there exists a Python utility that does exactly what you want called mklibs - It produces cut-down shared libraries that contain only the routines required by a particular set of executables.

On Debian just go “sudo apt-get install mklibs”, or you can get the source straight from the Buildroot source repository here.

If you don’t like Python (you really should!) you can try an older, shell script based variation on the same theme found here.

Note that you can pass the cross compiler prefix with the “–target” option, which is of course needed for supporting cross compilation.

Hope you found it useful and if you have more questions about Linux development you’d like answered, just let us know.

This post originally appeared in the Codefidence Technoblog