Re: kernel compile message

[Anatoly Pugachev]

On Mon, Oct 31, 2022 at 5:06 PM Anatoly Pugachev  wrote:
>
> got it again...
>

tracked it to

mator@ttip:~/linux-2.6$ rm include/config/auto.conf.cmd
mator@ttip:~/linux-2.6$ make V=1 include/config/auto.conf.cmd
: "  SYNCinclude/config/auto.conf.cmd"
make -f ./Makefile syncconfig
make[1]: /bin/sh: Bad address
make -f ./scripts/Makefile.build obj=scripts/basic
make -f ./scripts/Makefile.build obj=scripts/kconfig syncconfig
scripts/kconfig/conf  --syncconfig Kconfig
make: 'include/config/auto.conf.cmd' is up to date.

trying "syncconfig":

mator@ttip:~/linux-2.6$ rm include/config/auto.conf.cmd
mator@ttip:~/linux-2.6$ make V=1 -f ./Makefile syncconfig
make -f ./scripts/Makefile.build obj=scripts/basic
make -f ./scripts/Makefile.build obj=scripts/kconfig syncconfig
scripts/kconfig/conf  --syncconfig Kconfig
mator@ttip:~/linux-2.6$

^^ no error...

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: kernel compile message

[Anatoly Pugachev]

got it again...

mator@ttip:~/linux-2.6$ make V=1 -j olddefconfig; nice make -j20 &&
nice make -j20 modules
make -f ./scripts/Makefile.build obj=scripts/basic
make -f ./scripts/Makefile.build obj=scripts/kconfig olddefconfig
scripts/kconfig/conf  --olddefconfig Kconfig
#
# No change to .config
#
  SYNCinclude/config/auto.conf.cmd
make[1]: /bin/sh: Bad address
^Cmake: *** [include/config/auto.conf.cmd] Deleting file
'include/generated/rustc_cfg'
make: *** [include/config/auto.conf.cmd] Deleting file
'include/generated/autoconf.h'
make[2]: *** [scripts/kconfig/Makefile:77: syncconfig] Interrupt
make[1]: *** [Makefile:697: syncconfig] Interrupt
make: *** [Makefile:798: include/config/auto.conf.cmd] Interrupt

mator@ttip:~/linux-2.6$ make V=1 -j olddefconfig
make -f ./scripts/Makefile.build obj=scripts/basic
make -f ./scripts/Makefile.build obj=scripts/kconfig olddefconfig
scripts/kconfig/conf  --olddefconfig Kconfig
#
# No change to .config
#



so it's only seen when/after   "SYNCinclude/config/auto.conf.cmd" ...
but I don't have this file... How do I enable SYNC config on make ?
And V=1 does not help...

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: kernel compile message

[Anatoly Pugachev]

On Sun, Oct 30, 2022 at 3:33 AM Mulyadi Santosa
 wrote:
> On Tue, Oct 25, 2022, 16:29 Anatoly Pugachev  wrote:
>>
>> Hello!
>>
>> Doing kernel testing, occasionally I started to get messages:
>>
>> mator@ttip:~/linux-2.6$ make -j olddefconfig; nice make -j20 && nice
>> make -j20 modules
>> #
>> # configuration written to .config
>> #
>>   SYNCinclude/config/auto.conf.cmd
>> make[1]: /bin/sh: Bad address
>>   UPD include/generated/compile.h
>>   UPD include/config/kernel.release
>>   UPD include/generated/utsrelease.h
>>
>>
>> It is not always "bad address" is shown, next time i run "make
>> olddefconfig" it does not shows, but sometimes it shows... How do i
>> debug this ?
>
>
> Sounds like bad RAM to me

is a VM... and if it would be "bad ram" there would be random program
segfaults and kernel OOPS all around...
But thanks anyway, going to use "V=1"

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

kernel compile message

[Anatoly Pugachev]

Hello!

Doing kernel testing, occasionally I started to get messages:

