public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Cupertino Miranda <cupertino.miranda@oracle.com>
To: David Faust <david.faust@oracle.com>
Cc: gcc-patches@gcc.gnu.org, jose.marchesi@oracle.com,
	elena.zannoni@oracle.com
Subject: Re: [PATCH 2/3] bpf: remove huge memory waste with string allocation.
Date: Thu, 11 Apr 2024 18:23:42 +0100	[thread overview]
Message-ID: <87h6g7zuch.fsf@oracle.com> (raw)
In-Reply-To: <7365c55a-9704-46e8-8413-42e88a865a73@oracle.com>


Hi David,

Thanks for the review.
Will apply the changes.
Nice catch and optimization with the vlen size.

Cupertino

David Faust writes:

> Hi Cupertino,
>
> On 4/11/24 04:11, Cupertino Miranda wrote:
>> Code was allocating way too much space for the string.
>
> A little bit more description would not hurt. Perhaps you could say
> something like:
> "The BPF backend was allocating an unnecessarily large string when
>  constructing CO-RE relocations for enum types."
>
>>
>> gcc/ChangeLog:
>> 	* config/bpf/core-builtins.cc (process_enum_value): Corrected
>> 	string allocation.
>
> nit: present tense, i.e. "Correct" rather than "Corrected"
>
>> ---
>>  gcc/config/bpf/core-builtins.cc | 7 ++++---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/gcc/config/bpf/core-builtins.cc b/gcc/config/bpf/core-builtins.cc
>> index e03e986e2c1..ead1777d465 100644
>> --- a/gcc/config/bpf/core-builtins.cc
>> +++ b/gcc/config/bpf/core-builtins.cc
>> @@ -872,10 +872,11 @@ process_enum_value (struct cr_builtins *data)
>>  	{
>>  	  if (TREE_VALUE (l) == expr)
>>  	    {
>> -	      char *tmp = (char *) ggc_alloc_atomic ((index / 10) + 1);
>> +	      /* Array size is 21 = ceil(log_10(2^64)) + 1 to hold string
>> +		 representations of 64 bit integers.  */
>> +	      char tmp[21];
>>  	      sprintf (tmp, "%d", index);
>
> It looks like `index' is an `unsigned int', so this sprintf should use
> %u rather %d, no?
>
> Also, it occurs to me that the `vlen' of BTF types is only 16 bits, so
> BTF has no way currently to represent enums with more than 65535
> enumerators. It may be worth adding a sanity check to bail out (error)
> here if we're going to claim an index higher than that. And if that is
> validated before the printf, the buffer can be 6 bytes ("65535\0").
>
>> -	      ret.str = (const char *) tmp;
>> -
>> +	      ret.str = CONST_CAST (char *, ggc_strdup(tmp));
>>  	      break;
>>  	    }
>>  	  index++;

  reply	other threads:[~2024-04-11 17:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-11 11:11 [PATCH 1/3] bpf: support more instructions to match CO-RE relocations Cupertino Miranda
2024-04-11 11:11 ` [PATCH 2/3] bpf: remove huge memory waste with string allocation Cupertino Miranda
2024-04-11 16:34   ` David Faust
2024-04-11 17:23     ` Cupertino Miranda [this message]
2024-04-11 11:11 ` [PATCH 3/3] bpf: add line_info support to BTF.ext section Cupertino Miranda
2024-04-17 15:14   ` Jose E. Marchesi
2024-04-17 15:47     ` Cupertino Miranda
2024-04-17 17:48       ` Jose E. Marchesi
2024-04-17 17:55         ` Jose E. Marchesi
2024-04-17 15:07 ` [PATCH 1/3] bpf: support more instructions to match CO-RE relocations Jose E. Marchesi
2024-04-19 10:17   ` Cupertino Miranda

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=87h6g7zuch.fsf@oracle.com \
    --to=cupertino.miranda@oracle.com \
    --cc=david.faust@oracle.com \
    --cc=elena.zannoni@oracle.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jose.marchesi@oracle.com \
    /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).