This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902)

On 03/12/2015 04:05 PM, Oleg Nesterov wrote:
> On 03/12, Pedro Alves wrote:
>> On 03/12/2015 03:00 PM, Oleg Nesterov wrote:
>>> However. If (for any reason) you decide to dump this region, gdb can
>>> look into /proc/self/maps, find its own "vvar" mapping, and simply read
>>> this memory. Unlike "vdso", "vvar" has the same content for every process.
>> Actually it can't: GDB may well be dumping the memory of
>> a process running on another machine (through gdbserver).
> Yes, thanks for correcting me...
> I do not know if gdb can ask gdbserver to read its own memory, but even if
> it can this doesn't look like a nice solution.

Not currently, it can't.

> Just curious... I know that gdb can execute the code on behalf of the traced
> process, so perhaps it can force the tracee to memcpy() its "vvar" memory.
> Can this work with gdbserver? Again, I do not think this hack can make any
> sense. I am just curious.

Yes, that can work.  But it's horrible.  :-)  If the user is dumping the
process's core, it's likely because the traced process is already in a
not-so-good / corrupted state.  Forcing it to run more code may make
things worse.

> At least (I hope) this mapping doesn't look "important" from debugging pov,
> perhaps gdb should ignore it. Lets see what Andy thinks, 

Agreed, let's hear what Andy says.

> but I bet it is
> very unlikely that the kernel will be changed to allow the access to this
> vma.

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]