1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2013, 2016 Free Software
Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
(!) See also [[/glibc/debugging]].
Here are some hints about how to approach testing after nontrivial changes to
glibc have been done.
---
First step is having the build of glibc succeed. This is actually more
difficult than one might expect as it involves (towards the end of the build
process -- unless you are cross-compiling, of course -- that the
newly created libraries and loader actually work: they'll be used to run the
`rpcgen` program. If that step doesn't succeed, it'll look similar to this:
[...]
CPP='gcc -E -x c-header' [...]/build/elf/ld.so.1 --library-path [...] [...]/build/sunrpc/rpcgen [...]
Segmentation fault
---
Unless cross-compiling, the next thing you'll probably want to do
is running the test suite, or parts of it.
There is a list of [[known failures|open_issues/glibc]].
---
When building the debian glibc, to save yourself a double-compilation, comment
in debian/sysdeps/hurd-i386.mk the lines about xen. Then to avoid the whole
testsuite, use:
DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage
To save even more build, stop the build after configure has run, and then you
can restart the build of only libc.so and libc.a with:
make -C build-tree/hurd-i386-libc lib
or of only libc.so with:
make -C build-tree/hurd-i386-libc objdir=$PWD/build-tree/hurd-i386-libc $PWD/build-tree/hurd-i386-libc/libc.so
or of the whole tree with:
make -C build-tree/hurd-i386-libc
or of just one subdir with for instance:
make -C htl subdir=htl ..=../ objdir=$PWD/build-tree/hurd-i386-libc
(note that most subdirs need libc.so built)
Similarly, you can run the testsuite of a single directory the same way:
make check -C htl subdir=htl ..=../ objdir=$PWD/build-tree/hurd-i386-libc
---
In some cases, printing to stdout/stderr is problematic. One can use a kernel
with kdb enabled, and `mach_print` to get messages on the console:
#include <mach/mach_traps.h>
...
mach_print("foo\n");
If your `mach_traps.h` does not have the declaration, use:
extern void mach_print(const char *s);
If you can't use the libc-provided `mach_print` for some reason, you can use as last resort:
asm("\
my_mach_print:\n\
mov $-30,%eax\n\
lcall $7,$0\n\
ret\n\
");
extern void my_mach_print(const char *s);
This call does not support any formatting. You can use this kind of helper to
format a message before passing to gnumach:
#include <mach/mach_traps.h>
#include <stdio.h>
static void myprintf(const char *fmt, ...)
{
va_list ap;
char buf[1024];
va_start(ap, fmt);
vsnprintf(buf, sizeof(buf), fmt, ap);
mach_print(buf);
va_end(ap);
}
---
If you've been doing simple changes to glibc functions that end up in
`libc.so`, you may test them like this (like for a `strerror_l` implementation
in this case):
$ LD_PRELOAD=./libc.so ./ld.so ./a.out 10 1073741928 de_DE.utf8
1073741928 (0x40000068): Computer bought the farm
1073741928 (0x40000068): Der Computer hat den Bauernhof erworben
You usually will only have luck using the new `libc.so` (from
`[glibc-build]/libc.so`) in combination together with the new `ld.so` (from
`[glibc-build]/elf/ld.so`):
$ LD_PRELOAD=./libc.so ./a.out 10 1073741928 de_DE.utf8
Killed
$ LD_PRELOAD=./libc.so /lib/ld.so ./a.out 10 1073741928 de_DE.utf8
Killed
Make sure static linking is working OK at all. Running the
`[glibc-build]/elf/sln` program (a stripped-down `ln` that is statically
linked) ought to test that. Also, static linking under various conditions will
already have been tested when running the test suite, especially in `elf/` and
`dlfcn/`.
Make sure static linking with cthreads is working. If you can get an
`ext2fs.static` compiled and linked against the new glibc, that is good.
[TODO].
Then debug its startup as a normal program on your working hurd.
$ [...]/ext2fs.static --help
[...]
Then try its full server startup.
$ settrans -ca node [...]/ext2fs.static BACKING_STORE
$ ls -l node/
[...]
Make sure dynamic linking for servers is working. If you haven't broken the
ABI, you can just use an existing `/hurd/foobar` binary, started the way
glibc's `testrun.sh` does it.
[TODO]: Is this the correct way to do that?
$ settrans -ca node [glibc]/build/testrun.sh /hurd/ext2fs BACKING_STORE
$ cd node/
[...]
---
Test it in a [[subhurd]].
---
Test it on a real system.
|