mator@ttip:~/linux-2.6$ make -j olddefconfig; nice make -j20 && nice
make -j20 modules
#
# configuration written to .config
#
  SYNCinclude/config/auto.conf.cmd
make[1]: /bin/sh: Bad address
  UPD include/generated/compile.h
  UPD include/config/kernel.release
  UPD include/generated/utsrelease.h


It is not always "bad address" is shown, next time i run "make
olddefconfig" it does not shows, but sometimes it shows... How do i
debug this ?

Thanks

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: Kernel bug tracker

[Anatoly Pugachev]

On Sun, Aug 29, 2021 at 10:04 AM Adverg Ebashinskii  wrote:
>
> Hello.
>
> I’m a kernel newbie and try to get involved into the Kernel development. So 
> I’d like to start with small bug fixes related to any subsystem (fs is 
> preferred since I familiar with it the most) or something like that.
>
> Is there some kernel bug tracker where anybody could pick a bug to fix and 
> then send patches?

https://bugzilla.kernel.org/

There's as well per linux distribution / vendor bug reporting web
interfaces, like http://bugs.debian.org/ and/or
https://bugs.launchpad.net/
https://bugzilla.redhat.com/ where users could first post their bugs

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [OSSNA] Intro to kernel hacking tutorial

[Anatoly Pugachev]

On Mon, Sep 2, 2019 at 5:09 PM Valdis Klētnieks  wrote:
>
> On Mon, 02 Sep 2019 15:42:19 +0300, Anatoly Pugachev said:
>
> > is it intentionally that you use
> >
> > yes "" | make oldconfig
> >
> > instead of
> >
> > make olddefconfig
>
> They do something different.  'olddefconfig' just takes the platform or
> architecture defconfig and updates it for any new CONFIG_* variables added
> since the last time the defconfig was updated in the tree.
>
> yes "" | make oldconfig  does the same updating for new CONFIG_* variables, 
> but
> starts with the most recent .config - which produces wildly different results
> if the .config had previously been minimized by 'make localmodconfig' or other
> similar techniques.

Maybe i don't understand something, but someone would probably want to
patch kernel 'make help' accordingly , since current one lists:

$ make help
  oldconfig   - Update current config utilising a provided .config as base
  olddefconfig- Same as oldconfig but sets new symbols to their
default value without prompting

Thanks.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: [OSSNA] Intro to kernel hacking tutorial

[Anatoly Pugachev]

On Mon, Sep 2, 2019 at 4:52 AM Tobin C. Harding  wrote:
>
> On Sun, Sep 01, 2019 at 05:30:23AM +0530, Amit Kumar wrote:
> > Hi,
> > I think now your tutorial should be ready.
>
> I do  not understand what this means sorry.  Is it a request for action?
> The tutorial was a couple of weeks ago now, here is a link to the
> material if that is what you were asking
>
> https://github.com/tcharding/kernel/tree/master/workshop

Tobin,

is it intentionally that you use

yes "" | make oldconfig

instead of

make olddefconfig

in some of your docs ? ( tutorial/cheat-sheet.rst , tutorial/trouble-shoot.rst )

Want me to create/submit PR on github with 'make olddefconfig' ?

Thanks.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[sparc64] number of processors in a LDOM

[Anatoly Pugachev]

Hello!

Can someone tell me or suggest why does getconf returns total available to
a physical machine cpu count, and not LDOM allocated processor/vcpu count ?

ttip$ getconf -a | grep PROCESSORS
_NPROCESSORS_CONF  256
_NPROCESSORS_ONLN  16

i believe, nproc (from coreutils) use getconf as well :

ttip$ nproc --all
256

ttip$ nproc
16

But this LDOM is defined as following (16 vcpus allocated):

# ldm list
NAME STATE  FLAGS   CONSVCPU  MEMORY   UTIL  NORM
UPTIME
ttip active -n  50041632G  0.0%  0.0%  3h 1m


