Debugging with symbols and source

[Polaris Rhapsody]

Hi,

I have noticed at the following page:

http://wiki.minix3.org/DevelopersGuide/Debugging

that:

Compiling executables (and their libraries) you want debugged with -g helps a lot - it gives more source code line info and less weird optimization things happen. Specify DBG=-g on the make line to enable this, verify it does what you want by adding MAKEVERBOSE=2.

After adding MAKEVERBOSE=2, it revealed that the C compiler being used is clang. A few questions:

1. Can gdb work with binaries built by clang (loading symbols from it, etc.) the same way as it does with those built by gcc?

2. If answer to Q1 is no, then how to replace clang with gcc?

3. What does it mean by "Specify DBG=-g on the make line"? I set DBG=-g in environment variables, but from the clang command line it doesn't seem to have been applied.

Thanks,
Polaris

[Antoine LECA]

Polaris Rhapsody wrote:
> 1. Can gdb work with binaries built by clang (loading symbols from it,
> etc.) the same way as it does with those built by gcc?

As far as I know, it always did and does, particularly since both are
relying on the same set of "binutils".

> 2. If answer to Q1 is no, then how to replace clang with gcc?

Even if the answer is yes, the key is to add
CC=gcc
in the strategic place; there are three main ways to do it
1) in the environment before calling make/nbmake*/build.sh (not sure it
works the best way, since it has the least precedence);
2) on the command line of make/nbmake*, or using build.sh -V CC=gcc
3) within /etc/mk.conf (or /etc/make.conf, depends on releases)

> 3. What does it mean by "Specify DBG=-g on the make line"? I set DBG=-g in
> environment variables, but from the clang command line it doesn't seem to
> have been applied.

This is supposed to be (one of) the way to go, as explained above.

Hmmm, this problem is something I have seen sometimes in the past. But I
cannot reproduce it right now, with some "3.2.1" version dated from
several months ago (i.e., aligned with NetBSD tree.)

Can you be more specific about the version you are using?
Also, updating your system to -current, and also your packages as well
(`pkgin fug`) might help, first because the problem might vanish if it
has been corrected in the tree meanwhile, and second because if there is
still a problem, -current is where it should and will be corrected.

Also, there is still a problem if you are using MKSMALL=yes inside the
make arguments (i.e., with more priority than from the environment),
since it "erases" the value of DBG from the environment; the solution in
that (corner) case is to use build.sh, or
make MKSMALL=yes DBG=-g ...


Do not forget when using DBG=-g that you should force the rebuild of all
the libraries with that -g setting, else you would loose much of the
debugging information.
Also there is another setting, MKDEBUGLIBS, which is off by default but
would allow the building of alternate libraries, compiled with -DDEBUG;
however I do not know how to force the use of them instead of the
regular ones... looks like a semi-broken feature to me.

Thanks for your help.


Antoine

[Polaris Rhapsody]

Thanks so much for such a detailed reply. I was using 3.2.1, but it might be due to my own mistake that -g was not showing up during compilation. I will check that out.

 

My goal is to understand MINIX3 from bottom up, and I thought remote debugging in another OS would greatly help in this process. With that goal in mind, I'm trying to make remote debugging a process as painless as possible, thus the need for the "-g" flag. Now that you mentioned "force rebuild of all libraries", etc., is there a most painless way to rebuild everything with the "-g" flag, including all libraries? I'm more than happy to trade "painless" and "worry free" over build time, since understanding the build system is a second priority for me at this time.

 

Regards,

Polaris

[Lionel Sambuc]

Hi,


If you are using the cross-compilation scripts, you can do the following:

$ BUILDVARS='-V DBG="-g -O0"' ./releasetools/x86_hdimage.sh

This will build the whole system and genarate a disk image which you can boot. With the
BUILDVARS variable you can pass make variables, which are used to parameter the build.

That command will build the whole system with debug symbols. To speed things up you can also
add JOBS=<#of parallel jobs> before BUILDVARS.


Regards,

Lionel

> --
> You received this message because you are subscribed to the Google Groups "minix3" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Polaris Rhapsody]

I intend to run it on x86 qemu. I know the cross compilation script would be suitable for ARM, but would it also work for x86?

 

Regards,

Polaris

[Polaris Rhapsody]

I'm using 3.2.1. Just checked and there is no such script under /usr/src:

releasetools/x86_hdimage.sh

are you referring to a more recent build?

[Lionel Sambuc]

Hi,


Yes this is a recent development, I would recommend for you to clone the git repository and work on master.


Regards,

Lionel

[keesj]

