|
From: Christian B. <bor...@de...> - 2011-05-07 20:20:37
|
Nightly build on fedora390 ( Fedora 13/14/15 mix with gcc 3.5.3 on z196 (s390x) )
Started at 2011-05-07 22:10:01 CEST
Ended at 2011-05-07 22:19:50 CEST
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... failed
Last 20 lines of verbose log follow echo
mv -f .deps/libreplacemalloc_toolpreload_s390x_linux_a-vg_replace_malloc.Tpo .deps/libreplacemalloc_toolpreload_s390x_linux_a-vg_replace_malloc.Po
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_s390x=1 -DVGO_linux=1 -DVGP_s390x_linux=1 -I../coregrind -DVG_LIBDIR="\"/home/cborntra/valgrind-nightly/valgrind-new/Inst/lib/valgrind"\" -DVG_PLATFORM="\"s390x-linux\"" -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT vgdb-vgdb.o -MD -MP -MF .deps/vgdb-vgdb.Tpo -c -o vgdb-vgdb.o `test -f 'vgdb.c' || echo './'`vgdb.c
vgdb.c: In function 'getregs':
vgdb.c:637:30: error: 'PT_ENDREGS' undeclared (first use in this function)
vgdb.c:637:30: note: each undeclared identifier is reported only once for each function it appears in
vgdb.c: In function 'setregs':
vgdb.c:669:30: error: 'PT_ENDREGS' undeclared (first use in this function)
vgdb.c: At top level:
vgdb.c:298:5: warning: 'ptrace_write_memory' defined but not used
make[3]: *** [vgdb-vgdb.o] Error 1
make[3]: *** Waiting for unfinished jobs....
mv -f .deps/valgrind-m_debuglog.Tpo .deps/valgrind-m_debuglog.Po
mv -f .deps/libcoregrind_s390x_linux_a-syswrap-generic.Tpo .deps/libcoregrind_s390x_linux_a-syswrap-generic.Po
mv -f .deps/libcoregrind_s390x_linux_a-syswrap-linux.Tpo .deps/libcoregrind_s390x_linux_a-syswrap-linux.Po
make[3]: Leaving directory `/home/cborntra/valgrind-nightly/valgrind-new/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/cborntra/valgrind-nightly/valgrind-new/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/cborntra/valgrind-nightly/valgrind-new'
make: *** [all] Error 2
=================================================
== Results from 24 hours ago ==
=================================================
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... failed
Regression test results follow
== 460 tests, 6 stderr failures, 0 stdout failures, 0 post failures ==
helgrind/tests/tc06_two_races_xml (stderr)
helgrind/tests/tc20_verifywrap (stderr)
helgrind/tests/tc23_bogus_condwait (stderr)
drd/tests/tc04_free_lock (stderr)
drd/tests/tc09_bad_unlock (stderr)
drd/tests/tc23_bogus_condwait (stderr)
=================================================
== Difference between 24 hours ago and now ==
=================================================
*** old.short Sat May 7 22:18:58 2011
--- new.short Sat May 7 22:19:50 2011
***************
*** 3,16 ****
Configuring valgrind ... done
! Building valgrind ... done
! Running regression tests ... failed
!
! Regression test results follow
!
! == 460 tests, 6 stderr failures, 0 stdout failures, 0 post failures ==
! helgrind/tests/tc06_two_races_xml (stderr)
! helgrind/tests/tc20_verifywrap (stderr)
! helgrind/tests/tc23_bogus_condwait (stderr)
! drd/tests/tc04_free_lock (stderr)
! drd/tests/tc09_bad_unlock (stderr)
! drd/tests/tc23_bogus_condwait (stderr)
--- 3,26 ----
Configuring valgrind ... done
! Building valgrind ... failed
+ Last 20 lines of verbose log follow echo
+ mv -f .deps/libreplacemalloc_toolpreload_s390x_linux_a-vg_replace_malloc.Tpo .deps/libreplacemalloc_toolpreload_s390x_linux_a-vg_replace_malloc.Po
+ gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_s390x=1 -DVGO_linux=1 -DVGP_s390x_linux=1 -I../coregrind -DVG_LIBDIR="\"/home/cborntra/valgrind-nightly/valgrind-new/Inst/lib/valgrind"\" -DVG_PLATFORM="\"s390x-linux\"" -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT vgdb-vgdb.o -MD -MP -MF .deps/vgdb-vgdb.Tpo -c -o vgdb-vgdb.o `test -f 'vgdb.c' || echo './'`vgdb.c
+ vgdb.c: In function 'getregs':
+ vgdb.c:637:30: error: 'PT_ENDREGS' undeclared (first use in this function)
+ vgdb.c:637:30: note: each undeclared identifier is reported only once for each function it appears in
+ vgdb.c: In function 'setregs':
+ vgdb.c:669:30: error: 'PT_ENDREGS' undeclared (first use in this function)
+ vgdb.c: At top level:
+ vgdb.c:298:5: warning: 'ptrace_write_memory' defined but not used
+ make[3]: *** [vgdb-vgdb.o] Error 1
+ make[3]: *** Waiting for unfinished jobs....
+ mv -f .deps/valgrind-m_debuglog.Tpo .deps/valgrind-m_debuglog.Po
+ mv -f .deps/libcoregrind_s390x_linux_a-syswrap-generic.Tpo .deps/libcoregrind_s390x_linux_a-syswrap-generic.Po
+ mv -f .deps/libcoregrind_s390x_linux_a-syswrap-linux.Tpo .deps/libcoregrind_s390x_linux_a-syswrap-linux.Po
+ make[3]: Leaving directory `/home/cborntra/valgrind-nightly/valgrind-new/coregrind'
+ make[2]: *** [all] Error 2
+ make[2]: Leaving directory `/home/cborntra/valgrind-nightly/valgrind-new/coregrind'
+ make[1]: *** [all-recursive] Error 1
+ make[1]: Leaving directory `/home/cborntra/valgrind-nightly/valgrind-new'
+ make: *** [all] Error 2
|
|
From: Philippe W. <phi...@sk...> - 2011-05-08 07:47:13
|
Christian/Florian,
With reference to the below build failure I have seen:
> vgdb.c: In function 'getregs':
> vgdb.c:637:30: error: 'PT_ENDREGS' undeclared (first use in this function)
> vgdb.c: In function 'setregs':
> vgdb.c:669:30: error: 'PT_ENDREGS' undeclared (first use in this function)
vgdb.c does not compile on
Fedora 13/14/15 mix with gcc 3.5.3 on z196 (s390x)
SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x)
On Linux 2.6.9-42.EL s390x RH EL AS release 4 (Nahant Update 4),
it is defined with the following chain of include:
vgdb.c:#include <sys/user.h>
sys/user.h:#include <asm/user.h>
asm/user.h:# include <asm-s390x/user.h>
asm-s390x/user.h:#include <linux/ptrace.h>
linux/ptrace.h:#include <asm/ptrace.h>
asm/ptrace.h:# include <asm-s390x/ptrace.h>
asm-s390x/ptrace.h:#define PT_ENDREGS 0x1B0-1
Here are some extracts of asm-s390x/ptrace.h
...
/*
* Offsets in the user_regs_struct. They are used for the ptrace
* system call and in entry.S
*/
#define PT_PSWMASK 0x00
#define PT_PSWADDR 0x08
#define PT_GPR0 0x10
#define PT_GPR1 0x18
....
#define PT_IEEE_IP 0x1A8
#define PT_LASTOFF PT_IEEE_IP
#define PT_ENDREGS 0x1B0-1
...
/*
* The user_regs_struct defines the way the user registers are
* store on the stack for signal handling.
*/
struct user_regs_struct
{
psw_t psw;
unsigned long gprs[NUM_GPRS];
unsigned int acrs[NUM_ACRS];
unsigned long orig_gpr2;
s390_fp_regs fp_regs;
/*
* These per registers are in here so that gdb can modify them
* itself as there is no "official" ptrace interface for hardware
* watchpoints. This is the way intel does it.
*/
per_struct per_info;
unsigned long ieee_instruction_pointer;
/* Used to give failing instruction back to user for ieee exceptions */
};
The objective of the piece of code in vgdb.c using PT_ENDREGS is to
get or set the general registers of the process to allow vgdb.c
to force the invokation of gdbserver if the valgrind process is blocked
in a syscall.
On the s390x system I have access to (the CDSL, RH4), The value of PT_ENDREGS
is 431 while the sizeof(struct user_regs_struct) is 432.
To allow vgdb.c to compile on s390x fedora and suse, maybe I could replace
PT_ENDREGS by sizeof(struct user_regs_struct)-1 ?
Do you think this is ok ?
Note that there are regression tests in valgrind/gdbserver_tests which
are testing this aspect of vgdb.c.
|
|
From: Christian B. <bor...@de...> - 2011-05-08 20:09:49
|
On 08/05/11 09:47, Philippe Waroquiers wrote: > Christian/Florian, With reference to the below build failure I have seen: >> vgdb.c: In function 'getregs': >> vgdb.c:637:30: error: 'PT_ENDREGS' undeclared (first use in this function) >> vgdb.c: In function 'setregs': >> vgdb.c:669:30: error: 'PT_ENDREGS' undeclared (first use in this function) > > vgdb.c does not compile on > Fedora 13/14/15 mix with gcc 3.5.3 on z196 (s390x) > SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x) > On Linux 2.6.9-42.EL s390x RH EL AS release 4 (Nahant Update 4), > it is defined with the following chain of include: > vgdb.c:#include <sys/user.h> > sys/user.h:#include <asm/user.h> > asm/user.h:# include <asm-s390x/user.h> > asm-s390x/user.h:#include <linux/ptrace.h> > linux/ptrace.h:#include <asm/ptrace.h> > asm/ptrace.h:# include <asm-s390x/ptrace.h> > asm-s390x/ptrace.h:#define PT_ENDREGS 0x1B0-1 Can you include linux/ptrace.h in vgdb.c? That should work on the old RHEL4 as well as on newer systems. Index: coregrind/vgdb.c =================================================================== --- coregrind/vgdb.c (revision 11727) +++ coregrind/vgdb.c (working copy) @@ -51,6 +51,7 @@ # if defined(VGO_linux) #include <sys/prctl.h> +#include <linux/ptrace.h> # endif /* vgdb has two usages: |
|
From: Florian K. <br...@ac...> - 2011-05-09 20:15:21
|
On 05/08/2011 04:09 PM, Christian Borntraeger wrote:
> On 08/05/11 09:47, Philippe Waroquiers wrote:
>> Christian/Florian, With reference to the below build failure I have seen:
>>> vgdb.c: In function 'getregs':
>>> vgdb.c:637:30: error: 'PT_ENDREGS' undeclared (first use in this function)
>>> vgdb.c: In function 'setregs':
>>> vgdb.c:669:30: error: 'PT_ENDREGS' undeclared (first use in this function)
>>
>> vgdb.c does not compile on
>> Fedora 13/14/15 mix with gcc 3.5.3 on z196 (s390x)
>> SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x)
>> On Linux 2.6.9-42.EL s390x RH EL AS release 4 (Nahant Update 4),
>> it is defined with the following chain of include:
>> vgdb.c:#include <sys/user.h>
>> sys/user.h:#include <asm/user.h>
>> asm/user.h:# include <asm-s390x/user.h>
>> asm-s390x/user.h:#include <linux/ptrace.h>
>> linux/ptrace.h:#include <asm/ptrace.h>
>> asm/ptrace.h:# include <asm-s390x/ptrace.h>
>> asm-s390x/ptrace.h:#define PT_ENDREGS 0x1B0-1
>
>
>
> Can you include linux/ptrace.h in vgdb.c? That should work
> on the old RHEL4 as well as on newer systems.
>
On my system Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
(vmlinuz-2.6.9-42.EL) with glibc-2.3.4-2.25 the symbol PT_ENDREGS
is found here:
florian@l005036:/usr/include> find . -exec grep -H PT_ENDREGS {} \;
./asm-s390/ptrace.h:#define PT_ENDREGS 0x140-1
./asm-s390x/ptrace.h:#define PT_ENDREGS 0x1B0-1
So your suggestion would probably not work.
Florian
|
|
From: Julian S. <js...@ac...> - 2011-05-09 21:00:29
|
On Monday, May 09, 2011, Maynard Johnson wrote:
> Valgrind builds OK on SLES 11 SP1. Comparing ptrace header files between
> SLES 10 and SLES 11 SP1, I see that PTRACE_{GET|SET}REGS is most assuredly
> *not* defined in SLES 10. Is this a PowerPC issue only?
Maynard, are you 110% sure about that? IIUC, the lack of PTRACE_{GET|SET}REGS
functionality would make ptrace() pretty darn useless.
Also .. if you try Christian's suggestion ..
> Can you include linux/ptrace.h in vgdb.c? That should work
> on the old RHEL4 as well as on newer systems.
.. does that help?
FWIW (probably not much), I had no problems this morning building on a
970 box running F11 (I think).
J
|
|
From: Maynard J. <may...@us...> - 2011-05-09 16:09:11
|
Christian Borntraeger wrote:
> On 08/05/11 09:47, Philippe Waroquiers wrote:
>> Christian/Florian, With reference to the below build failure I have seen:
>>> vgdb.c: In function 'getregs':
>>> vgdb.c:637:30: error: 'PT_ENDREGS' undeclared (first use in this function)
>>> vgdb.c: In function 'setregs':
>>> vgdb.c:669:30: error: 'PT_ENDREGS' undeclared (first use in this function)
>>
>> vgdb.c does not compile on
>> Fedora 13/14/15 mix with gcc 3.5.3 on z196 (s390x)
>> SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x)
I also get compile errors with ppc64, but on older distros like SLES 10 and RHEL 5. The compilation error is different, though:
---------
make[1]: Entering directory `/home/mpj/ISA2.06/NEW/upstream/valg_svn_05.09.2011_BUILD/coregrind'
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_ppc64=1 -DVGO_linux=1 -DVGP_ppc64_linux=1 -I../coregrind -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -DVG_PLATFORM="\"ppc64-linux\"" -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT vgdb-vgdb.o -MD -MP -MF .deps/vgdb-vgdb.Tpo -c -o vgdb-vgdb.o `test -f 'vgdb.c' || echo './'`vgdb.c
vgdb.c: In function ?getregs?:
vgdb.c:650:18: error: ?PTRACE_GETREGS? undeclared (first use in this function)
vgdb.c:650:18: note: each undeclared identifier is reported only once for each function it appears in
vgdb.c: In function ?setregs?:
vgdb.c:682:18: error: ?PTRACE_SETREGS? undeclared (first use in this function)
vgdb.c: At top level:
vgdb.c:299:5: warning: ?ptrace_write_memory? defined but not used
make[1]: *** [vgdb-vgdb.o] Error 1
---------
Valgrind builds OK on SLES 11 SP1. Comparing ptrace header files between SLES 10 and SLES 11 SP1, I see that PTRACE_{GET|SET}REGS is most assuredly *not* defined in SLES 10. Is this a PowerPC issue only?
-Maynard
>> On Linux 2.6.9-42.EL s390x RH EL AS release 4 (Nahant Update 4),
>> it is defined with the following chain of include:
>> vgdb.c:#include <sys/user.h>
>> sys/user.h:#include <asm/user.h>
>> asm/user.h:# include <asm-s390x/user.h>
>> asm-s390x/user.h:#include <linux/ptrace.h>
>> linux/ptrace.h:#include <asm/ptrace.h>
>> asm/ptrace.h:# include <asm-s390x/ptrace.h>
>> asm-s390x/ptrace.h:#define PT_ENDREGS 0x1B0-1
>
>
>
> Can you include linux/ptrace.h in vgdb.c? That should work
> on the old RHEL4 as well as on newer systems.
>
> Index: coregrind/vgdb.c
> ===================================================================
> --- coregrind/vgdb.c (revision 11727)
> +++ coregrind/vgdb.c (working copy)
> @@ -51,6 +51,7 @@
>
> # if defined(VGO_linux)
> #include <sys/prctl.h>
> +#include <linux/ptrace.h>
> # endif
>
> /* vgdb has two usages:
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Philippe W. <phi...@sk...> - 2011-05-09 19:02:03
|
From: "Maynard Johnson" <may...@us...>
> I also get compile errors with ppc64, but on older distros like SLES 10 and RHEL 5. The compilation error is different, though:
...
> Valgrind builds OK on SLES 11 SP1. Comparing ptrace header files between SLES 10 and SLES 11 SP1, I see that PTRACE_{GET|SET}REGS
> is most assuredly *not* defined in SLES 10. Is this a PowerPC issue only?
vgdb.c (and the rest of the gdbserver patch) has been compiled on various combinations of arch and platforms.
(a.o. on RHEL5 x86_64).
>From what I can see, depending on the OS and the arch, we can have:
PTRACE_GETREGS not defined
PTRACE_GETREGS defined, but returning an error at runtime if used.
PTRACE_GETREGS defined and working.
I will update vgdb.c so that it handles the above 3 cases (doing checks at compile time
and/or at runtime), which should solve the vgdb.c compilation problem for all linux platforms.
(there is no compilation problem on Darwin, because the ptrace support has not been
done for Darwin. There is however a link problem on Darwin/x86 that I do not understand).
Philippe
|
|
From: Maynard J. <may...@us...> - 2011-05-09 21:08:11
|
Philippe Waroquiers wrote:
> From: "Maynard Johnson" <may...@us...>
>> I also get compile errors with ppc64, but on older distros like SLES 10 and RHEL 5. The compilation error is different, though:
> ...
>> Valgrind builds OK on SLES 11 SP1. Comparing ptrace header files between SLES 10 and SLES 11 SP1, I see that PTRACE_{GET|SET}REGS
>> is most assuredly *not* defined in SLES 10. Is this a PowerPC issue only?
>
> vgdb.c (and the rest of the gdbserver patch) has been compiled on various combinations of arch and platforms.
> (a.o. on RHEL5 x86_64).
>
> From what I can see, depending on the OS and the arch, we can have:
> PTRACE_GETREGS not defined
> PTRACE_GETREGS defined, but returning an error at runtime if used.
> PTRACE_GETREGS defined and working.
>
> I will update vgdb.c so that it handles the above 3 cases (doing checks at compile time
> and/or at runtime), which should solve the vgdb.c compilation problem for all linux platforms.
Thanks, Philippe, that would be good. Just FYI . . . here's a link to a kernel commit that should provide you with a bit more background regarding the PowerPC part of the story: http://www.mail-archive.com/git...@vg.../msg17265.html.
-Maynard
>
> (there is no compilation problem on Darwin, because the ptrace support has not been
> done for Darwin. There is however a link problem on Darwin/x86 that I do not understand).
>
>
> Philippe
>
|
|
From: Tom H. <to...@co...> - 2011-05-09 21:12:54
|
On 09/05/11 21:46, Julian Seward wrote:
> On Monday, May 09, 2011, Maynard Johnson wrote:
>
>> Valgrind builds OK on SLES 11 SP1. Comparing ptrace header files between
>> SLES 10 and SLES 11 SP1, I see that PTRACE_{GET|SET}REGS is most assuredly
>> *not* defined in SLES 10. Is this a PowerPC issue only?
>
> Maynard, are you 110% sure about that? IIUC, the lack of PTRACE_{GET|SET}REGS
> functionality would make ptrace() pretty darn useless.
Why? You would still have {PEEK|POKE}USER, you just wouldn't be able to
do multiple registers at once.
The {GET|SET}REGS opcodes were added to the original API to allow
efficient access to multiple registers at once - they are an
optimisation and not essential.
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|
|
From: Julian S. <js...@ac...> - 2011-05-09 21:36:32
|
On Monday, May 09, 2011, Tom Hughes wrote:
> On 09/05/11 21:46, Julian Seward wrote:
> > On Monday, May 09, 2011, Maynard Johnson wrote:
> >> Valgrind builds OK on SLES 11 SP1. Comparing ptrace header files
> >> between SLES 10 and SLES 11 SP1, I see that PTRACE_{GET|SET}REGS is
> >> most assuredly *not* defined in SLES 10. Is this a PowerPC issue only?
> >
> > Maynard, are you 110% sure about that? IIUC, the lack of
> > PTRACE_{GET|SET}REGS functionality would make ptrace() pretty darn
> > useless.
>
> Why? You would still have {PEEK|POKE}USER, you just wouldn't be able to
> do multiple registers at once.
You're right .. I'm ill-informed. (I kinda suspected PTRACE_{GET|SET}REGS
were an en-masse enhancement of {PEEK|POKE}USER, but only after I
sent the above message :-(
J
|
|
From: Philippe W. <phi...@sk...> - 2011-05-09 22:51:21
|
>> From what I can see, depending on the OS and the arch, we can have: >> PTRACE_GETREGS not defined >> PTRACE_GETREGS defined, but returning an error at runtime if used. >> PTRACE_GETREGS defined and working. >> >> I will update vgdb.c so that it handles the above 3 cases (doing checks at compile time >> and/or at runtime), which should solve the vgdb.c compilation problem for all linux platforms. I have just uploaded under https://bugs.kde.org/show_bug.cgi?id=214909 under the comment 69 a patch that improves the situation of the gdbserver tests on some platforms and a fix to vgdb.c that should make it compîle on all platforms. Together with (r11735) , when the patch in comment 69 is committed, valgrind should be buildable again on linux and darwin platforms. Philippe |
|
From: Maynard J. <may...@us...> - 2011-05-10 00:18:38
|
Philippe Waroquiers wrote: >>> From what I can see, depending on the OS and the arch, we can have: >>> PTRACE_GETREGS not defined >>> PTRACE_GETREGS defined, but returning an error at runtime if used. >>> PTRACE_GETREGS defined and working. >>> >>> I will update vgdb.c so that it handles the above 3 cases (doing checks at compile time >>> and/or at runtime), which should solve the vgdb.c compilation problem for all linux platforms. > > I have just uploaded under https://bugs.kde.org/show_bug.cgi?id=214909 > under the comment 69 a patch that improves the situation of the gdbserver tests > on some platforms and a fix to vgdb.c that should make it compîle on all platforms. > > Together with (r11735) , when the patch in comment 69 is committed, valgrind should > be buildable again on linux and darwin platforms. Philippe, Thanks! The patch allowed me to build and run the testsuite for the ppc64 arch. -Maynard > > Philippe > |
|
From: Christian B. <bor...@de...> - 2011-05-10 07:17:33
|
>> Can you include linux/ptrace.h in vgdb.c? That should work
>> on the old RHEL4 as well as on newer systems.
>>
>
> On my system Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
> (vmlinuz-2.6.9-42.EL) with glibc-2.3.4-2.25 the symbol PT_ENDREGS
> is found here:
>
> florian@l005036:/usr/include> find . -exec grep -H PT_ENDREGS {} \;
> ./asm-s390/ptrace.h:#define PT_ENDREGS 0x140-1
> ./asm-s390x/ptrace.h:#define PT_ENDREGS 0x1B0-1
>
> So your suggestion would probably not work.
All ptrace specific stuff can be taken from linux/ptrace.h.
Having sys/user.h included the definitions was just a coincidence.
linux/ptrace.h will include the right asm define.
|