Just to compare, if we take power systems (ppc64) LPAR, it reports only
LPAR allocated CPU count (not physical machine available cpu/core count).

I'm raising this issue, because some userspace tools use nproc to run
parallel make for example. And starting from 4.15+ (but not on 4.14) kernel
overcommited CPU usage (for example, using make -j256 on a LDOM with 16
vcpus allocated) gets me to the following (reproducible):

Message from syslogd@ttip at Apr  3 14:53:15 ...
 kernel:[  942.850499] BUG: workqueue lockup - pool cpus=8 node=0
flags=0x0 nice=0 stuck for 36s!
Apr 03 14:53:15 ttip kernel: BUG: workqueue lockup - pool cpus=8
node=0 flags=0x0 nice=0 stuck for 36s!
Apr 03 14:53:15 ttip kernel: Showing busy workqueues and worker pools:
Apr 03 14:53:15 ttip kernel: workqueue mm_percpu_wq: flags=0x8
Apr 03 14:53:15 ttip kernel:   pwq 16: cpus=8 node=0 flags=0x0 nice=0
active=1/256
Apr 03 14:53:15 ttip kernel: pending: vmstat_update
Apr 03 14:53:15 ttip kernel: workqueue xfs-sync/dm-0: flags=0x4
Apr 03 14:53:15 ttip kernel:   pwq 0: cpus=0 node=0 flags=0x0 nice=0
active=1/256
Apr 03 14:53:15 ttip kernel: pending: xfs_log_worker [xfs]
^C
Message from syslogd@ttip at Apr  3 14:53:45 ...
 kernel:[  972.929725] BUG: workqueue lockup - pool cpus=8 node=0
flags=0x0 nice=0 stuck for 66s!

Message from syslogd@ttip at Apr  3 14:54:15 ...
 kernel:[ 1003.008979] BUG: workqueue lockup - pool cpus=8 node=0
flags=0x0 nice=0 stuck for 96s!

Message from syslogd@ttip at Apr  3 14:54:46 ...
 kernel:[ 1033.088189] BUG: workqueue lockup - pool cpus=8 node=0
flags=0x0 nice=0 stuck for 126s!

Message from syslogd@ttip at Apr  3 14:55:16 ...
 kernel:[ 1063.166574] BUG: workqueue lockup - pool cpus=8 node=0
flags=0x0 nice=0 stuck for 156s!

Message from syslogd@ttip at Apr  3 14:55:46 ...
 kernel:[ 1093.244982] BUG: workqueue lockup - pool cpus=8 node=0
flags=0x0 nice=0 stuck for 186s!

This messages occasionally lead to machine/LDOM being unstable, i.e.
with some lockups to processes.

filtered dmesg output:

ttip$ dmesg  | egrep -i "cpu|smp"
[0.73] Linux version 4.16.0-05456-g17dec0a94915 (mator@ttip)
(gcc version 7.3.0 (Debian 7.3.0-14)) #659 SMP Wed Apr 4 12:16:32 MSK
2018
[0.037199] PLATFORM: max-cpus [1024]
[0.194415] CPU CAPS: [flush,stbar,swap,muldiv,v9,blkinit,n2,mul32]
[0.194525] CPU CAPS: [div32,v8plus,popc,vis,vis2,ASIBlkInit,fmaf,vis3]
[0.194630] CPU CAPS: [hpc,ima,pause,cbcond,aes,des,kasumi,camellia]
[0.194731] CPU CAPS: [md5,sha1,sha256,sha512,mpmul,montmul,montsqr,crc32c]
[0.237948] percpu: Embedded 12 pages/cpu @(ptrval) s56584
r8192 d33528 u131072
[0.238199] pcpu-alloc: s56584 r8192 d33528 u131072 alloc=1*4194304
[0.238209] pcpu-alloc: [0] 000 001 002 003 004 005 006 007 008 009
010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026
027 028 029
030 031
[0.238363] pcpu-alloc: [0] 032 033 034 035 036 037 038 039 040 041
042 043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058
059 060 061
062 063
[0.238515] pcpu-alloc: [0] 064 065 066 067 068 069 070 071 072 073
074 075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090
091 092 093
094 095
[0.238668] pcpu-alloc: [0] 096 097 098 099 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
[0.238820] pcpu-alloc: [0] 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
[0.238973] pcpu-alloc: [0] 160 161 162 163 164 165 166 167 168 169
170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186
187 188 189
190 191
[0.239125] pcpu-alloc: [0] 192 193 194 195 196 197 198 199 200 201
202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218
219 220 221
222 223
[0.239278] pcpu-alloc: [0] 224 225 226 227 228 229 230 231 232 233
234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250
251 252 253
254 255
[0.239873] SUN4V: Mondo queue sizes [cpu(131072) dev(16384) r(8192) nr(256)]
[0.242373] log_buf_len individual max cpu contribution: 4096 bytes
[0.242438] log_buf_len total cpu_extra contributions: 1044480 bytes
[0.516414] smp: Bringing up secondary CPUs ...
[0.548006] smp: Brought up 1 node, 16 CPUs

