From: Pedro Alves <palves@redhat.com>
To: John Baldwin <jhb@freebsd.org>
Cc: gdb-patches@sourceware.org, binutils@sourceware.org
Subject: Re: [PATCH v2 3/6] Display per-thread information for threads in FreeBSD cores.
Date: Mon, 18 Jan 2016 12:27:00 -0000 [thread overview]
Message-ID: <569CDA29.3050000@redhat.com> (raw)
In-Reply-To: <2320320.x23qbZCVbY@ralph.baldwin.cx>
On 01/15/2016 08:13 PM, John Baldwin wrote:
> On Thursday, January 14, 2016 03:03:50 PM Pedro Alves wrote:
>> On 01/13/2016 09:45 PM, John Baldwin wrote:
>>>
>>>
>>> +/* This is how we want PTIDs from core files to be printed. */
>>> +
>>> +static char *
>>> +fbsd_core_pid_to_str (struct gdbarch *gdbarch, ptid_t ptid)
>>> +{
>>> + static char buf[80], name[64];
>>
>> This static "name" buffer appears unused, and then masked
>> by the "name" pointer below.
>
> Yes, it was from an earlier rev of the patch before I switched to
> alloca(). Removed.
>>
>>> + struct bfd_section *section;
>>> + bfd_size_type size;
>>> + char sectionstr[32];
>>> +
>>> + if (ptid_get_lwp (ptid) != 0)
>>> + {
>>> + snprintf (sectionstr, sizeof sectionstr, ".thrmisc/%ld",
>>> + ptid_get_lwp (ptid));
>>
>> xsnprintf.
>
> Fixed here and throughout.
>
>>> + section = bfd_get_section_by_name (core_bfd, sectionstr);
>>> + if (section != NULL)
>>> + {
>>> + char *name;
>>> +
>>> + size = bfd_section_size (core_bfd, section);
>>> + name = alloca (size + 1);
>>> + if (bfd_get_section_contents (core_bfd, section, name, (file_ptr) 0,
>>> + size) && name[0] != '\0')
>>
>> This indentation / line break reads unusual to me. I think breaking
>> before the && would be clearer:
>>
>> if (bfd_get_section_contents (core_bfd, section, name,
>> (file_ptr) 0, size)
>> && name[0] != '\0')
>>
>> Guess this should check size > 0 as well, otherwise name[0] contains
>> garbage.
>
> Ok. I decided to check the size in the earlier if statement to avoid
> the alloca(), etc. when the size is zero.
>
>>> + {
>>> + name[size] = '\0';
>>> + if (strcmp(name, elf_tdata (core_bfd)->core->program) != 0)
>>
>> Missing space after strcmp.
>
> Fixed.
>
>> Is this ".thrmisc" section documented somewhere? Could you add a
>> small comment on what this entry you're skipping means?
>
> It is not documented aside from the code unfortunately. :( If I had my
> way we would be dumping the full ptrace_lwpinfo structure that contains
> per-LWP info used by the 'nat' target instead (it has other potentially
> useful information such as the siginfo_t for each thread). At the moment
> I don't generate a NT_THRMISC note in 'gcore' because 'struct thrmisc' is
> currently only present in FreeBSD's headers.
I think just having a comment mentioning that this note contains
the "struct thrmisc" structure, which contains the thread name, would
be helpful.
But, if this is about the thread name, is there a reason you're hacking it
through fbsd_core_pid_to_str, rather than hooking this up
through "thread name" ?
>
> A somewhat related question: would it be reasonable to dump additional
> notes in 'gcore' only when native?
That's OK, as long as you go through the target vector, through some target
method or by reading some target object.
If there was a FreeBSD gdbserver port I'd push you into defining whatever
packets are missing to make it work in gdbserver too, though...
> For example, FreeBSD kernels dump
> several additional notes including things like auxv, open files, etc.
See the TARGET_OBJECT_AUXV dumping in linux-tdep.c. When native, that goes
to linux-nat.c. When cross/remote, it goes through remote.c/qXfer:auxv:read.
> The "gross" way I can think of for doing that is to simply place that
> additional logic under #ifdef __FreeBSD__ in fbsd-tdep.c, but that seems
> quite hackish given the otherwise clean split between tdep.c and nat.c.
Yeah, I'd rather not. Best go through the target vector instead.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2016-01-18 12:27 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 21:46 [PATCH v2 0/6] Support kernel-backed user threads on FreeBSD John Baldwin
2016-01-13 21:46 ` [PATCH v2 2/6] Add a psuedosection for the NT_FREEBSD_THRMISC note John Baldwin
2016-01-14 5:30 ` Alan Modra
2016-01-13 21:46 ` [PATCH v2 1/6] Add support to readelf for reading FreeBSD ELF core notes John Baldwin
2016-01-14 5:30 ` Alan Modra
2016-01-14 5:40 ` John Baldwin
2016-01-13 21:46 ` [PATCH v2 3/6] Display per-thread information for threads in FreeBSD cores John Baldwin
2016-01-14 15:03 ` Pedro Alves
2016-01-15 20:23 ` John Baldwin
2016-01-18 12:27 ` Pedro Alves [this message]
2016-01-18 17:06 ` John Baldwin
2016-01-18 17:13 ` Pedro Alves
2016-01-13 21:46 ` [PATCH v2 6/6] Dump register notes for each thread when generating a FreeBSD core John Baldwin
2016-01-14 15:34 ` Pedro Alves
2016-01-13 21:52 ` [PATCH v2 5/6] Add support for LWP-based threads on FreeBSD John Baldwin
2016-01-14 15:29 ` Pedro Alves
2016-01-15 23:54 ` John Baldwin
2016-01-16 14:47 ` Pedro Alves
2016-01-13 21:52 ` [PATCH v2 4/6] Use LWP IDs with ptrace register requests " John Baldwin
2016-01-14 15:07 ` Pedro Alves
2016-01-15 20:23 ` John Baldwin
2016-01-15 21:41 ` Pedro Alves
2016-01-15 23:54 ` John Baldwin
2016-01-16 14:39 ` Pedro Alves
2016-01-16 19:17 ` John Baldwin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=569CDA29.3050000@redhat.com \
--to=palves@redhat.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=jhb@freebsd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).