public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] bfd: Handle bmmap failure in _bfd_mmap_read_temporary
@ 2024-04-03 22:37 H.J. Lu
  2024-04-04  7:15 ` Alan Modra
  0 siblings, 1 reply; 3+ messages in thread
From: H.J. Lu @ 2024-04-03 22:37 UTC (permalink / raw)
  To: binutils; +Cc: gdb-patches

bmmap may return MAP_FAILED.  _bfd_mmap_readonly_temporary returns
MAP_FAILED when called from GDB on an object with opncls_iovec.  Update
_bfd_mmap_read_temporary to handle bmmap failure.

	* libbfd.c (_bfd_mmap_read_temporary): Handle bmmap failure.
---
 bfd/libbfd.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/bfd/libbfd.c b/bfd/libbfd.c
index 869f0ed5c66..34197b75b5e 100644
--- a/bfd/libbfd.c
+++ b/bfd/libbfd.c
@@ -1207,7 +1207,11 @@ _bfd_mmap_read_temporary (void **data_p, size_t *size_p,
     {
       data = _bfd_mmap_readonly_temporary (abfd, size, mmap_base,
 					   size_p);
-      if (data == NULL || data == MAP_FAILED)
+      /* MAP_FAILED is returned when called from GDB on an object with
+	 opncls_iovec.  Use bfd_read in this case.  */
+      if (data == MAP_FAILED)
+	goto mmap_failed;
+      if (data == NULL)
 	abort ();
       *data_p = data;
       return true;
@@ -1216,6 +1220,7 @@ _bfd_mmap_read_temporary (void **data_p, size_t *size_p,
 
   if (data == NULL)
     {
+mmap_failed:
       data = bfd_malloc (size);
       if (data == NULL)
 	return false;
-- 
2.44.0


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] bfd: Handle bmmap failure in _bfd_mmap_read_temporary
  2024-04-03 22:37 [PATCH] bfd: Handle bmmap failure in _bfd_mmap_read_temporary H.J. Lu
@ 2024-04-04  7:15 ` Alan Modra
  2024-04-04 13:53   ` H.J. Lu
  0 siblings, 1 reply; 3+ messages in thread
From: Alan Modra @ 2024-04-04  7:15 UTC (permalink / raw)
  To: H.J. Lu; +Cc: binutils, gdb-patches

On Wed, Apr 03, 2024 at 03:37:44PM -0700, H.J. Lu wrote:
> bmmap may return MAP_FAILED.  _bfd_mmap_readonly_temporary returns
> MAP_FAILED when called from GDB on an object with opncls_iovec.  Update
> _bfd_mmap_read_temporary to handle bmmap failure.
> 
> 	* libbfd.c (_bfd_mmap_read_temporary): Handle bmmap failure.
> ---
>  bfd/libbfd.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/bfd/libbfd.c b/bfd/libbfd.c
> index 869f0ed5c66..34197b75b5e 100644
> --- a/bfd/libbfd.c
> +++ b/bfd/libbfd.c
> @@ -1207,7 +1207,11 @@ _bfd_mmap_read_temporary (void **data_p, size_t *size_p,
>      {
>        data = _bfd_mmap_readonly_temporary (abfd, size, mmap_base,
>  					   size_p);
> -      if (data == NULL || data == MAP_FAILED)
> +      /* MAP_FAILED is returned when called from GDB on an object with
> +	 opncls_iovec.  Use bfd_read in this case.  */
> +      if (data == MAP_FAILED)
> +	goto mmap_failed;
> +      if (data == NULL)
>  	abort ();
>        *data_p = data;
>        return true;
> @@ -1216,6 +1220,7 @@ _bfd_mmap_read_temporary (void **data_p, size_t *size_p,
>  
>    if (data == NULL)
>      {
> +mmap_failed:

Will this give an unused label warning when !USE_MMAP?  I'm sure you
can rewrite the patch without needing a label if you use another temp
rather than "data" inside the use_mmap block.  That would be a good
idea anyway as it saves anyone wondering whether the !final_link case
can have "data" non-NULL and thus malloc is not needed.

>        data = bfd_malloc (size);
>        if (data == NULL)
>  	return false;
> -- 
> 2.44.0

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] bfd: Handle bmmap failure in _bfd_mmap_read_temporary
  2024-04-04  7:15 ` Alan Modra
@ 2024-04-04 13:53   ` H.J. Lu
  0 siblings, 0 replies; 3+ messages in thread
From: H.J. Lu @ 2024-04-04 13:53 UTC (permalink / raw)
  To: Alan Modra; +Cc: binutils, gdb-patches

On Thu, Apr 4, 2024 at 12:15 AM Alan Modra <amodra@gmail.com> wrote:
>
> On Wed, Apr 03, 2024 at 03:37:44PM -0700, H.J. Lu wrote:
> > bmmap may return MAP_FAILED.  _bfd_mmap_readonly_temporary returns
> > MAP_FAILED when called from GDB on an object with opncls_iovec.  Update
> > _bfd_mmap_read_temporary to handle bmmap failure.
> >
> >       * libbfd.c (_bfd_mmap_read_temporary): Handle bmmap failure.
> > ---
> >  bfd/libbfd.c | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/bfd/libbfd.c b/bfd/libbfd.c
> > index 869f0ed5c66..34197b75b5e 100644
> > --- a/bfd/libbfd.c
> > +++ b/bfd/libbfd.c
> > @@ -1207,7 +1207,11 @@ _bfd_mmap_read_temporary (void **data_p, size_t *size_p,
> >      {
> >        data = _bfd_mmap_readonly_temporary (abfd, size, mmap_base,
> >                                          size_p);
> > -      if (data == NULL || data == MAP_FAILED)
> > +      /* MAP_FAILED is returned when called from GDB on an object with
> > +      opncls_iovec.  Use bfd_read in this case.  */
> > +      if (data == MAP_FAILED)
> > +     goto mmap_failed;
> > +      if (data == NULL)
> >       abort ();
> >        *data_p = data;
> >        return true;
> > @@ -1216,6 +1220,7 @@ _bfd_mmap_read_temporary (void **data_p, size_t *size_p,
> >
> >    if (data == NULL)
> >      {
> > +mmap_failed:
>
> Will this give an unused label warning when !USE_MMAP?  I'm sure you
> can rewrite the patch without needing a label if you use another temp
> rather than "data" inside the use_mmap block.  That would be a good
> idea anyway as it saves anyone wondering whether the !final_link case
> can have "data" non-NULL and thus malloc is not needed.
>

The v2 patch:

https://sourceware.org/pipermail/binutils/2024-April/133374.html

-- 
H.J.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-04-04 13:53 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-03 22:37 [PATCH] bfd: Handle bmmap failure in _bfd_mmap_read_temporary H.J. Lu
2024-04-04  7:15 ` Alan Modra
2024-04-04 13:53   ` H.J. Lu

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).