___
Kernelnewbies mailing list

[sparc64] number of processors in a LDOM

[Anatoly Pugachev]

Hello!

Can someone tell me or suggest why does getconf returns total available to
a physical machine cpu count, and not LDOM allocated processor/vcpu count ?

ttip$ getconf -a | grep PROCESSORS
_NPROCESSORS_CONF  256
_NPROCESSORS_ONLN  16

i believe, nproc (from coreutils) use getconf as well :

ttip$ nproc --all
256

ttip$ nproc
16

But this LDOM is defined as following (16 vcpus allocated):

# ldm list
NAME STATE  FLAGS   CONSVCPU  MEMORY   UTIL  NORM
UPTIME
ttip active -n  50041632G  0.0%  0.0%  3h 1m


Just to compare, if we take power systems (ppc64) LPAR, it reports only
LPAR allocated CPU count (not physical machine available cpu/core count).

I'm raising this issue, because some userspace tools use nproc to run
parallel make for example. And starting from 4.15+ (but not on 4.14) kernel
overcommited CPU usage (for example, using make -j256 on a LDOM with 16
vcpus allocated) gets me to the following (reproducible):

Message from syslogd@ttip at Apr  3 14:53:15 ...
 kernel:[  942.850499] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0
nice=0 stuck for 36s!
Apr 03 14:53:15 ttip kernel: BUG: workqueue lockup - pool cpus=8 node=0
flags=0x0 nice=0 stuck for 36s!
Apr 03 14:53:15 ttip kernel: Showing busy workqueues and worker pools:
Apr 03 14:53:15 ttip kernel: workqueue mm_percpu_wq: flags=0x8
Apr 03 14:53:15 ttip kernel:   pwq 16: cpus=8 node=0 flags=0x0 nice=0
active=1/256
Apr 03 14:53:15 ttip kernel: pending: vmstat_update
Apr 03 14:53:15 ttip kernel: workqueue xfs-sync/dm-0: flags=0x4
Apr 03 14:53:15 ttip kernel:   pwq 0: cpus=0 node=0 flags=0x0 nice=0
active=1/256
Apr 03 14:53:15 ttip kernel: pending: xfs_log_worker [xfs]
^C
Message from syslogd@ttip at Apr  3 14:53:45 ...
 kernel:[  972.929725] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0
nice=0 stuck for 66s!

Message from syslogd@ttip at Apr  3 14:54:15 ...
 kernel:[ 1003.008979] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0
nice=0 stuck for 96s!

Message from syslogd@ttip at Apr  3 14:54:46 ...
 kernel:[ 1033.088189] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0
nice=0 stuck for 126s!

Message from syslogd@ttip at Apr  3 14:55:16 ...
 kernel:[ 1063.166574] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0
nice=0 stuck for 156s!

