Re: Missing Copyright?
Warner, Thanks for the quick response. If I have time I'll rig up my build to disable the use of assembly routines on x86_64 and any compiler builtin functions to do some testing of these routines. On Fri, Oct 22, 2021 at 10:05:38PM -0600, Warner Losh wrote: > Done. > https://cgit.freebsd.org/src/commit/?id=3550a49f6814af38c21b0033ef8746953451dade > > Since the license is a verbatim copy of the standard SPDX license, I tagged > it using our draft license policy's > suggested SPDX-License-Identifier: tag. > > Warner > > On Fri, Oct 22, 2021 at 9:14 PM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > It seems that git commit f5542795b99206a2b4e5a57429d18b9478264e24 > > replaced the fdlibm implementations of s_scalbn.c, s_scalbnf.c, > > and s_scalbnl.c by those in MUSL. There are no Copyright > > notices in these files. There is no statement to the originals > > of these files within the files. > > > > If one looks at https://git.musl-libc.org/cgit/musl/tree/COPYRIGHT > > one finds: > > > > musl as a whole is licensed under the following standard MIT license: > > (trimmed) -- Steve
Re: Missing Copyright?
Done. https://cgit.freebsd.org/src/commit/?id=3550a49f6814af38c21b0033ef8746953451dade Since the license is a verbatim copy of the standard SPDX license, I tagged it using our draft license policy's suggested SPDX-License-Identifier: tag. Warner On Fri, Oct 22, 2021 at 9:14 PM Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > It seems that git commit f5542795b99206a2b4e5a57429d18b9478264e24 > replaced the fdlibm implementations of s_scalbn.c, s_scalbnf.c, > and s_scalbnl.c by those in MUSL. There are no Copyright > notices in these files. There is no statement to the originals > of these files within the files. > > If one looks at https://git.musl-libc.org/cgit/musl/tree/COPYRIGHT > one finds: > > musl as a whole is licensed under the following standard MIT license: > > Copyright Š 2005-2020 Rich Felker, et al. > > Permission is hereby granted, free of charge, to any person obtaining > a copy of this software and associated documentation files (the > "Software"), to deal in the Software without restriction, including > without limitation the rights to use, copy, modify, merge, publish, > distribute, sublicense, and/or sell copies of the Software, and to > permit persons to whom the Software is furnished to do so, subject to > the following conditions: > > The above copyright notice and this permission notice shall be > included in all copies or substantial portions of the Software. > > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. > IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY > CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, > TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE > SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. > > Please add a Copyright to these files or remove them from the > repository to prevent someone from accidently violating said > Copyright. > > -- > Steve > >
Missing Copyright?
It seems that git commit f5542795b99206a2b4e5a57429d18b9478264e24 replaced the fdlibm implementations of s_scalbn.c, s_scalbnf.c, and s_scalbnl.c by those in MUSL. There are no Copyright notices in these files. There is no statement to the originals of these files within the files. If one looks at https://git.musl-libc.org/cgit/musl/tree/COPYRIGHT one finds: musl as a whole is licensed under the following standard MIT license: Copyright © 2005-2020 Rich Felker, et al. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Please add a Copyright to these files or remove them from the repository to prevent someone from accidently violating said Copyright. -- Steve
Re: main changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS but /usr/lib/libdialog.so.? naming was not adjusted? (crashes in releng/13 programs on main [so: 14] can result)
On Fri, Oct 22, 2021 at 04:11:56PM +, Baptiste Daroussin wrote: > > 22 oct. 2021 18:06:56 John Baldwin : > > > On 10/22/21 1:08 AM, Mark Millard via freebsd-current wrote: > >> main [soi: 14] commit a96ef450 (2021-02-26 09:16:49 +) > >> changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS . > >> These are publicly exposed in (ones that I noticed): > >> /usr/include/dialog.h:extern DIALOG_STATE dialog_state; > >> /usr/include/dialog.h:extern DIALOG_VARS dialog_vars; > >> /usr/include/dialog.h:extern DIALOG_COLORS dlg_color_table[]; > > > > Then we need to bump libdialog's so version to 10? (I don't > > think libdialog has symbol versioning) > > > > -- > > John Baldwin > > It does not have symbol versionning and yes good catch it needs to be bumped Upstream does do symbol versioning, but I don't know that can help, (it doesn't appear to have some way of saying "version >= whatever", but only "version == whatever"). The soname should be updated (which is what you're talking about "bumped") -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Future of ident(1)
On Fri, Oct 22, 2021 at 03:51:15PM -0600, Warner Losh wrote: > On Fri, Oct 22, 2021 at 3:30 PM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > All, > > > > With the new world order, what is the future of ident(1)? > > Should it be removed from base? Given a compiled binary > > in base, how does one find the equivalent git info that > > ident(1) used to perform? > > > > It is useful for some rare cases, but in general those cases likely > can likely be handled by readelf / elfdump and adding build info > to the files. I tendto think it's time to retire ident(1), but I'm in no > hurry. > I played a bit with objdump. It seems currently a compiled object and/or binary does not include a git hash. I suppose this makes it only a bit more inconvenient to explore history. > > > > Having a few minutes to dust off old patchs for libm, should > > I remove $FreeBSD$ tags in files I touch? > > No. The current rule is that we're not removing $FreeBSD$ as we touch files. > The plan is to remove it wholesale in the future. This gives maximum > flexibility because stable/12 is still built out of svn and you never > know what might get MFC'd there. > OK. > > For new files, is > > it expected that useless $FreeBSD$ tags should be added? > > > > If you plan to or expet to merge the new file to stable/12, then yes. > Otherwise omit $FreeBSD$. Most new files won't likely be merged to 12 > and even if you make an error in judgement and a new file without > $FreeBSD$ is merged to 12, the impact is going to be minimal. I have no intentions of merging anything. I'll submit re-open a PR and attach the updated to it. -- Steve
Re: Future of ident(1)
On Fri, Oct 22, 2021 at 3:30 PM Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > All, > > With the new world order, what is the future of ident(1)? > Should it be removed from base? Given a compiled binary > in base, how does one find the equivalent git info that > ident(1) used to perform? > It is useful for some rare cases, but in general those cases likely can likely be handled by readelf / elfdump and adding build info to the files. I tendto think it's time to retire ident(1), but I'm in no hurry. > > Having a few minutes to dust off old patchs for libm, should > I remove $FreeBSD$ tags in files I touch? No. The current rule is that we're not removing $FreeBSD$ as we touch files. The plan is to remove it wholesale in the future. This gives maximum flexibility because stable/12 is still built out of svn and you never know what might get MFC'd there. > For new files, is > it expected that useless $FreeBSD$ tags should be added? > If you plan to or expet to merge the new file to stable/12, then yes. Otherwise omit $FreeBSD$. Most new files won't likely be merged to 12 and even if you make an error in judgement and a new file without $FreeBSD$ is merged to 12, the impact is going to be minimal. Warner
Future of ident(1)
All, With the new world order, what is the future of ident(1)? Should it be removed from base? Given a compiled binary in base, how does one find the equivalent git info that ident(1) used to perform? Having a few minutes to dust off old patchs for libm, should I remove $FreeBSD$ tags in files I touch? For new files, is it expected that useless $FreeBSD$ tags should be added? -- Steve
Re: LAN ure interface problem
On 10/22/21 16:00, Ludovit Koren wrote: Hi, I have installed FreeBSD 14.0-CURRENT #1 main-n250134-225639e7db6-dirty on my notebook HP EliteBook 830 G7 and I am using RealTek usb LAN interface: ure0 on uhub0 ure0: on usbus1 miibus0: on ure0 rgephy0: PHY 0 on miibus0 rgephy0: OUI 0x00e04c, model 0x, rev. 0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on ure0 ue0: bpf attached ue0: Ethernet address: 00:e0:4c:68:04:20 When there is bigger load on the interface, for example rsync of the big directory, the carrier is lost. The only solution I found is to remove and insert the usb interface; ifconfig ue0 down, ifconfig ue0 up did not help. The output of the ifconfig: ue0: flags=8843 metric 0 mtu 1500 options=68009b ether 00:e0:4c:68:04:20 inet 192.168.1.18 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 I do not know and did not find anything relevant, if the driver is buggy or the hardware has some problems. Please, advice. Regards, Not the same device, but similar issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258057 --HPS
Re: main changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS but /usr/lib/libdialog.so.? naming was not adjusted? (crashes in releng/13 programs on main [so: 14] can result)
22 oct. 2021 18:06:56 John Baldwin : > On 10/22/21 1:08 AM, Mark Millard via freebsd-current wrote: >> main [soi: 14] commit a96ef450 (2021-02-26 09:16:49 +) >> changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS . >> These are publicly exposed in (ones that I noticed): >> /usr/include/dialog.h:extern DIALOG_STATE dialog_state; >> /usr/include/dialog.h:extern DIALOG_VARS dialog_vars; >> /usr/include/dialog.h:extern DIALOG_COLORS dlg_color_table[]; > > Then we need to bump libdialog's so version to 10? (I don't > think libdialog has symbol versioning) > > -- > John Baldwin It does not have symbol versionning and yes good catch it needs to be bumped Bapt
Re: main changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS but /usr/lib/libdialog.so.? naming was not adjusted? (crashes in releng/13 programs on main [so: 14] can result)
On 10/22/21 1:08 AM, Mark Millard via freebsd-current wrote: main [soi: 14] commit a96ef450 (2021-02-26 09:16:49 +) changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS . These are publicly exposed in (ones that I noticed): /usr/include/dialog.h:extern DIALOG_STATE dialog_state; /usr/include/dialog.h:extern DIALOG_VARS dialog_vars; /usr/include/dialog.h:extern DIALOG_COLORS dlg_color_table[]; Then we need to bump libdialog's so version to 10? (I don't think libdialog has symbol versioning) -- John Baldwin
LAN ure interface problem
Hi, I have installed FreeBSD 14.0-CURRENT #1 main-n250134-225639e7db6-dirty on my notebook HP EliteBook 830 G7 and I am using RealTek usb LAN interface: ure0 on uhub0 ure0: on usbus1 miibus0: on ure0 rgephy0: PHY 0 on miibus0 rgephy0: OUI 0x00e04c, model 0x, rev. 0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on ure0 ue0: bpf attached ue0: Ethernet address: 00:e0:4c:68:04:20 When there is bigger load on the interface, for example rsync of the big directory, the carrier is lost. The only solution I found is to remove and insert the usb interface; ifconfig ue0 down, ifconfig ue0 up did not help. The output of the ifconfig: ue0: flags=8843 metric 0 mtu 1500 options=68009b ether 00:e0:4c:68:04:20 inet 192.168.1.18 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=29 I do not know and did not find anything relevant, if the driver is buggy or the hardware has some problems. Please, advice. Regards, lk
Re: Curious minds .. etc
On 22 Oct 2021, at 14.05, Konstantin Belousov wrote: > > On Fri, Oct 22, 2021 at 01:07:47AM -0700, Julian Elischer wrote: >> Several years ago (OK, maybe 12 years ago) I did an experiment where I >> unpacked a >> freebsd 1.1 (or maybe 2.0?) image into a subdirectory, and after installing >> various >> compat packagesand options and a.out support and changing MAX_PID to be >> 6, I was able to >> chroot to it and do a "make world". Things were stupidly fast. >> >> >> Has anyone been able to do such a thing in recent years? One wonders what >> options one >> would need and what the oldest Version we could run in this way was.. > > Yes, I added support for a.out to amd64, and wrote man page which documents > all details that are relevant there, see aout(4). > I have a 2.2.5 vbox image, with 256M mem and 1CPU (crashes with SMP) does buildworld in just under 4 minutes on 1 core from a i9 9900k. -- Søren Schmidt s...@deepcore.dk / s...@freebsd.org "So much code to hack, so little time"
Re: Curious minds .. etc
On Fri, Oct 22, 2021 at 01:07:47AM -0700, Julian Elischer wrote: > Several years ago (OK, maybe 12 years ago) I did an experiment where I > unpacked a > freebsd 1.1 (or maybe 2.0?) image into a subdirectory, and after installing > various > compat packagesand options and a.out support and changing MAX_PID to be > 6, I was able to > chroot to it and do a "make world". Things were stupidly fast. > > > Has anyone been able to do such a thing in recent years? One wonders what > options one > would need and what the oldest Version we could run in this way was.. Yes, I added support for a.out to amd64, and wrote man page which documents all details that are relevant there, see aout(4).
Re: Curious minds .. etc
On Fri, 22 Oct 2021 01:07:47 -0700 Julian Elischer wrote: > Several years ago (OK, maybe 12 years ago) I did an experiment where I > unpacked a > freebsd 1.1 (or maybe 2.0?) image into a subdirectory, and after installing > various > compat packagesand options and a.out support and changing MAX_PID to be > 6, I was able to > chroot to it and do a "make world". Things were stupidly fast. > > > Has anyone been able to do such a thing in recent years? One wonders what > options one > would need and what the oldest Version we could run in this way was.. > Well, there's still a /usr/ports/misc/compat4x, which is the oldest version supported. So that could still work, although it's not obvious whether it will work with e.g. FBSD-14. The most recent compat version is for 12x. The good old days, when the kernel was on the order of 90kB and 256kB of memory was a lot and big disks had one or two hundred MB. -- Gary Jennejohn
main changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS but /usr/lib/libdialog.so.? naming was not adjusted? (crashes in releng/13 programs on main [so: 14] can result)
main [soi: 14] commit a96ef450 (2021-02-26 09:16:49 +)
changed DIALOG_STATE, DIALOG_VARS, and DIALOG_COLORS .
These are publicly exposed in (ones that I noticed):
/usr/include/dialog.h:extern DIALOG_STATE dialog_state;
/usr/include/dialog.h:extern DIALOG_VARS dialog_vars;
/usr/include/dialog.h:extern DIALOG_COLORS dlg_color_table[];
and ends up with the storage being form the .bss of
the likes of dialog4ports (the example I ran into).
But the .9 in /usr/lib/libdialog.so.9 's .text that references
the storage where not increased compared to releng/13.0 and
stable/13 that predate the changes, there by not matching
old programs built under releng/13.0 or stable/13 .
Turns out that this explains the crashes I get when I attempt
to use a releng/13 based dialog4ports under main [so: 14]. For
a particular example, see:
https://lists.freebsd.org/archives/freebsd-current/2021-October/000860.html
It shows /usr/main-src/contrib/dialog/dlg_keys.c in
/usr/lib/libdialog.so.9 updating a new field:
286 } else {
287 dialog_state.had_resize = FALSE;
0x0008002d298e <+62>:movb $0x0,0x84(%rax)
such that the following happens:
Hardware watchpoint 1: -location __stderrp
Old value = (FILE *) 0x8004d4940
New value = (FILE *) 0x4d4940
where:
(gdb) print &__stderrp
$4 = (FILE **) 0x208568 <__stderrp>
which has that storage in the dialog4ports area:
0x00208360 - 0x00208c50 is .bss
with the older set of fields and size for:
extern DIALOG_STATE dialog_state;
That in turn later leads to a SIGSEGV from the point of
view of a releng/13 based dialog4ports build.
Should main [14] instead have:
/usr/lib/libdialog.so.10
in order to avoid some releng/13.0 and stable/13 programs
trashing their memory? I'm guessing there is no reasonble
way to "compat" this. But preventing programs from trashing
there own memory and running in a corrupted state seems
achievable if the /usr/lib/libdialog.so.? name changes.
This might be something for a freebsd-arch discussion for
relevant folks.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Curious minds .. etc
Several years ago (OK, maybe 12 years ago) I did an experiment where I unpacked a freebsd 1.1 (or maybe 2.0?) image into a subdirectory, and after installing various compat packagesand options and a.out support and changing MAX_PID to be 6, I was able to chroot to it and do a "make world". Things were stupidly fast. Has anyone been able to do such a thing in recent years? One wonders what options one would need and what the oldest Version we could run in this way was.. J
Re: Building ZFS disk images
On 9/28/21 9:15 AM, Rodney W. Grimes wrote: On Tue, Sep 28, 2021 at 9:48 AM Rodney W. Grimes wrote: ^^^ re-guid the pool on first boot. Isnt the proper place to solve this lack of Unique UUID creation in the tool(s) that are creating the zfs pool in the first place. Fixing it "post boot" seems to be a far to late hack and doesnt fix any of the situations where one might import these pools between creation and first boot. No, because you might create a VM image once, then instantiate it dozens or thousands of times. The firstboot solution is great because it lets you reuse the same image file. I would continue to argue that the place to fix this is in the "instantiate tool". ESXI vmfs deals with this all the time when you clone a disk. And again the "fix at boot" does not deal with the problem in that if I "instatiate" 10 copies of a zpool for VM's and then try to mount 2 of them at once on the host this problem rares it head. Fix the problem as close to point of creation as possible for minimal issues in all operations for everyone. Define a special magic "change to something else" ID that will always do the right thing exactly once.
Re: Is dialog4ports built in/for releng/13.0 also supposed to work under main [so: 14]? It gets SIGSEGV in my context. (some low level failure info now)
On 2021-Oct-21, at 16:24, Mark Millard wrote: > On 2021-Oct-21, at 11:53, Mark Millard wrote: > >> On 2021-Oct-21, at 08:27, Tomoaki AOKI wrote: >> >>> On Thu, 21 Oct 2021 07:40:36 -0700 >>> Mark Millard via freebsd-current wrote: >>> On 2021-Oct-21, at 06:14, Gary Jennejohn wrote: > On Thu, 21 Oct 2021 01:34:47 -0700 > Mark Millard via freebsd-current wrote: > >> I get the following crash (amd64 example shown), as reported >> via gdb afterwards. (devel/llvm13 is just an example context.) >> >> gdb `which dialog4ports` devel/llvm13/dialog4ports.core >> . . . >> Core was generated by `/usr/local/bin/dialog4ports'. >> Program terminated with signal SIGSEGV, Segmentation fault. >> Address not mapped to object. >> #0 vfprintf_l (fp=0x4d4940, locale=0x8004d4128 >> <__xlocale_global_locale>, fmt0=0x201f64 "\"%s\"", >> ap=ap@entry=0x7fffcf00) at >> /usr/main-src/lib/libc/stdio/vfprintf.c:281 >> 281 if ((fp->_flags & (__SNBF|__SWR|__SRW)) == >> (__SNBF|__SWR) && >> (gdb) bt >> #0 vfprintf_l (fp=0x4d4940, locale=0x8004d4128 >> <__xlocale_global_locale>, fmt0=0x201f64 "\"%s\"", >> ap=ap@entry=0x7fffcf00) at >> /usr/main-src/lib/libc/stdio/vfprintf.c:281 >> #1 0x000800409283 in fprintf (fp=0x800411660 >> <__stdio_cancel_cleanup>, fmt=0x7fffcdd0 "0\317\377\377\377\177") at >> /usr/main-src/lib/libc/stdio/fprintf.c:57 >> #2 0x0020399d in main (argc=, argv=> out>) at dialog4ports.c:332 >> (gdb) quit >> >> The crash happens after selecting OK but not after selecting Cancel. The >> display is also odd before that (no line drawing, just odd text instead), >> but is sufficient to be usable at that stage. >> >> . . . > > gdb's disass/s reports the failure point via: > > . . . > /usr/main-src/lib/libc/stdio/vfprintf.c: > 279 FLOCKFILE_CANCELSAFE(fp); > 0x000800412357 <+71>: mov0xbf082(%rip),%rax# 0x8004d13e0 > 0x00080041235e <+78>: cmpl $0x0,(%rax) > 0x000800412361 <+81>: je 0x800412370 > 0x000800412363 <+83>: mov%rbx,%rdi > 0x000800412366 <+86>: call 0x8004c6730 <_flockfile@plt> > 0x00080041236b <+91>: mov%rbx,%rsi > 0x00080041236e <+94>: jmp0x800412372 > 0x000800412370 <+96>: xor%esi,%esi > 0x000800412372 <+98>: lea-0xd19(%rip),%rdi# 0x800411660 > <__stdio_cancel_cleanup> > 0x000800412379 <+105>: lea-0x70(%rbp),%rdx > 0x00080041237d <+109>: call 0x800384a90 > <__pthread_cleanup_push_imp_int> > > 280 /* optimise fprintf(stderr) (and other unbuffered Unix files) */ > 281 if ((fp->_flags & (__SNBF|__SWR|__SRW)) == (__SNBF|__SWR) && > => 0x000800412382 <+114>: movzwl 0x10(%rbx),%eax > 0x000800412386 <+118>: and$0x1a,%eax > 0x000800412389 <+121>: cmp$0xa,%ax > 0x00080041238d <+125>: jne0x8004123a9 > > 282 fp->_file >= 0) > 0x00080041238f <+127>: cmpw $0x0,0x12(%rbx) > > 281 if ((fp->_flags & (__SNBF|__SWR|__SRW)) == (__SNBF|__SWR) && > 0x000800412394 <+132>: js 0x8004123a9 > . . . > > (gdb) info reg > rax0x0 0 > rbx0x4d49405065024 > rcx0x7fffd0e0 140737488343264 > rdx0x7fffcfb0 140737488342960 > rsi0x0 0 > rdi0x800411660 34364003936 > rbp0x7fffd020 0x7fffd020 > rsp0x7fffcfb0 0x7fffcfb0 > r8 0x0 0 > r9 0x0 0 > r100x800a330f0 34370433264 > r110x206 518 > r120x8004d4128 34364801320 > r130x2083a02130848 > r140x7fffd0e0 140737488343264 > r150x201f642105188 > rip0x800412382 0x800412382 > eflags 0x10246 [ PF ZF IF RF ] > cs 0x4367 > ss 0x3b59 > ds > es > fs > gs > fs_base > gs_base > > where: > > (gdb) disass/s __pthread_cleanup_push_imp_int > Dump of assembler code for function __pthread_cleanup_push_imp_int: > /usr/main-src/lib/libc/gen/_pthread_stubs.c: > 289 STUB_FUNC3(__pthread_cleanup_push_imp, PJT_CLEANUP_PUSH_IMP, void, void > *, > 0x000800384a90 <+0>:push %rbp > 0x000800384a91 <+1>:mov%rsp,%rbp > 0x000800384a94 <+4>:mov0x14c94d(%rip),%rax# 0x8004d13e8 > 0x000800384a9b <+11>: mov0x3c8(%rax),%rax > 0x000800384aa2 <+18>: pop%rbp > 0x000800384aa3 <+19>: jmp*%rax > End of assembler dump. > > > It is not obvious that any
