[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-commits
Subject:    [PATCH] D122822: [Clang][CodeGen]Add constant array support for __builtin_dump_sturct
From:       Aaron Ballman via Phabricator via cfe-commits <cfe-commits () lists ! llvm ! org>
Date:       2022-03-31 19:50:30
Message-ID: vrtNVccISyOTXqzYJUwB6A () geopod-ismtpd-5-1
[Download RAW message or body]

aaron.ballman added a comment.

In D122822#3420162 <https://reviews.llvm.org/D122822#3420162>, @rsmith wrote:

> I'm also concerned that this builtin is making a lot of design decisions on behalf \
> of the programmer, meaning that either it does exactly what you want or it's not \
> suitable for your use and there's not much you can do about it.

FWIW, I'm not concerned by this. My understanding of this builtin is that it exists \
solely as a developer debugging aid (https://reviews.llvm.org/D44093) predominately \
for kernel folks when a debugger may not be available. As such, I view this the same \
as our other `dump()` methods -- we try to dump useful information, but ultimately, \
nobody should be relying on this output or building anything around it.

> A different design that let the programmer choose whether to recurse into structs \
> and arrays and similarly let the programmer choose how to format the fields would \
> seem preferable, but I'm not confident there's a good way to expose that in C \
> (though in C++ there seem to be good designs to choose from). As an example of how \
> that manifests here, the choice to print each element as a separate line for a \
> struct member of type `const char str[256];` is probably going to make the output \
> very unreadable, but choosing to print every array of `char` using `"%s"` will be \
> equally bad for arrays that don't contain text -- the "right" answer for a dumping \
> facility probably involves checking whether the array contains only printable \
> characters and trimming a trailing sequence of zeroes, but that seems like vastly \
> more complexity than we'd want in code generated by a builtin.

While this is interesting, I am not certain there's a lot of value to it as a \
debugging aid for times when a debugger is not available to you. It sounds like a \
fair amount of complexity, so I'd like to know whether there's a strong need for this \
much generality.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122822/new/

https://reviews.llvm.org/D122822

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[prev in list] [next in list] [prev in thread] [next in thread]