Message from syslogd@ttip at Apr  3 14:55:46 ...
 kernel:[ 1093.244982] BUG: workqueue lockup - pool cpus=8 node=0 flags=0x0
nice=0 stuck for 186s!

This messages occasionally lead to machine/LDOM being unstable, i.e. with
some lockups to processes.

filtered dmesg output:

ttip$ dmesg  | egrep -i "cpu|smp"
[0.73] Linux version 4.16.0-05456-g17dec0a94915 (mator@ttip) (gcc
version 7.3.0 (Debian 7.3.0-14)) #659 SMP Wed Apr 4 12:16:32 MSK 2018
[0.037199] PLATFORM: max-cpus [1024]
[0.194415] CPU CAPS: [flush,stbar,swap,muldiv,v9,blkinit,n2,mul32]
[0.194525] CPU CAPS: [div32,v8plus,popc,vis,vis2,ASIBlkInit,fmaf,vis3]
[0.194630] CPU CAPS: [hpc,ima,pause,cbcond,aes,des,kasumi,camellia]
[0.194731] CPU CAPS:
[md5,sha1,sha256,sha512,mpmul,montmul,montsqr,crc32c]
[0.237948] percpu: Embedded 12 pages/cpu @(ptrval) s56584 r8192
d33528 u131072
[0.238199] pcpu-alloc: s56584 r8192 d33528 u131072 alloc=1*4194304
[0.238209] pcpu-alloc: [0] 000 001 002 003 004 005 006 007 008 009 010
011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029
030 031
[0.238363] pcpu-alloc: [0] 032 033 034 035 036 037 038 039 040 041 042
043 044 045 046 047 048 049 050 051 052 053 054 055 056 057 058 059 060 061
062 063
[0.238515] pcpu-alloc: [0] 064 065 066 067 068 069 070 071 072 073 074
075 076 077 078 079 080 081 082 083 084 085 086 087 088 089 090 091 092 093
094 095
[0.238668] pcpu-alloc: [0] 096 097 098 099 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
[0.238820] pcpu-alloc: [0] 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
[0.238973] pcpu-alloc: [0] 160 161 162 163 164 165 166 167 168 169 170
171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189
190 191
[0.239125] pcpu-alloc: [0] 192 193 194 195 196 197 198 199 200 201 202
203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221
222 223
[0.239278] pcpu-alloc: [0] 224 225 226 227 228 229 230 231 232 233 234
235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253
254 255
[0.239873] SUN4V: Mondo queue sizes [cpu(131072) dev(16384) r(8192)
nr(256)]
[0.242373] log_buf_len individual max cpu contribution: 4096 bytes
[0.242438] log_buf_len total cpu_extra contributions: 1044480 bytes
[0.516414] smp: Bringing up secondary CPUs ...
[0.548006] smp: Brought up 1 node, 16 CPUs
___
Kernelnewbies mailing list

Re: building debug version of klibc

[Anatoly Pugachev]

On Sat, Dec 30, 2017 at 3:14 PM,  <valdis.kletni...@vt.edu> wrote:
> On Sat, 30 Dec 2017 15:05:46 +0300, Anatoly Pugachev said:
>> On Sat, Dec 30, 2017 at 3:00 PM,  <valdis.kletni...@vt.edu> wrote:
>> > On Sat, 30 Dec 2017 13:54:05 +0300, Anatoly Pugachev said:
>> >> Hello!
>> >>
>> >> Can someone please help me in building debug version of klibc ?
>> >>
>> >> I've cloned git://git.kernel.org/pub/scm/libs/klibc/klibc.git  , but
>> >> failed to build it with debug info
>> >>
>> >> added "-g" to HOSTCFLAGS in Makefile, but
>
>> it's usual git kernel compile and install. And it's the first time I
>> started to get segfault from fstype.
>
> I missed where you went from klibc to building a new kernel, probably
> because you changed topics in mid-email.  Why were you building a new
> kernel for your host system just to get a klibc that had -g?

