Correct macro name for the i386 platform

[stacknip]

Some more info in this issue:
#5131

[crowell]

is this something unique to 32 bit x86? should there be an ifdef here?

[radare]

As a side note. The coredump thing is not supported on android. Will be nice to review that support right after merging the arm support

On 16 Aug 2016, at 22:45, stacknip [email protected] wrote:

You can view, comment on, or merge this pull request online at:

#5540

Commit Summary

Correct macro name for the i386 platform
File Changes

M libr/debug/p/native/linux/linux_coredump.c (2)
Patch Links:

https://github.com/radare/radare2/pull/5540.patch
https://github.com/radare/radare2/pull/5540.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[stacknip]

@crowell I was trying to find a quick answer to your question, but I couldn't. Right now it is in an ifdef, I assume with good reason.

[radare]

cc @leberus

[leberus]

Hi @stacknip , could you paste here the output of

$ grep -r PTRACE_GETREGSET /usr/include/

Thanks

Btw, your change is compiling, but it's not gonna give the expected results. We can't take NT_PRXFPREG just using PTRACE_GETREGS.

As you can see in arch/x86/kernel/ptrace.c

        [REGSET_XFP] = {
                .core_note_type = NT_PRXFPREG,
                .n = sizeof(struct user32_fxsr_struct) / sizeof(u32),
                .size = sizeof(u32), .align = sizeof(u32),
                .active = regset_xregset_fpregs_active, .get = xfpregs_get, .set = xfpregs_set
        },

Is using regset.

PD: For older kernels running on x86 we could use the same workaround as we use for linux_get_xsave_data, something like:

#if __i386__
static elf_fpxregset_t *linux_get_fpx_regset (int tid) {
#ifdef PTRACE_GETREGSET
        struct iovec transfer;
        elf_fpxregset_t *fpxregset = R_NEW0 (elf_fpxregset_t);

        if (!fpxregset) return NULL;
        transfer.iov_base = fpxregset;
        transfer.iov_len = sizeof (elf_fpxregset_t);
        if (ptrace (PTRACE_GETREGSET, tid, (unsigned int)NT_PRXFPREG, &transfer) < 0) {
                perror ("linux_get_fpx_regset");
                return NULL;
        }
        return fpxregset;
#else
        return NULL;
#endif
}
#endif

I could push that change if everybody is happy about that.

[stacknip]

@leberus You are on to something.

$grep -r -e "PTRACE_GETREGSET"
linux/elf.h: * using the corresponding note types via the PTRACE_GETREGSET and
linux/ptrace.h: * ret = ptrace(PTRACE_GETREGSET/PTRACE_SETREGSET, pid, NT_XXX_TYPE, &iov);
linux/ptrace.h:#define PTRACE_GETREGSET 0x4204

So it is defined in the file:
/usr/include/linux/ptrace.h

Though the header included in linux_coredump is sys/ptrace.h.
In my machine this is a reference to:
/usr/include/i386-linux-gnu/sys/ptrace.h
Which does not contain this macro.

Maybe add that header?

You will have to excuse me, I'm not really familiar with the code. I will leave any changes to the code up to you.
I hope this helps.

[leberus]

@stacknip Thanks for the output ;)

I guess you're using debian, aren't you?

Could you tell me the version of your libc6-dev package?

Thanks ;)

[stacknip]

@leberus Yes, I'm using Debian Wheezy.
It says that my libc version is 2.13 .

$dpkg --get-selection | grep libc6
libc6:i386 install
libc6-dev:i386 install
libc6-i686:i386 install

Gotta run now.

[leberus]

@stacknip It looks like before debian jessie, ptrace file version shipped with libc6-dev didn't contain that macro.
I'll try to think about the best way to fix this because including /usr/include/linux it's not the best idea, since can be differences between kernel headers and userspace headers.

I'll come back with something

[radare]

waiting for feedback from @leberus

[leberus]

With my last commit I've added a macro for i386, so if ptrace headers from userland don't contain PTRACE_GETREGSET, we bypass it.

Maybe I'll add the PTRACE_REGSET macro within linux_coredump.h (as it is in ../sys/ptrace.h), or I'll include /usr/include/linux/ptrace.h (but I'm not so amused about it).

Anyways, @stacknip: could you try to get the latest code from radare2 and compile it? You shouldn't have any problems anymore.

Once this is confirmed, this issue could be closed and the commit should be dropped (this commit will break the functionality about NT_PRXFPREG).

[stacknip]

It builds successfully! :)

[simonmysun]

Hi,

I'm experiencing a similar issue:

• during the installization, the output is almost the same as described in the issue comment

...
CC debug_windbg.c
CC linux_debug.c
CC procfs.c
CC linux_coredump.c
p/native/linux/linux_debug.c: In function 'linux_reg_read':
p/native/linux/linux_debug.c:1111:18: error: storage size of 'xstate' isn't known
p/native/linux/linux_debug.c:1114:24: error: invalid application of 'sizeof' to incomplete type 'struct _xstate'
p/native/linux/linux_debug.c:1115:30: error: 'PTRACE_GETREGSET' undeclared (first use in this function)
p/native/linux/linux_debug.c:1115:30: note: each undeclared identifier is reported only once for each function it appears in
p/native/linux/linux_debug.c:1111:18: warning: unused variable 'xstate' [-Wunused-variable]
gmake[4]: *** [p/native/linux/linux_debug.o] Error 1
gmake[4]: *** Waiting for unfinished jobs....
gmake[3]: *** [foo] Error 2
gmake[2]: *** [debug] Error 2
gmake[1]: *** [all] Error 2
gmake: *** [all] Error 2

• grep -r -e "PTRACE_GETREGSET" returns the same as the comment above

$ grep -r PTRACE_GETREGSET /usr/include/
/usr/include/linux/ptrace.h: *  ret = ptrace(PTRACE_GETREGSET/PTRACE_SETREGSET, pid, NT_XXX_TYPE, &iov);
/usr/include/linux/ptrace.h:#define PTRACE_GETREGSET    0x4204
/usr/include/linux/elf.h: * using the corresponding note types via the PTRACE_GETREGSET and

I cannot find what related code was changed during your conversation and cannot understand how to solve this issue. Could you please provide more details?

Here's my environment I find necessary to mention:

$ uname -a
Linux uit-xxxxxxx 2.6.32-754.6.3.el6.x86_64 #1 SMP Tue Sep 18 10:29:08 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
LSB Version:    :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 6.10 (Santiago)
Release:        6.10
Codename:       Santiago
$ gcc --version
gcc (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[radare]

probably in that old kernel there was only PTRACE_GETREG

…

On 22 Apr 2020, at 04:36, 孙茂胤 ***@***.***> wrote: Hi, I'm experiencing a similar issue: the output is almost the same as described in the issue comment <#5131 (comment)> ... CC debug_windbg.c CC linux_debug.c CC procfs.c CC linux_coredump.c p/native/linux/linux_debug.c: In function 'linux_reg_read': p/native/linux/linux_debug.c:1111:18: error: storage size of 'xstate' isn't known p/native/linux/linux_debug.c:1114:24: error: invalid application of 'sizeof' to incomplete type 'struct _xstate' p/native/linux/linux_debug.c:1115:30: error: 'PTRACE_GETREGSET' undeclared (first use in this function) p/native/linux/linux_debug.c:1115:30: note: each undeclared identifier is reported only once for each function it appears in p/native/linux/linux_debug.c:1111:18: warning: unused variable 'xstate' [-Wunused-variable] gmake[4]: *** [p/native/linux/linux_debug.o] Error 1 gmake[4]: *** Waiting for unfinished jobs.... gmake[3]: *** [foo] Error 2 gmake[2]: *** [debug] Error 2 gmake[1]: *** [all] Error 2 gmake: *** [all] Error 2 grep -r -e "PTRACE_GETREGSET" returns the same as the comment above <#5540 (comment)> $ grep -r PTRACE_GETREGSET /usr/include/ /usr/include/linux/ptrace.h: * ret = ptrace(PTRACE_GETREGSET/PTRACE_SETREGSET, pid, NT_XXX_TYPE, &iov); /usr/include/linux/ptrace.h:#define PTRACE_GETREGSET 0x4204 /usr/include/linux/elf.h: * using the corresponding note types via the PTRACE_GETREGSET and I cannot find what related code was changed during your conversation and cannot understand how to solve this issue. Could you please provide more details? Here's my environment I find necessary to mention: $ uname -a Linux uit-algo-d-21 2.6.32-754.6.3.el6.x86_64 #1 SMP Tue Sep 18 10:29:08 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux $ lsb_release -a LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 6.10 (Santiago) Release: 6.10 Codename: Santiago $ gcc --version gcc (GCC) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5540 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG75FW2F2SK4Z7TBA6HNITRNZJ4FANCNFSM4CMXKH6A>.

[simonmysun]

Fine. After making adjustment for this and also other issues I finally gave up because it wants root password.

Thanks anyway for creating this great software!

[ret2libc]

Fine. After making adjustment for this and also other issues I finally gave up because it wants root password.

Thanks anyway for creating this great software!

Hi @simonmysun !

Are you using ./sys/install.sh ? If so, then that's why it wants root password, as it tries to install radare2 in /usr/. If you want to install radare2 without root you can either use ./sys/user.sh or just set a prefix when running configure. Of course if you install it in your home directory, without root privileges, you will need to adjust your PATH and LD_LIBRARY_PATH to make sure you find the r2 binaries and the libraries.

For example:

$ ./configure --prefix=/home/ret2libc/.local
$ make CS_RELEASE=1
$ make install
$ export PATH=$PATH:/home/ret2libc/.local/bin
$ export LD_LIBRARY_PATH=/home/ret2libc/.local/lib
$ r2 -

However, on RHEL6 / CENTOS6 that won't work as you discovered. Those systems ship very old gcc/libs and we are not always able to test whether everything runs well on every system, so we appreciate user contributions. I am working on creating a CI test that we are going to run in the future to make sure radare2 can be at least compiled on such platforms (even though some runtime functions may not work). For a little bit unfortunately you won't be able to run radare2 on such systems, but there is already work ongoing to make sure it will be possible again (see #16712 and tree-sitter/tree-sitter#604 ).

Hope it helps :)

[simonmysun]

Hi @ret2libc ,

Thanks for the guidance! I was indeed giving up too early. That's because I was leaving my working environment.

So I have successfully compiled it and it works great!

To whom it may concern, here are the changes I have made before the compilation in my environment mentioned above:

• In ./libr/debug/p/native/linux/linux_debug.c I first replaced PTRACE_GETREGSET in Line 1115 with PTRACE_GETREGS but then it cannot find the definition of x_state at Line 1111 so I commented the whole block under case R_REG_TYPE_YMM: (did not expect it would work actually, and it should have broken some features)
• In ./libr/core/cmd.c Line 5069 I replaced for (int i = 0; i < rep; i ++) { with int i; plus for (i = 0; i < rep; i ++) because gcc yields that the original one is only allowed in c99 mode. I did not change the Makefile because it's the only related occurrence with this format. I will create a pull request for this. @radare has already made pull request on this: Avoid the use of 'for (int' constructions ##build #16718
• In ./global.mk I added LDFLAGS+=-lrt to make it compatible for glibc@"<2.17" (mine here is 2.12)
• In ./sys/build.sh I changed FREE_RAM=$(grep MemAvailable /proc/meminfo | sed 's/[^0-9]//g') to grep on MemFree because MemAvailable is introduced in linux 3.14. But this led to compiling with all 384 cores so I limited it with nproc(mine here is 144. not sure where this number is from) because I don't want to engage all the resource and I don't expect much performance improvement when there are too many jobs parallelized. I will not make a pull request about it because I don't know what is good.

Many thanks again for this great software!

[ret2libc]

* In `./libr/debug/p/native/linux/linux_debug.c` I first replaced `PTRACE_GETREGSET` in Line 1115 with `PTRACE_GETREGS` but then it cannot find the definition of `x_state` at Line 1111 so I commented the whole block under `case R_REG_TYPE_YMM:` (did not expect it would work actually, and it should have broken some features)

* In `./libr/core/cmd.c` Line 5069 I replaced `for (int i = 0; i < rep; i ++) {` with `int i;` plus `for (i = 0; i < rep; i ++)` because gcc yields that the original one is only allowed in c99 mode. I did not change the Makefile because it's the only related occurrence with this format. ~I will create a pull request for this. ~ @radare has already made pull request on this: #16718

* In `./global.mk` I added `LDFLAGS+=-lrt` to make it compatible for glibc@"<2.17" (mine here is 2.12)

Yes, we are already working on this at #16712 . We are also adding centos6 build to our CI so that in can try to keep radare2 compiling on that platform at least.

* In `./sys/build.sh` I changed `FREE_RAM=$(grep MemAvailable /proc/meminfo | sed 's/[^0-9]//g')` to grep on `MemFree` because `MemAvailable` is introduced in linux 3.14. But this led to compiling with all 384 cores so I limited it with `nproc`(mine here is 144. not sure where this number is from) because I don't want to engage all the resource and I don't expect much performance improvement when there are too many jobs parallelized. I will not make a pull request about it because I don't know what is good.

Ok, nice catch I will have a look!

Thanks :)