Re: [PING][PATCH v4] Add pretty printers for the NPTL lock types

[Martin Galvan <martin dot galvan at tallertechnologies dot com>]

On Mon, Apr 11, 2016 at 12:26 AM, Siddhesh Poyarekar
<sid@reserved-bit.com> wrote:
> On Sun, Apr 10, 2016 at 05:51:44PM -0300, Martin Galvan wrote:
>> Yes, I know that. I've tried to split lines wherever I could, as long
>> as it doesn't hurt readability too much. However, doing so on the test
>> programs confuses gdb to the point where I need to issue a (somewhat
>> random) number of 'next' commands to advance. Those should stay as
>> they are.
>
> Please add a comment on top of the tests mentioning that.

Will do.

>> I don't understand. Why isn't it safe?
>
> If your target terminates prematurely due to an error, it may not
> resume because the target now already exists.

Oh, I see. Didn't think of that. Will fix it, thanks!

>> I remember trying to do that and it failing to work. I think it's
>> because Makerules runs for each submodule, and the
>> build/pretty-printers directory doesn't yet exist when Makerules is
>> running for nptl. I can give it another shot, but I don't think it'll
>> work.
>
> How about making the file inside pretty-printers and not inside nptl?
> Or else you could just make the directory if it doesn't exist yet.

If the file was created from pretty-printers, I'd have to add
something to the pretty-printers Makefile to (again) traverse all the
submodule dirs, which is ugly. I guess I could add an 'mkdir -p
$(common-objpfx)/pretty-printers' to the $(py-const) recipe, which is
a bit better though it'd try to create the dir each time Makerules
runs for a submodule with gen-py-const-headers. I can only pray that
whatever part of the build system that's creating the submodule dirs
is using '-p' as well, or else it'll fail when it arrives to
pretty-printers..

I'll try these things and let you know what happens.Thanks for the feedback!