I'm using / testing a git kernel upstream on my hardware (sparc64 /
ppc64 / ia64 ).
Only this time, installing latest git kernel, I get a sigserv on
sparc64 from klibc utility (fstype), and posted about it to mailing
list.
So, to properly report with gdb backtrace, i was need to build klibc
(fstype) with debug info.
I'm not able to fix it myself, so probably someone else could look
into the issue (or i'm just raising awareness for the issue to other
who can hit it as well).
It could be compiler issue as well, if files in klibc.git repo does
not changed for about a year
I was asking for help with building debug version of klibc and since i
was able to build it, we could close this issue for now (going to
discuss it with debian distribution maintainers first).
Thanks!

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: building debug version of klibc

[Anatoly Pugachev]

On Sat, Dec 30, 2017 at 3:00 PM,  <valdis.kletni...@vt.edu> wrote:
> On Sat, 30 Dec 2017 13:54:05 +0300, Anatoly Pugachev said:
>> Hello!
>>
>> Can someone please help me in building debug version of klibc ?
>>
>> I've cloned git://git.kernel.org/pub/scm/libs/klibc/klibc.git  , but
>> failed to build it with debug info
>>
>> added "-g" to HOSTCFLAGS in Makefile, but
>
> Hint:  HOSTCFLAGS is applied to code that needs to run on the machine that's
> doing the build, not the target code.  So for instance, if I'm 
> cross-compiling on
> an x86_64   for an ARM target (which I do quite a bit, building Lede 
> router images
> for my wireless), HOSTCFLAGS is applied to any x86_64 utility code that gets
> built.  I don't know what code is in klibc, but an example in the kernel 
> source
> tree would be 'objtool' - that runs on the host system during the build, not 
> at runtime.
>
>> I started to get segfault in fstype:
>
>> linux-2.6$ make install
> ...
>>  DEPMOD  4.15.0-rc5-00149-g5aa90a845892
>> sh ./arch/sparc/boot/install.sh 4.15.0-rc5-00149-g5aa90a845892 
>> arch/sparc/boot/zImage \
>>System.map "/boot"
>
> What directory did you do that in?  It looks like you're trying to install a 
> whole
> new kernel image, not a new initramfs that has an updated klibc on it.

Valdis,

it's usual git kernel compile and install. And it's the first time I
started to get segfault from fstype.

git kernel from
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

local directory where do i build it is ~/linux-2.6 , my own config.
Worked fine for more than 100th times.
So, i'm doing "make modules_install && make install" in this directory
which doing right about to copy vmlinuz, System.map, kernel config
file to /boot and generate initrd there and updating boot loader
(grub2) config file.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: building debug version of klibc

[Anatoly Pugachev]

On Sat, Dec 30, 2017 at 2:30 PM, Sam Ravnborg <s...@ravnborg.org> wrote:
> Hi Anatoly
>
> On Sat, Dec 30, 2017 at 01:54:05PM +0300, Anatoly Pugachev wrote:
>> Hello!
>>
>> Can someone please help me in building debug version of klibc ?
>>
>> I've cloned git://git.kernel.org/pub/scm/libs/klibc/klibc.git  , but
>> failed to build it with debug info
>>
>> added "-g" to HOSTCFLAGS in Makefile, but
>
> HOSTCFLAGS is used when building tools running on your build machine.
>
> Try something like this (untested, whitespace damaged):
>
> diff --git a/scripts/Kbuild.klibc b/scripts/Kbuild.klibc
> index f500d535..3e8124f7 100644
> --- a/scripts/Kbuild.klibc
> +++ b/scripts/Kbuild.klibc
> @@ -69,7 +69,7 @@ include $(srctree)/scripts/Kbuild.include
>  KLIBCREQFLAGS := $(call cc-option, -fno-stack-protector, ) \
>   $(call cc-option, -fwrapv, )
>  KLIBCARCHREQFLAGS :=
> -KLIBCOPTFLAGS :=
> +KLIBCOPTFLAGS := -g
>  KLIBCWARNFLAGS:= -W -Wall -Wno-sign-compare -Wno-unused-parameter
>  KLIBCSHAREDFLAGS  :=
>  KLIBCBITSIZE  :=
>
> If you use make V=1 then you should be able to see the
> full gcc command line, where -g should be included with
> theabove fix.


