I am using the linux capabilities by cap_set_flag.
It's published like , capabilities of the process would be reflected in /proc/$$/task/$$/status
But with cap_set_flag, it won't reflect . Only with capset API ,the capabilities are getting recorded in this status file.
Any reason for this.
Does this depend on kernel version which I am using (4.19.183).
I tried using cap_set_flag as below
cap_list[0] = CAP_CHOWN;
if (cap_set_flag(cap, CAP_EFFECTIVE, 1, cap_list, CAP_SET) == -1) {
perror("cap_set_flag cap_chown");
cap_free(cap);
exit(-1);
}
want this to be reflected in status file
$ grep Cap /proc/$$/task/$$/status
CapInh: 00000000a80425fb
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 00000000a80425fb
CapAmb: 0000000000000000
Related
I am working with a Stamp9g20 embedded chip. It is based on the Atmel at91sam9g20 platform. For a client I need to upgrade the kernel to a newer version. After a bit of research, I landed on the Linux4SAM pages and their additional yocto layer, complete with a 4.14 kernel!
However, when I compile that kernel, I don't see all of my devices, for example, I can write onto the NAND memory and mount an USB device, but I cannot see nor mount any mmc/mci devices. I have tried checking how the Stamp9g20 really differs from the AT91SAM9G20EK, but I couldn't find a definitive clue to an answer there.
The Linux4SAM repo supports slightly different versions of the AT91SAM9 family, but I got it working for the 4.14 kernel, using the at91sam9g20ek.dts as an input for the board. Had to add my machine to the compatible machine list, so it will compile for the 9g20 versions as well.
COMPATIBLE_MACHINE += 'at91sam9g20ek'
and my machine.conf looks like:
##Name: ATMEL AT91SAM9G20EK
##DESCRIPTION: Machine configuration for Atmel's evaluation board
#
# define SOC_FAMILY (we are the family of ...)
SOC_FAMILY = "atsam9"
# Add arm926ejs to the DEFAULTTUNE, so it will be selected in our environment
DEFAULTTUNE = "arm926ejs"
# http://lists.openembedded.org/pipermail/openembedded-core/2019-January/277527.html
#TUNE_CCARGS .= "${#bb.utils.contains('TUNE_FEATURES', 'armv5', ' -march=armv5t${ARMPKGSFX_DSP}', '', d)}"
TUNE_CCARGS = "${#bb.utils.contains('TUNE_FEATURES', 'armv5', ' -march=armv5t${ARMPKGSFX_DSP}', '', d)}"
# We rely on the generic meta-atmel layer
require conf/machine/include/at91sam9.inc
MACHINE_FEATURES = "apm ext2 ext3 ext4 usbhost usbgadget vfat jffs2"
# This device tree is available in the kernel
KERNEL_DEVICETREE = " \
at91sam9g20ek.dtb \
"
# Create filesystems tar.gz and jffs2
IMAGE_FSTYPES += " tar.gz jffs2 tar"
# UNTESTED IMAGES (both bootstrap and uboot)
UBOOT_MACHINE ?= "at91sam9g20ek_nandflash_defconfig"
UBOOT_ENTRYPOINT = "0x20008000"
UBOOT_LOADADDRESS = "0x20008000"
AT91BOOTSTRAP_MACHINE ?= "at91sam9g20ek"
When the kernel launches, it shows that it registers a device driver onto the address 0xffff8000, but it doesn't see a block device.
bus: 'mmc': add driver mmcblk
bus: 'sdio': add driver sdio_uart
bus: 'platform': add driver atmel_mci
bus: 'platform': driver_probe_device: matched device fffa8000.mmc with driver atmel_mci
bus: 'platform': really_probe: probing driver atmel_mci with device fffa8000.mmc
atmel_mci fffa8000.mmc: no init pinctrl state
atmel_mci fffa8000.mmc: version: 0x210
atmel_mci fffa8000.mmc: using PDC
device: 'mmc0': device_add
atmel_mci fffa8000.mmc: Atmel MCI controller at 0xfffa8000 irq 30, 1 slots
driver: 'atmel_mci': driver_bound: bound to device 'fffa8000.mmc'
bus: 'platform': really_probe: bound device fffa8000.mmc to driver atmel_mci
I have tried this board with the 2.6.x version where it works as expected.
How can I make the block device mmcblk available in the system? Do I need to change the .dts (currently I am using the at91sam9g20ek.dts as a template with a minor change to the NAND memory). Or what can I do to get more information as to why the kernel doesn't interact with the mmc device?
Also, if I compare the source code from before the dts structure, I don't see significant differences in the mcc part of the code:
https://elixir.bootlin.com/linux/v3.6.9/source/arch/arm/mach-at91/board-sam9g20ek.c
https://elixir.bootlin.com/linux/v3.6.9/source/arch/arm/mach-at91/board-stamp9g20.c
The only difference I found,
at91sam9g20ek board:
.slot_b = 1, /* Only one slot so use slot B */
stamp9g20 board:
.slot_b = 0,
so I tried changing the reg<> property in the dts to 1, but to no avail...
Found it! All I had to do was change the mmc slot (was 1) in the dts to slot 0:
--- a/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20ek_common.dtsi
## -39,8 +39,8 ##
};
- mmc0_slot1 {
- pinctrl_board_mmc0_slot1: mmc0_slot1-board {
+ mmc0_slot0 {
+ pinctrl_board_mmc0_slot0: mmc0_slot0-board {
atmel,pins =
<AT91_PIOC 9 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PC9 gpio CD pin pull up and deglitch */
};
## -90,15 +90,14 ##
mmc0: mmc#fffa8000 {
pinctrl-0 = <
- &pinctrl_board_mmc0_slot1
+ &pinctrl_board_mmc0_slot0
&pinctrl_mmc0_clk
- &pinctrl_mmc0_slot1_cmd_dat0
- &pinctrl_mmc0_slot1_dat1_3>;
+ &pinctrl_mmc0_slot0_cmd_dat0
+ &pinctrl_mmc0_slot0_dat1_3>;
status = "okay";
- slot#1 {
- reg = <1>;
+ slot#0 {
+ reg = <0>;
bus-width = <4>;
- cd-gpios = <&pioC 9 GPIO_ACTIVE_HIGH>;
};
};
I'm writing a block device driver and started with the sbull example from here:
http://lwn.net/images/pdf/LDD3/ldd3_pdf.tar.bz2
I loaded the sbull driver successfully on my machine with kernel version 3.5.0-23.
When I run this code:
int main(){
int fd;
if ((fd = open("/dev/sbulla",O_RDWR)) < 0)
{
perror("open: ");
exit(1);
}
lseek(fd,4096,SEEK_SET);
write(fd,"yonityoyin",10);
lseek(fd,4096*2,SEEK_SET);
write(fd,"yonityoyin",10);
close(fd);
}
The session gets stuck.
If i open another session on the machine and print dmesg i get this after some time:
[56437.815570] INFO: task a.out:4640 blocked for more than 120 seconds.
[56437.822742] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[56437.831563] a.out D ffffffff8180cbe0 0 4640 4639 0x00000000
[56437.831571] ffff880852715c08 0000000000000082 0000000000000000 0000000000000001
[56437.831580] ffff880852715fd8 ffff880852715fd8 ffff880852715fd8 00000000000139c0
[56437.831588] ffff8808547c0000 ffff880851bc2e00 ffff880852715be8 ffff88085fd74258
[56437.831595] Call Trace:
[56437.831623] [<ffffffff81127220>] ? __lock_page+0x70/0x70
[56437.831638] [<ffffffff8169d8b9>] schedule+0x29/0x70
[56437.831643] [<ffffffff8169d98f>] io_schedule+0x8f/0xd0
[56437.831652] [<ffffffff8112722e>] sleep_on_page+0xe/0x20
[56437.831657] [<ffffffff8169c25f>] __wait_on_bit+0x5f/0x90
[56437.831663] [<ffffffff81127c1b>] ? find_get_pages_tag+0xcb/0x170
[56437.831674] [<ffffffff81127388>] wait_on_page_bit+0x78/0x80
[56437.831682] [<ffffffff81078490>] ? autoremove_wake_function+0x40/0x40
[56437.831691] [<ffffffff8112749c>] filemap_fdatawait_range+0x10c/0x1a0
[56437.831701] [<ffffffff81133000>] ? do_writepages+0x20/0x40
[56437.831706] [<ffffffff8112755b>] filemap_fdatawait+0x2b/0x30
[56437.831711] [<ffffffff811298e4>] filemap_write_and_wait+0x44/0x60
[56437.831718] [<ffffffff811c0091>] __sync_blockdev+0x21/0x40
[56437.831722] [<ffffffff811c00c3>] sync_blockdev+0x13/0x20
[56437.831726] [<ffffffff811c0139>] __blkdev_put+0x69/0x1c0
[56437.831736] [<ffffffff811c02eb>] blkdev_put+0x5b/0x160
[56437.831740] [<ffffffff811c0415>] blkdev_close+0x25/0x30
[56437.831750] [<ffffffff81188afe>] __fput+0xbe/0x240
[56437.831756] [<ffffffff81188ca5>] fput+0x25/0x30
[56437.831761] [<ffffffff81185976>] filp_close+0x66/0x90
[56437.831766] [<ffffffff81185a3e>] sys_close+0x9e/0x110
[56437.831775] [<ffffffff816a7029>] system_call_fastpath+0x16/0x1b
What could be the problem with the driver?
Just to be clear, I get this problem with the original sbull driver.
Please refer the newer example code.
https://github.com/martinezjavier/ldd3
I have a user mode dump from Win 8.1/64, the dump was taken by attaching Windbg when the Wer dialogue. The .ecxr shows then ntdll!DbgBreakPoint for the Windbg injected thread. (As normal)
I have identified the thread by examine all stack, and finding the one which has :
# Call Site
00 ntdll!NtWaitForMultipleObjects
01 KERNELBASE!WaitForMultipleObjectsEx
02 kernel32!WerpReportFaultInternal
03 kernel32!WerpReportFault
04 KERNELBASE!UnhandledExceptionFilter
05 ntdll!RtlUserThreadStart$filt$0
06 ntdll!_C_specific_handler
07 ntdll!RtlpExecuteHandlerForException
08 ntdll!RtlDispatchException
09 ntdll!KiUserExceptionDispatch
10 <My faulty code which generated the exception>
The kvn aslo dispays a TrapFrame # 00000000`0379ed28)
09 00000000`0379e900 00000000`00250bc8 : 00000000`00000000 00000000`0026ca09 00000000`0379f160 00000000`0379f168 : ntdll!KiUserExceptionDispatch+0x2e (TrapFrame # 00000000`0379ed28)
Is there a way to use the trap frame to get the context record to feed into .cxr ?
Or is it other possibilities to find the exception context?
I see a KERNELBASE!UnhandledExceptionFilter on the stack. That seems like a good thing to focus on.
If this were x86, you could easily get an EXCEPTION_POINTERS struct out of the first parameter to KERNELBASE!UnhandledExceptionFilter. From there, you would have access to the EXCEPTION_RECORD and CONTEXT. The procedure is described in this KB article.
The same method works for x64 processes with one caveat. Due to the nature of the x64 calling convention, it is harder to retrieve the actual argument to KERNELBASE!UnhandledExceptionFilter since it is stored in a register rather than on the stack.
I recently found a debugger extension called CMKD that automates the task of hunting for the first 4 args in the x64 calling convention rather than blindly displaying stack values like kb and kv. This can be done by hand but it is a rather lengthy and error-prone process -- better to let an extension take a crack at it first.
With it, you can do something like this:
0:000> !cmkd.stack -p
Call Stack : 15 frames
## Stack-Pointer Return-Address Call-Site
[...]
03 000000aea3dae7e0 00007fff1e906b14 KERNELBASE!UnhandledExceptionFilter+196
Parameter[0] = 000000aea3dae930
Parameter[1] = (unknown)
Parameter[2] = (unknown)
Parameter[3] = (unknown)
[...]
And, now we have an EXCEPTION_POINTERS* in Parameter[0].
0:000> dt 000000ae`a3dae930 EXCEPTION_POINTERS
ConsoleApplication2!EXCEPTION_POINTERS
+0x000 ExceptionRecord : 0x000000ae`a3daf850 _EXCEPTION_RECORD
+0x008 ContextRecord : 0x000000ae`a3daf240 _CONTEXT
We can see in my example that a C++ exception was thrown...
0:000> .exr 000000ae`a3daf850
ExceptionAddress: 00007fff1bfeab78 (KERNELBASE!RaiseException+0x0000000000000068)
ExceptionCode: e06d7363 (C++ EH exception)
ExceptionFlags: 00000001
NumberParameters: 4
Parameter[0]: 0000000019930520
Parameter[1]: 000000aea3daf9b0
Parameter[2]: 00007ff6f50024a8
Parameter[3]: 00007ff6f5000000
pExceptionObject: 000000aea3daf9b0
_s_ThrowInfo : 00007ff6f50024a8
Hopefully this helps. Good luck. :)
Another method fox x64 case doesn't require extension but is relying on two unstable facts:
windbg ability to reconstruct registers for a specific frame
the fact that WerpReportFault stores EXCEPTION_POINTERS address in rdi before passing it to WerpReportFaultInternal (it is the case at least for kernel32.dll 6.1.7601.23915 (win7sp1_ldr.170913-0600)
Exception pointer can be extracted as an rdi value of the WerpReportFault's frame:
0:007> k
# Child-SP RetAddr Call Site
00 00000000`0868dcd8 000007fe`fcf61430 ntdll!NtWaitForMultipleObjects+0xa
01 00000000`0868dce0 00000000`76fb16e3 KERNELBASE!WaitForMultipleObjectsEx+0xe8
02 00000000`0868dde0 00000000`7702b8b5 kernel32!WaitForMultipleObjectsExImplementation+0xb3
03 00000000`0868de70 00000000`7702ba37 kernel32!WerpReportFaultInternal+0x215
04 00000000`0868df10 00000000`7702ba8f kernel32!WerpReportFault+0x77
05 00000000`0868df40 00000000`7702bcac kernel32!BasepReportFault+0x1f
06 00000000`0868df70 00000000`77230108 kernel32!UnhandledExceptionFilter+0x1fc
07 00000000`0868e050 00000000`771c7958 ntdll! ?? ::FNODOBFM::`string'+0x2025
08 00000000`0868e080 00000000`771d812d ntdll!_C_specific_handler+0x8c
09 00000000`0868e0f0 00000000`771c855f ntdll!RtlpExecuteHandlerForException+0xd
0a 00000000`0868e120 00000000`771fbcb8 ntdll!RtlDispatchException+0x45a
0b 00000000`0868e800 000007fe`fe03df54 ntdll!KiUserExceptionDispatch+0x2e
0c 00000000`0868ef00 000007fe`fe03e1b6 gdi32!pmfAllocMF+0x2b0
0d 00000000`0868ef70 000007fe`fb10a646 gdi32!GetEnhMetaFileW+0x32
0e 00000000`0868efb0 000007fe`fb0c4959 GdiPlus!GpMetafile::GpMetafile+0x1c6
0f 00000000`0868f150 00000001`40001c35 GdiPlus!GdipCreateBitmapFromFile+0xc5
0:007> .frame /r 04
04 00000000`0868df10 00000000`7702ba8f kernel32!WerpReportFault+0x77
rax=00000000c0000001 rbx=0000000000000000 rcx=0000000002660000
rdx=0000000000000001 rsi=0000000000000001 rdi=000000000868e0b0
rip=000000007702ba37 rsp=000000000868df10 rbp=000000000868ff90
r8=000000000868d3f8 r9=000000000868d560 r10=0000000000000000
r11=0000000000000246 r12=000000000868e0b0 r13=0000000000000000
r14=0000000000000002 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000244
kernel32!WerpReportFault+0x77:
00000000`7702ba37 8b0d27ff0600 mov ecx,dword ptr [kernel32!RestrictedUserHandle+0xc (00000000`7709b964)] ds:00000000`7709b964=00000000
0:007> .exptr 000000000868e0b0
----- Exception record at 00000000`0868ecf0:
ExceptionAddress: 000007fefe03df54 (gdi32!pmfAllocMF+0x00000000000002b0)
ExceptionCode: c0000006 (In-page I/O error)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 0000000000000000
Parameter[1]: 0000000002610028
Parameter[2]: 00000000c00000be
Inpage operation failed at 0000000002610028, due to I/O error 00000000c00000be
----- Context record at 00000000`0868e800:
rax=0000000002610000 rbx=000000000e5fe7c0 rcx=0000000000006894
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=000007fefe03df54 rsp=000000000868ef00 rbp=0000000000000104
r8=000000000868ee38 r9=0000000000000104 r10=0000000000000000
r11=0000000000000286 r12=0000000000000001 r13=000000006d9cf760
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
gdi32!pmfAllocMF+0x2b0:
000007fe`fe03df54 81782820454d46 cmp dword ptr [rax+28h],464D4520h ds:00000000`02610028=????????
I did some research and found two ways of getting it without any plugins, relying on WinDBG magic, etc.
First, invoke k command in WinDBG. Find a portion of stack like this:
Child-SP RetAddr
00000000`0ab7d9d0 00007ff9`98baed2d exception handler
00000000`0ab7da10 00007ff9`98b16c86 ntdll!RtlpExecuteHandlerForException+0xd
00000000`0ab7da40 00007ff9`98badc5e ntdll!RtlDispatchException+0x3c6
00000000`0ab7e140 00007ff9`98b5b48a ntdll!KiUserExceptionDispatch+0x2e
00000000`0ab7e860 00007ff9`96925531 Function that crashed
Now you can find what you want in local variables:
Option 1: Use EXCEPTION_POINTERS structure saved on stack
.exptr 00000000`0ab7da10 - 0x20
Option 2: Use CONTEXT and EXCEPTION_RECORD separately
.cxr 00000000`0ab7e140
.exr 00000000`0ab7e140 + ##c++(sizeof(ntdll!_CONTEXT)) + 0x20
I need to find the offset of an instruction inside a program. Let's say I wanna find the position of open *system_call* in the program cat.
I used objdump to find the position inside the bin file.
objdump -T /bin/cat | grep open :
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 fdopen
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 open
0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 iconv_ope
Unfortunately, analyzing the sible table I cannot retrieve that information because the open function is linked dynamically. The open function is implemented in glibc.
Using the same approach on the Glibc library I retrieved the offset of the open function, though this offset refers to the position inside the /lib/libc.so.6 So this is not useful for me.
00000000000778d0 g DF .text 00000000000004e3 GLIBC_2.2.5 _IO_file_fopen
000000000006be50 g DF .text 000000000000000a GLIBC_2.2.5 fopen
0000000000073540 g DF .text 00000000000000f6 GLIBC_2.4 open_wmemstream
0000000000121cf0 w DF .text 0000000000000107 GLIBC_2.2.5 posix_openpt
000000000006d480 g DF .text 00000000000003bf GLIBC_2.2.5 _IO_proc_open
00000000000e38b0 g DF .text 0000000000000021 GLIBC_2.7 __open64_2
000000000006bfe0 g DF .text 00000000000000fa GLIBC_2.2.5 fopencookie
000000000006d840 g DF .text 0000000000000098 GLIBC_2.2.5 popen
00000000000ddd30 w DF .text 000000000000005e GLIBC_2.2.5 __open64
000000000006be50 g DF .text 000000000000000a GLIBC_2.2.5 _IO_fopen
00000000000de020 w DF .text 0000000000000020 GLIBC_2.7 __openat64_2
00000000000e84d0 g DF .text 0000000000000066 GLIBC_2.2.5 openlog
00000000000ddd30 w DF .text 000000000000005e GLIBC_2.2.5 open64
00000000003aa630 g DO .bss 0000000000000008 GLIBC_PRIVATE _dl_open_hook
00000000000ec840 g DF .text 000000000000005e GLIBC_2.14 open_by_handle_at
0000000000034250 g DF .text 0000000000000254 GLIBC_2.2.5 catopen
000000000006d840 g DF .text 0000000000000098 GLIBC_2.2.5 _IO_popen
0000000000075330 g DF .text 0000000000000355 GLIBC_2.2.5 freopen64
0000000000075eb0 g DF .text 00000000000001d8 GLIBC_2.2.5 fmemopen
00000000000b5b90 w DF .text 000000000000008b GLIBC_2.4 fdopendir
00000000000de020 g DF .text 0000000000000020 GLIBC_2.7 __openat_2
00000000000b5640 w DF .text 000000000000000d GLIBC_2.2.5 opendir
00000000000e3880 g DF .text 0000000000000021 GLIBC_2.7 __open_2
00000000000ddd30 w DF .text 000000000000005e GLIBC_2.2.5 __open
00000000000777f0 g DF .text 00000000000000d2 GLIBC_2.2.5 _IO_file_open
0000000000074370 g DF .text 00000000000000e6 GLIBC_2.2.5 open_memstream
0000000000073ab0 g DF .text 000000000000035d GLIBC_2.2.5 freopen
00000000000345a0 g DF .text 0000000000000837 GLIBC_PRIVATE __open_catalog
00000000000ddd30 w DF .text 000000000000005e GLIBC_2.2.5 open
000000000006b540 g DF .text 0000000000000249 GLIBC_2.2.5 fdopen
0000000000022b20 g DF .text 000000000000020a GLIBC_2.2.5 iconv_open
00000000000e2130 g DF .text 0000000000000373 GLIBC_2.2.5 fts_open
00000000000ddf80 w DF .text 0000000000000092 GLIBC_2.4 openat
000000000006be50 w DF .text 000000000000000a GLIBC_2.2.5 fopen64
00000000000ddf80 w DF .text 0000000000000092 GLIBC_2.4 openat64
0000000000122f30 g DF .text 0000000000000046 GLIBC_PRIVATE __libc_dlopen_mode
00000000000dc650 g DF .text 00000000000000b8 GLIBC_2.2.5 posix_spawn_file_actions_addopen
000000000006b540 g DF .text 0000000000000249 GLIBC_2.2.5 _IO_fdopen
I need the offset to set a tracer when the open function is called by the cat program. If I put a tracer on the Glibc lib I will trace that syscall each time it will be called.
Can you help me?
Have I been clear explaining my problem?
Thanks
Well, cat itself doesn't contain the open system call. It lives in glibc.so. cat calls the library to make use of the function. That's why when you look inside cat, there is no open function in it, it's "undefined" and refers to glibc.so.
You can of course find where cat calls open:
If you search for the symbol open#plt in the symbol table, that's where it calls open. For example objdump -dwhich cat|grep open#plt shows 0000000000401910 <open#plt>:, which is where the jump to the glibc function takes place.
I hope this helps.
Use /proc/$PID/maps to see where a shared object library's segments are loaded in the process memory. E.g.:
# grep libc /proc/$$/maps
7f3243879000-7f3243a2e000 r-xp 00000000 08:01 270246 /lib/x86_64-linux-gnu/libc-2.15.so
7f3243a2e000-7f3243c2d000 ---p 001b5000 08:01 270246 /lib/x86_64-linux-gnu/libc-2.15.so
7f3243c2d000-7f3243c31000 r--p 001b4000 08:01 270246 /lib/x86_64-linux-gnu/libc-2.15.so
7f3243c31000-7f3243c33000 rw-p 001b8000 08:01 270246 /lib/x86_64-linux-gnu/libc-2.15.so
-- so there are 4 segments of libc.so loaded into the address space of the process, we need an executable one, which is marked r-xp ("Read, no write, eXecute, Private"), its start is at *0x7f3243879000. You already know how to get relative offset for a symbols, e.g. freopen from your example is at 000000000000035d from the start of the executable segment, so in my example the symbol can be found at 7f3243879000 + 35d = *0x7f324387935d in the process memory.
A debugger with decent dynamic linker integration should handle this for you, resolving the symbolic name at which you wish to set a breakpoint. It can even do this when the library hasn't yet been loaded at the time you attempt to set the breakpoint.
However, be aware that there's not much of a syscall you can trace with a user-mode debugger. You can trace through the little libc stub which might do something such as re-order paramaters between the platform's C calling convention and its often different syscall convention, or implement a deprecated syscall as a wrapper around a new one, but the actual kernel mode implementation can only be traced with a kernel debugger.
You might also be interested in the strace program, which prints out the paramaters and return values of all syscalls. Another thing usefull in some cases is dynamic library interception, for example using LD_PRELOAD.
I get this error while loading a lib with dlopen():
Cannot dlopen load module '/usr/lib/pa20_64/libpthread.1' because it contains thread specific data.
I looked this up on google and the following export fixed it.
export LD_PRELOAD=/usr/lib/hpux64/libpthread.so.1
Can anybody tell me what exactly LD_PRELOAD does and why I have to preload this lib? Why does the linker not load it?
Compiling with -lpthread does not help either.
ENV: HP-UX hhtenb1 B.11.31 U ia64 3881169896 unlimited-user license
I can't tell you all the details on HPUX, but try linking your program with -lpthread - that may solve your problem.
As is, the library you're dlopen()ing seems to be digging around at run-time to find a version of libpthread. LD_PRELOAD just loads the specified library as if you'd dlopened them, but it does it before the program has a chance to start running.
Not sure of details, but a vague guess: some library you're using has called the pthread static data functions before your dlopen triggers a load of libpthread (but why would it try to load pthread then if the first library had it as a dependency? - not sure / maybe that indicates the former library statically linked some pthread content?).
We had this error below on hpux-11.31 IA64 running DB2-10.1.2 and doing the
"export LD_PRELOAD=/usr/lib/hpux64/libpthread.so.1"
fixed it.
DATA #2 : String, 49 bytes
/home/db2inst1/sqllib/lib64/icc/libgsk8iccs_64.so
CALLSTCK: (Static functions may not be resolved correctly, as they are resolved to the nearest symbol)
[0] 0xC000000032488900 pdOSSeLoggingCallback + 0x980
[1] 0xC000000010CC5A00 ossLog + 0x4E0
[2] 0xC000000010CC5610 ossLog + 0xF0
[3] 0xC00000003255E100 _Z27cryptDynamicLoadGSKitCryptoPc + 0x5F0
[4] 0xC00000003255F460 cryptContextRealInit + 0x200
[5] 0xC000000032561950 cryptContextCheckAndInit + 0x130
[6] 0xC000000032561B70 cryptDHInit + 0x120
[7] 0xC00000003384FBD0 sqlexSlcServerEncryptAccsec + 0x170
[8] 0xC00000003384F7B0 _Z33sqlexSlcServerEncryptAuthenticateP14db2UCinterfacelPj + 0xF0
[9] 0xC0000000321FB7D0 _Z20sqlexAppAuthenticateP14db2UCinterface + 0x1A60
[10] 0xC0000000321F8920 _Z18sqljrDrdaArConnectP14db2UCinterface + 0x140
[11] 0xC0000000321E96F0 _Z16sqleUCdrdaARinitP14db2UCconHandle + 0x230
[12] 0xC000000032238CD0 sqleUCappConnect + 0x13C0
[13] 0xC000000032647B20 _Z14CLI_sqlConnectP15CLI_CONNECTINFOP5sqlcaP19CLI_ERRORHEADERINFO + 0x32A0
[14] 0xC0000000325D5710 _Z11SQLConnect2P15CLI_CONNECTINFOPhsS1_sS1_sS1_sh + 0xA10
[15] 0xC0000000325ADB90 _Z17SQLDriverConnect2P15CLI_CONNECTINFOPvPhsS2_sPsthhP19CLI_ERRORHEADERINFO + 0x26E0
[16] 0xC0000000325AAC00 _Z11SQLConnect1P15CLI_CONNECTINFOPhsS1_sS1_s + 0xB60
[17] 0xC0000000325A8E30 SQLConnect + 0xC10
[18] 0x4000000000001EA0 main + 0x620
[19] 0xC00000000006E9B0 _DYNAMIC + 0xC00000000006E993