On Monday, December 9, 2013 8:56:12 AM UTC+1, Polaris Rhapsody wrote:

Hi,

I have noticed at the following page:

http://wiki.minix3.org/DevelopersGuide/Debugging

Hi,

I also created  a video about this

http://www.youtube.com/watch?v=Wni_Yw-2b88&list=PL2JiIx7dnbsG09NsK8Rbd9GHqoREz6hKK&index=2

Greetings

[Polaris Rhapsody]

Thanks to all for the help. I will give it a try tonight.

[Polaris Rhapsody]

I followed exactly the same steps:

1. enlist latest minix3 source from git.minix3.org
2. cross compiling it using the below BUILDVARS and script you gave me
3. successfully produced an image:

To boot this image on kvm:
cd ../obj.i386/destdir.i386/multiboot && kvm -serial stdio -kernel kernel -append "console=tty00 rootdevname=c0d0p1" -initrd "mod01_ds,mod02_rs,mod03_pm,mod04_sched,mod05_vfs,mod06_memory,mod07_log,mod08_tty,mod09_mfs,mod10_vm,mod11_pfs,mod12_init" -hda /home/chu7/minix/src/minix_x86.img

4. I don't have kvm, so I used qemu instead. the script I used was:

qemu -serial stdio -kernel kernel -append "console=tty00 rootdevname=c0d0p1" -initrd "mod01_ds,mod02_rs,mod03_pm,mod04_sched,mod05_vfs,mod06_memory,mod07_log,mod08_tty,mod09_mfs,mod10_vm,mod11_pfs,mod12_init" -hda /home/chu7/minix/minix_x86.img

5. booting seemed to fail to mount some partitions and eventually failed with the following:

chu7@chu7-x200s ~/minix/obj.i386/destdir.i386/multiboot $ ./qemu
MINIX booting
acpi: returning 0x7ffff80 as vir addr
acpi: returning 0x7ffe4f0 as vir addr
acpi: Could not read S5 data. Use default SLP_TYPa and SLP_TYPb
APIC disabled, using legacy PIC

MINIX 3.2.1. Copyright 2012, Vrije Universiteit, Amsterdam, The Netherlands
MINIX is open source software, see http://www.minix3.org
Initiating legacy i8253 timer
CPU 0 freq 1851 MHz
kernel: selecting intel sysenter ipc style
Started VFS: 8 worker thread(s)
Root device name is /dev/c0d0p1
/dev/c0d0p1: clean
/dev/c0d0p1 is mounted on /
none is mounted on /proc
/sbin/readclock.drv: no such file or directory
service: couldn't get stat binary
date: timed: no such device or address
Tue Jan  1 00:00:00 GMT 2013
/dev/c0d0p2: clean
/dev/c0d0p3: clean
Can't mount on /usr
ramdisk: not found
Failed to free boot ramdisk
/usr/sbin/rs: no such file or directory
service: couldn't get stat binary
/usr/sbin/vm: no such file or directory
service: couldn't get stat binary
/usr/sbin/pm: no such file or directory
service: couldn't get stat binary
/usr/sbin/sched: no such file or directory
service: couldn't get stat binary
/usr/sbin/vfs: no such file or directory
service: couldn't get stat binary
/usr/sbin/ds: no such file or directory
service: couldn't get stat binary
/usr/sbin/tty: no such file or directory
service: couldn't get stat binary
/usr/sbin/memory: no such file or directory
service: couldn't get stat binary
/usr/sbin/log: no such file or directory
service: couldn't get stat binary
/usr/sbin/pfs: no such file or directory
service: couldn't get stat binary
/usr/sbin/init: no such file or directory
service: couldn't get stat binary
touch: not found
Multiuser startup in progress ...
Starting hotplugging infrastructure... devmand: not found
done.
No space on device 3/2
init: /etc/utmp: no space left on device
 Minix  Release 3 Version 2.1  (console)

minix login: init: /etc/utmp: no space left on device
init: /etc/utmp: no space left on device
init: /etc/utmp: no space left on device


The issue seems to lie within the disk image, but I don't know for sure. Have you seen this before? Could you please give me some pointers?

Regards,
Polaris

On Monday, December 9, 2013 2:39:18 PM UTC-8, Lionel Sambuc wrote:

[Polaris Rhapsody]

I think I know the cause now. x86_hdimage.sh is trying to make the root partition as tight as possible, but not considering the fact that building with -g -O0 will increase binary sizes, causing partition overflow, leading to a corrupt hd image. I will adjust the root partition size to fit my needs.