Sam, thanks!
I did notice that later as well, but I've changed KLIBCCFLAGS to
include "-g" and changed strip to echo:

mator@ttip:~/klibc$ git diff
diff --git a/scripts/Kbuild.klibc b/scripts/Kbuild.klibc
index f500d535..40cbfd60 100644
--- a/scripts/Kbuild.klibc
+++ b/scripts/Kbuild.klibc
@@ -74,7 +74,7 @@ KLIBCWARNFLAGS:= -W -Wall -Wno-sign-compare
-Wno-unused-parameter
 KLIBCSHAREDFLAGS  :=
 KLIBCBITSIZE  :=
 KLIBCLDFLAGS  :=
-KLIBCCFLAGS   :=
+KLIBCCFLAGS   := -g

 # Defaults for arch to override
 KLIBCARCHINCFLAGS = -I$(KLIBCKERNELOBJ)/arch/$(KLIBCARCH)/include
@@ -99,7 +99,7 @@ KLIBCAR  := $(AR)
 klibc-ar = $(KLIBCAR) $(if $(KBUILD_REPRODUCIBLE),$(2),$(1))

 KLIBCRANLIB  := $(call klibc-ar,s,Ds)
-KLIBCSTRIP   := $(STRIP)
+KLIBCSTRIP   := echo
 KLIBCNM  := $(NM)
 KLIBCOBJCOPY := $(OBJCOPY)
 KLIBCOBJDUMP := $(OBJDUMP)
@@ -126,7 +126,7 @@ KLIBCCPPFLAGS+= $(KLIBCDEFS)
 KLIBCCFLAGS  += $(KLIBCCPPFLAGS) $(KLIBCREQFLAGS) $(KLIBCARCHREQFLAGS)  \
 $(KLIBCOPTFLAGS) $(KLIBCWARNFLAGS)
 KLIBCAFLAGS  += -D__ASSEMBLY__ $(KLIBCCFLAGS)
-KLIBCSTRIPFLAGS  += --strip-all -R .comment -R .note
+#KLIBCSTRIPFLAGS  += --strip-all -R .comment -R .note

 KLIBCLIBGCC_DEF  := $(shell $(KLIBCCC) $(KLIBCCFLAGS) --print-libgcc)
 KLIBCLIBGCC ?= $(KLIBCLIBGCC_DEF)
mator@ttip:~/klibc$

this helped me to produce exec with debug info and stack trace:

(gdb) file ./usr/kinit/fstype/static/fstype
Reading symbols from ./usr/kinit/fstype/static/fstype...done.
(gdb) run
Starting program: /home/mator/klibc/usr/kinit/fstype/static/fstype

Program received signal SIGSEGV, Segmentation fault.
__syscall_common () at usr/klibc/arch/sparc64/syscall.S:15
15  st  %o0,[%g4]
(gdb) bt
#0  __syscall_common () at usr/klibc/arch/sparc64/syscall.S:15
#1  0x001010d4 in identify_fs ()
#2  0x001001f0 in main ()


PS: added sparclinux@vger , first thread message is
http://www.zytor.com/pipermail/klibc/2017-December/003962.html

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

building debug version of klibc

[Anatoly Pugachev]

Hello!

Can someone please help me in building debug version of klibc ?

I've cloned git://git.kernel.org/pub/scm/libs/klibc/klibc.git  , but
failed to build it with debug info

added "-g" to HOSTCFLAGS in Makefile, but

$ make -j KLIBCKERNELSRC=`pwd`/../linux-2.6/usr

