gi?id=26754
I've went through GDB's code looking for potential issues with the change and
whether
it would affect GDBs already in the wild. Tricky corner cases abound, but I
think
we're good. Feel free to add my ack:
Acked-by: Pedro Alves
Thanks,
Pedro Alves
On 06/21/2016 05:32 PM, Andy Lutomirski wrote:
> On Jun 21, 2016 5:40 AM, "Pedro Alves" wrote:
> I didn't try that particular experiment. But, from that email:
>
>> After that, GDB can control the stopped inferior. To call function "func1()"
>&g
198) exited with code 01]
(gdb) q
Is this expected?
This is the same testcase as before:
https://sourceware.org/ml/gdb/2014-05/msg4.html
Thanks,
Pedro Alves
y problem: seccomp is currently entirely insecure if a
>> malicious ptracer is attached.) As a minimal fix, this patch adds a
>> new flag TS_I386_REGS_POKED that handles the ptrace special case.
>>
>> Cc: Pedro Alves
>> Cc: Oleg Nesterov
>> Cc: Kees Cook
>>
t.
0xf7fd9d49 in __kernel_vsyscall ()
(gdb) p func1()
$1 = 4
(gdb) c
Continuing.
Unknown error 512
[Inferior 1 (process 20252) exited with code 01]
(gdb)
That was a 64-bit gdb.
Note it doesn't fail with fedora 23's gdb, because of a
fedora-local workaround.
Thanks,
Pedro Alves
https://www.sourceware.org/ml/gdb-patches/2015-11/msg00076.html
https://www.sourceware.org/ml/gdb-patches/2015-11/msg00077.html
Guess that makes fs_base/gs_base user-writable, if the kernel allows it.
Thanks,
Pedro Alves
On 06/18/2016 02:55 PM, Pedro Alves wrote:
> This hunk being mentioned in this thread a couple years ago too:
>
> https://www.sourceware.org/ml/gdb/2014-04/msg00095.html
>
> Please don't break this use case ( and fix the one reported in
> that thread :-) ).
BTW, there w
ior, with:
(gdb) print foo()
Some background here:
http://linux-kernel.vger.kernel.narkive.com/fqrh4xKK/patch-x86-ptrace-sign-extend-eax-with-orig-eax-0
This hunk being mentioned in this thread a couple years ago too:
https://www.sourceware.org/ml/gdb/2014-04/msg00095.html
Please don't break this use case ( and fix the one reported in
that thread :-) ).
Thanks,
Pedro Alves
had sufficient
time to be sure that a full test run passes cleanly too. :-P :-)
>> But maybe not, if we're sure that
>> that when that happens, waitpid returns for the initial
>> PTRACE_ATTACH-induced SIGSTOP.
>
> Yes. Just you can't assume that watpid(WNO
This queuing of a SIGSTOP + PTRACE_CONT was necessary because
otherwise when gdb attaches to a job stopped process, gdb would hang in the
waitpid
after PTRACE_ATTACH, waiting for the initial SIGSTOP which would never arrive.
If the proposed change makes it so that a new intermediate state can be ob
On 10/28/2015 04:11 PM, Oleg Nesterov wrote:
> On 10/26, Pedro Alves wrote:
>>
>> On 10/25/2015 03:54 PM, Oleg Nesterov wrote:
>>>
>>> In any case, the real question is whether we should change the kernel to
>>> fix the problem, or ask the distros to fi
el error out on PTRACE_TRACEME issued
from a non-leader thread? Then between PTRACE_TRACEME and the parent's
waitpid, __WALL or !__WALL should make no difference.
(Also, in the original test case, if the child gets/raises a signal or execs
before exiting, the bash/init/whatever process won
int *status, int options) = NULL;
+
+ if (waitpid2 == NULL)
+waitpid2 = dlsym (RTLD_NEXT, "waitpid");
+
+ options |= __WALL;
+ return waitpid2 (pid, status, options);
+}
~~
and got no regressions. So seems like all would be well from
GDB's perspectiv
On 06/12/2015 03:10 PM, Josh Poimboeuf wrote:
> On Fri, Jun 12, 2015 at 12:18:16PM +0100, Pedro Alves wrote:
>> On 06/11/2015 03:10 PM, Josh Poimboeuf wrote:
>>
>>> C would definitely make more sense when analyzing object code. In fact,
>>> asmvalidate is written
list the
following jump. And then if it's possible run a CFI generator
as a separate step over the source, it sounds like it should also
be possible to have the assembler do it instead too (again with
some new high level directive to trigger/help it).
Thanks,
Pedro Alves
--
To unsubscribe f
l
this is sorted.
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
wever, in vvar case,
sounds like there's nowhere to read it from offline? In that case,
it could be justified to dump it.
Thanks,
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo in
On 11/04/2014 11:55 PM, Oleg Nesterov wrote:
> On 11/03, Pedro Alves wrote:
>>
>> Thanks a lot Oleg.
>
> thanks for the detailed report ;)
>
>> Question - shouldn't ptrace tests be put in
>> tools/testing/selftests/ptrace/ in the kernel tree nowadays?
&g
Thanks a lot Oleg.
Question - shouldn't ptrace tests be put in
tools/testing/selftests/ptrace/ in the kernel tree nowadays?
Thanks,
Pedro Alves
On 11/03/2014 08:13 PM, Oleg Nesterov wrote:
> When the TIF_SINGLESTEP tracee dequeues a signal, handle_signal()
> clears TIF_FO
size.
>
> Signed-off-by: Anshuman Khandual
> ---
> NOTE:
> Pedro Alves has mentioned that producing smaller note sections in the core
> dump may break some existing consumers. I request suggestions, reviews and
> test reports on different architectures to prove that this patch does
On 05/20/2014 09:14 AM, Anshuman Khandual wrote:
> On 05/19/2014 08:13 PM, Pedro Alves wrote:
>> On 05/19/2014 12:46 PM, Anshuman Khandual wrote:
>>
>>>>> I couldn't actually find any arch that currently returns -ENODEV in
>>>>> the &quo
et)
> +{
> + if (!cpu_has_feature(CPU_FTR_TM))
> + return -ENODEV;
... unfortunately this will do the wrong thing.
Thanks,
--
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 05/15/2014 03:36 PM, Denys Vlasenko wrote:
> On 05/14/2014 08:49 PM, Pedro Alves wrote:
>> I realized now that I responded to this. Sorry about that.
>>
>> On 01/19/2014 03:29 PM, Oleg Nesterov wrote:
>>> On 01/19, Sergio Durigan Junior wrote:
>>>
On 05/15/2014 09:25 AM, Anshuman Khandual wrote:
> On 05/14/2014 04:45 PM, Pedro Alves wrote:
>> On 05/14/14 06:46, Anshuman Khandual wrote:
>>> On 05/13/2014 10:43 PM, Pedro Alves wrote:
>>>> On 05/05/14 08:54, Anshuman Khandual wrote:
>>>>> This patc
t;clone".
- PTRACE_EVENT_FORK is reported.
- The debugger does ptrace(PTRACE_CONT).
What should be reported? What is reported now?
--
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ng something to HWCAP too?
>
> Yes but it's in HWCAP2
That's fine.
--
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 05/14/14 06:46, Anshuman Khandual wrote:
> On 05/13/2014 10:43 PM, Pedro Alves wrote:
>> On 05/05/14 08:54, Anshuman Khandual wrote:
>>> This patch enables get and set of transactional memory related register
>>> sets through PTRACE_GETREGSET/PTRACE_SETREGSET interfa
On 05/14/14 08:10, Anshuman Khandual wrote:
> On 05/13/2014 11:39 PM, Pedro Alves wrote:
>> On 05/05/14 05:10, Anshuman Khandual wrote:
>>> On 05/01/2014 07:43 PM, Pedro Alves wrote:
>> OK, then this is what I suggest instead:
...
>>> Shall I resend the patch w
On 05/05/14 05:10, Anshuman Khandual wrote:
> On 05/01/2014 07:43 PM, Pedro Alves wrote:
>> On 04/28/2014 12:00 PM, Anshuman Khandual wrote:
>>> The current documentation is bit misleading and does not explicitly
>>> specify that iov.len need to be initialized failin
no longer
exists in the @redhat.com domain.
--
Pedro Alves
On 05/05/14 08:54, Anshuman Khandual wrote:
> This patch enables get and set of transactional memory related register
> sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing
> four new powerpc specific reg
t, what does the
kernel return when the ptracer requests these registers and the
program is not in a transaction? Specifically I'm wondering whether
this follows the same semantics as the s390 port.
--
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe lin
ust ignore the ptrace request and never read from/write into
> the user specified buffer.
You're saying that if iov.len is larger than the NT_XXX_TYPE regset,
then the kernel returns _success_, but actually doesn't fill the
buffer? That sounds like a bug to me.
--
Pedro Alves
--
On 04/28/2014 11:30 AM, Anshuman Khandual wrote:
> On 04/26/2014 05:12 AM, Pedro Alves wrote:
>> On 04/02/2014 08:02 AM, Anshuman Khandual wrote:
>>> This patch adds following new sets of ptrace request macros for
>>> transactional
>>> memory expandin
break;
>
> which gets used for 32-bit compat ptrace(2). Perhaps the same logic
> should be added to putreg() if the child is a 32-bit process?
Sounds like the right fix to me.
--
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Does this support PTRACE_GETREGSET / PTRACE_SETREGSET ?
IMO, the kernel shouldn't accept ports without those anymore.
And IMHO, we shouldn't even allow new ports having PTRACE_GETREGS.
http://sourceware.org/ml/archer/2010-q3/msg00193.html
--
Pedro Alves
--
To unsubscribe from this
d VMX registers */
> PTRACE_GETTM_CVMXREGS
> PTRACE_SETTM_CVMXREGS
Urgh, we're _still_ adding specialized register specific calls?
Why aren't these exported as new register sets, accessible through
PTRACE_GETREGSET / PTRACE_SETREGSET? That's supposed to be the
Modern Way to do thin
report an event.
+10^6. With PTRACE_SYSCALL/sysgood, we don't have a way to trace
syscalls when single-stepping, which isn't much of a problem for
strace, but of course is for GDB. That is one of the things the
new API should definitely sort out.
--
Pedro Alves
--
To unsubscribe
On 06/19/2013 05:09 PM, Jan Kratochvil wrote:
> On Wed, 19 Jun 2013 17:15:36 +0200, Denys Vlasenko wrote:
>> CCing Jan to hear his comments from gdb side.
PTRACE_DETACH takes a signal number in the data parameter.
What happens to if the tracer passes a non-zero signal?
--
Pedro Alv
dded later" comment instead of actually requesting it. But if
we had it, we could make e.g., gdb inspect the signal queues,
and then be able to tweak a realtime signal before it is
delivered.
--
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
On 02/15/2013 07:43 PM, Oleg Nesterov wrote:
> On 02/15, Pedro Alves wrote:
>>
>> Not sure I'm reading the patch right, but it looks like GDB would
>> be able to use this as alternative to PTRACE_GET_SIGINFO variant
>
> No, it is different. PTRACE_GETSIGINFO re
INT_RESTORE. We'd miss the poke
variant, but that looks like something that could be always be added
later.
--
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
d have only one macro for all
structs/enums (you could split into __IPV6_IN6_ADDR_DEFINED,
__IPV6_SOCKADDR_IN6_DEFINED, etc.) but to have the kernel
and libc agree on guard macros, instead of having the kernel
do #ifdef __GLIBC__ and glibc doing #ifdef _NETINET_IN_H.
But as Carlos says, th
ngle macro/symbol both the
kernel and libc (any libc that needs this) define? Something
like both the kernel and userland doing:
#ifndef __IPV6_BITS_DEFINED
#define __IPV6_BITS_DEFINED
...
define in6_addr, sockaddr_in6, ipv6_mreq, whatnot
#endif
So whichever the application includes first, wi
gt; will look as a "normal" syscall. Like vsyscall_seccomp() does.
>
> But this needs much more changes.
I'd just like to add, that if any new syscall related option is
to be added, can we please just go all the way and add
PTRACE_EVENT_SYSCALL_ENTER|PTRACE_EVENT_SYSCALL_E
On 11/08/2012 12:44 PM, Oleg Nesterov wrote:
> On 11/08, Pedro Alves wrote:
>> If this isn't inherited by the ptrace child's children, a fork child can
>> end up detached if the tracer dies before it had a chance of setting
>> the PTRACE_O_EXITKILL on the new
ace between PTRACE_ME/PTRACE_ATTACH and
setting PTRACE_SETOPTIONS).
(For completeness, Windows' age old equivalent,
DebugSetProcessKillOnExit, it a tracer option, not tracee option, though
that's not as flexible.)
--
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
biarch)
because
of this, for "(gdb) print $_siginfo".
I wish we had a PTRACE_GETSIGINFO variant that returned the siginfo_t in
layout of the program, not the kernel's..
> Note also that compat_binfmt_elf must deliver the 32-bit version
> of siginfo_t, i.e. as copy_siginfo_
ing itself. On the other hand, if
> the
> internal loop has actually ended, then node will be NULL, and the outer loop
> will keep running.
>
> Is there anything I've missed?
Looks right to me, from a cursory look at hlist_for_each_entry. That's exactly
what I meant
. It's the comma
that separates function parameters that doesn't guarantee ordering.
--
Pedro Alves
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 09/04/2012 09:59 PM, Steven Rostedt wrote:
> On Tue, 2012-09-04 at 18:21 +0100, Pedro Alves wrote:
>> On 09/04/2012 06:17 PM, Steven Rostedt wrote:
>>> On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
>>>
>>>> BTW, you can also go a step fu
On 09/04/2012 06:17 PM, Steven Rostedt wrote:
> On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
>
>> BTW, you can also go a step further and remove the need to close with double
>> }},
>> with something like:
>>
>> #d
On 09/04/2012 05:30 PM, Pedro Alves wrote:
> On 09/04/2012 04:35 PM, Steven Rostedt wrote:
>> On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
>>
>>> Looking again at:
>>>
>>> +#define hash_for_each_size(name, bits, bkt, node, obj, member)
\
for (_i = 0; _i < pg->index; _i++) {\
rec = &pg->records[_i];
(other variants possible)
IOW, the outer loop only iterates if the inner loop completes. If there's
a break in the inner loop, t
53 matches
Mail list logo