===> Successful make distribution
===> build.sh ended:      Fri Dec 13 01:06:06 PST 2013
===> Summary of results:
     build.sh command:    build.sh -V SLOPPY_FLIST=yes -V MKBINUTILS=yes -V MKGCCCMDS=yes -j 1 -m i386 -O ../obj.i386 -D ../obj.i386/destdir.i386 -V DBG=-g -O0 -U -u distribution
     build.sh started:    Fri Dec 13 00:19:37 PST 2013
     MINIX version:       3.2.1
     MACHINE:             i386
     MACHINE_ARCH:        i386
     Build platform:      Linux 3.8.0-19-generic x86_64
     HOST_SH:             /bin/sh
     No $TOOLDIR/bin/nbmake, needs building.
     Bootstrapping nbmake
     TOOLDIR path:        /home/chu7/minix/src/../obj.i386/tooldir.Linux-3.8.0-19-generic-x86_64
     DESTDIR path:        /home/chu7/minix/src/../obj.i386/destdir.i386
     RELEASEDIR path:     /home/chu7/minix/src/../obj.i386/releasedir
     Created /home/chu7/minix/src/../obj.i386/tooldir.Linux-3.8.0-19-generic-x86_64/bin/nbmake
     Updated makewrapper: /home/chu7/minix/src/../obj.i386/tooldir.Linux-3.8.0-19-generic-x86_64/bin/nbmake-i386
     Successful make distribution
     build.sh ended:      Fri Dec 13 01:06:06 PST 2013
===> .
creating the file systems
Writing Minix filesystem images
 - ROOT
nbmkfs.mfs: File system not big enough for all the files: No such file or directory
nbmkfs.mfs: Line 655 being processed when error detected.

./releasetools/x86_hdimage.sh: line 149: /512: syntax error: operand expected (error token is "/512")
 - USR
../obj.i386/tooldir.Linux-3.8.0-19-generic-x86_64/bin/nbmkfs.mfs: Can't open ../obj.i386/destdir.i386/usr/man/man1/nm.1: No such file or directory
 - HOME
Part     First         Last         Base      Size       Kb
  0      0/000/00     0/000/07         0         8        4
  1      0/000/08    64/000/07         8    131072    65536
  2     64/000/08  1600/000/07    131080   3145728  1572864
  3   1600/000/08  1728/000/07   3276808    262144   131072

To boot this image on kvm:
cd ../obj.i386/destdir.i386/multiboot && kvm -serial stdio -kernel kernel -append "console=tty00 rootdevname=c0d0p1" -initrd "mod01_ds,mod02_rs,mod03_pm,mod04_sched,mod05_vfs,mod06_memory,mod07_log,mod08_tty,mod09_mfs,mod10_vm,mod11_pfs,mod12_init" -hda /home/chu7/minix/src/minix_x86.img

[Lionel Sambuc]

Hi Polaris,


You also have an error:

> ./releasetools/x86_hdimage.sh: line 149: /512: syntax error: operand expected (error token is "/512")

Did you edit the script? If not, then use bash/zsh when executing the script.

The simplest in your case is to use the following:

$ USR_SIZE=<x> ROOT_SIZE=<y> BUILDVARS='-V DBG="-g -O0"' ./releasetools/x86_hdimage.sh

<x> and <y> being the sizes you want for /usr and /, respectively. Those are values expressed in disk blocks (512bytes).

For references, here are the default settings the script uses:
- ROOT: 64MB,
- HOME: 128MB,
- USR: 1.5GB.

Below, the corresponding part of the script:

# All sized are written in 512 byte blocks
#
# we create a disk image of about 2 gig's
# for alignment reasons, prefer sizes which are multiples of 4096 bytes
#
: ${ROOT_SIZE=$(( 64*(2**20) / 512))}
: ${HOME_SIZE=$(( 128*(2**20) / 512))}
: ${USR_SIZE=$(( 1536*(2**20) / 512))}


Regards,

Lionel

[Polaris Rhapsody]

Yes, you are right. I have adjusted the partition sizes, and now it works like a charm. I have gdb working with symbols and source. Thanks to everyone for the help!

[Polaris Rhapsody]

The same build command doesn't seem to work with the latest snapshot (commit 92dfb2dc8e10130f50447d3e477eda0267cc19ec). Error logs pasted below.

What command can I use to build a latest X86 hd image with "-g -O0" to facilitate debugging, with custom root and user partition size, on Ubuntu Xenial? Once built, where can the hd image be found? Thanks!

$ cat /etc/os-release 

NAME="Ubuntu"

VERSION="16.04 LTS (Xenial Xerus)"

ID=ubuntu

ID_LIKE=debian

PRETTY_NAME="Ubuntu 16.04 LTS"

VERSION_ID="16.04"

HOME_URL="http://www.ubuntu.com/"

SUPPORT_URL="http://help.ubuntu.com/"

BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

UBUNTU_CODENAME=xenial

$ USR_SIZE=$((  5*(2**30) )) ROOT_SIZE=$((  3*(2**30) )) BUILDVARS='-V DBG="-g -O0"' ./releasetools/x86_hdimage.sh

Going to build Minix source code...

===> build.sh command:    build.sh -j 1 -m i386 -O ../obj.i386 -D ../obj.i386/destdir.i386 -V DBG="-g -O0" -U -u release

===> build.sh started:    Mon Sep 19 22:52:24 PDT 2016

===> MINIX version:       3.4.0

===> MACHINE:             i386

===> MACHINE_ARCH:        i386

===> Build platform:      Linux 4.4.0-21-generic x86_64

===> HOST_SH:             /bin/sh

===> No $TOOLDIR/bin/nbmake, needs building.

===> Bootstrapping nbmake

.....

cc  -O -o nbmake *.o  

===> MAKECONF file:       /etc/mk.conf (File not found)

/bin/sh: 1: Syntax error: Unterminated quoted string

*** Failed target:  _x_

*** Failed command: echo /home/workbench/minixsrc/0"

ERROR: bomb_getmakevar MAKEOBJDIR: /tmp/nbbuild25449/nbmake failed

*** BUILD ABORTED ***

[Antoine LECA]

On 20/09/2016 05:59Z, Polaris Rhapsody wrote:
> ===> MAKECONF file: /etc/mk.conf (File not found)
> /bin/sh: 1: Syntax error: Unterminated quoted string
>
> *** Failed target: _x_

You want to correct that one first, independently of your problem.

The NetBSD build system which MINIX uses, and the *BSD pmake/make/bmake
program under it, has a hard-wired "feature" to read very early while
processing the makefiles, the file /etc/mk.conf, and interprets it as
bmake(1) commands. The feature is, it does so even while
cross-compiling, even when run on a completely foreign platform. To all
effects, it means that system file is /reserved/ to *BSD make.

From the message you saw, it seems that on your machine, that file
exists and might contain strings which *BSD make cannot make sense of.
So in order to make any use of MINIX, you'll have to "clean up" that
file to run MINIX build system.

Antoine

[Polaris Rhapsody]

/etc/mk.conf doesn't exist on my system:

$ ls /etc/mk.conf

ls: cannot access '/etc/mk.conf': No such file or directory

The simplest command works just fine:

$ bash ./releasetools/x86_hdimage.sh

However, with the additional env parameter, it fails with the same error:

$ BUILDVARS='-V DBG="-g -O0"' bash ./releasetools/x86_hdimage.sh

[Sambuc Lionel]

The problem comes from the double quotes, here:
DBG="-g -O0"

You have to escape them, as that variable goes through several interpolations, among them at least:
1. from the shell, as it puts the variable in the environment of x86_hdimage.sh
2. within that script as the argument is passed to build.sh
3. within build.sh as it creates the BSD make variable which is used in the end.

Kind regards

> --
> You received this message because you are subscribed to the Google Groups "minix3" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[Antoine LECA]

On 20/09/2016 22:20Z, Polaris Rhapsody wrote:
> /etc/mk.conf doesn't exist on my system:
>

> The simplest command works just fine:
> $ bash ./releasetools/x86_hdimage.sh
>
> However, with the additional env parameter, it fails with the same error:
> $ BUILDVARS='-V DBG="-g -O0"' bash ./releasetools/x86_hdimage.sh

Ok, sorry I did not understand what was happened. Now I get it.

Well, in your case, /etc/mk.conf could end bein a nice solution: just
put the variable there, and it would have the same effect as BUILDVARS
$ echo>/etc/mk.conf "DBG+=-g -O0"
(notice the " won't be in the mf.conf file.)

If this trick works, or if it does not, please report it, since it is
possible others could have similar issues.


Antoine

[Polaris Rhapsody]

Yes, I confirm that with your trick, I was able to build an hd image successfully, with "-g -O0":

$ cat /etc/mk.conf 

DBG+=-g -O0

With above, my full command line was:

$ USR_SIZE=$((  5*(2**30) )) ROOT_SIZE=$((  3*(2**30) )) ./releasetools/x86_hdimage.sh

Thanks a lot for the tip!