still strips every debug symbol , and i'm failed to change
scripts/Kbuild.klibc and Makefile to remove strip usage

klibc$ find . -name fstype | xargs file
./usr/kinit/fstype:   directory
./usr/kinit/fstype/static/fstype: ELF 64-bit MSB executable, SPARC V9,
relaxed memory ordering, version 1 (SYSV), statically linked, stripped
./usr/kinit/fstype/shared/fstype: ELF 64-bit MSB executable, SPARC V9,
relaxed memory ordering, version 1 (SYSV), statically linked,
interpreter /lib/klibc-M67ne2AU3wnuYln_9h2L1vfH5J0.so, stripped



I started to get segfault in fstype:

linux-2.6$ make install
...
  DEPMOD  4.15.0-rc5-00149-g5aa90a845892
sh ./arch/sparc/boot/install.sh 4.15.0-rc5-00149-g5aa90a845892
arch/sparc/boot/zImage \
System.map "/boot"
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal
4.15.0-rc5-00149-g5aa90a845892
/boot/vmlinuz-4.15.0-rc5-00149-g5aa90a845892
run-parts: executing /etc/kernel/postinst.d/initramfs-tools
4.15.0-rc5-00149-g5aa90a845892
/boot/vmlinuz-4.15.0-rc5-00149-g5aa90a845892
update-initramfs: Generating /boot/initrd.img-4.15.0-rc5-00149-g5aa90a845892
Segmentation fault
run-parts: executing /etc/kernel/postinst.d/zz-update-grub
4.15.0-rc5-00149-g5aa90a845892
/boot/vmlinuz-4.15.0-rc5-00149-g5aa90a845892

Dec 30 12:51:06 ttip kernel: fstype[162686]: segfault at 38 ip
8001069c (rpc 80004820) sp 07feffdf53a1 error 1 in
klibc-g_9mplOvk_73CeIA8YN-t9vhxyc.so[8000+14000]

linux-2.6$ gdb -q -c core.164896
[New LWP 164896]
Core was generated by `/usr/lib/klibc/bin/fstype /dev/vdiska2'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x8001069c in ?? ()

linux-2.6$ $ find /usr -name fstype | xargs file
/usr/lib/klibc/bin/fstype: ELF 64-bit MSB executable, SPARC V9,
relaxed memory ordering, version 1 (SYSV), statically linked,
interpreter /lib/klibc-g_9mplOvk_73CeIA8YN-t9vhxyc.so, stripped

linux-2.6# file -s /dev/vdiska2
/dev/vdiska2: Linux rev 1.0 ext4 filesystem data,
UUID=f2eda779-5310-4af2-b48a-b43db51c0961 (needs journal recovery)
(extents) (64bit) (large files) (huge files)

$ dpkg -S /usr/lib/klibc/bin/fstype
klibc-utils: /usr/lib/klibc/bin/fstype

$ dpkg -l klibc-utils
||/ Name   Version
Architecture   Description
+++-==-==-==-=
ii  klibc-utils2.0.4-10   sparc64
  small utilities built with klibc for early boot


$ apt show klibc-utils
Package: klibc-utils
Version: 2.0.4-10
Priority: optional
Section: libs
Source: klibc
Maintainer: maximilian attems 
Installed-Size: 522 kB
Depends: libklibc (= 2.0.4-10)
Breaks: initramfs-tools (<< 0.123~)
Homepage: https://git.kernel.org/cgit/libs/klibc/klibc.git
Download-Size: 107 kB
APT-Manual-Installed: no
APT-Sources: http://ftp.ports.debian.org/debian-ports unstable/main
sparc64 Packages
Description: small utilities built with klibc for early boot
 This package contains a collection of programs that are linked
 against klibc. These duplicate some of the functionality of a
 regular Linux toolset, but are typically much smaller than their
 full-function counterparts.  They are intended for inclusion in
 initramfs images and embedded systems.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies