Re: Objcopy seems to consider tbss part of PTLOAD

[Nick Clifton]

Hi Vijay,


but Im unsure about PT_TLS segment  consisting only of .tbss section like in 
above case.


Why ?  It seems reasonable to me.


when objcopy does consider such a segment to be part of LOAD, when assigning 
offsets things seem to be going wrong

First issue we encounter.
objcopy: stq0GBq2: section `.data' can't be allocated in segment 0
LOAD: .tbss .data .bss .sdata
objcopy: stq0GBq2: section `.bss' can't be allocated in segment 0
LOAD: .tbss .data .bss .sdata

second issue the image sizes are overblown
du -sh a.out
34G a.out

>

all of this because lld seems to not emit LMA with a proper offset ie its LMA 
is just VMA not LMA+Offset.


Right.  I think that this means that the problem lies with lld.
(When I try the same sequence of commands using the ld.bfd
everything works...)


Is it expected that objcopy considers PT_TLS segment consisting only of tbss to be part of LOAD, since tbss is a special section I assumed it should have been dealt with 
differently ie not part of LOAD. if so could you explain reasoning behind this.


AH - I think that I understand your question now.  The reason
is that the ELF_SECTION_IN_SEGMENT_1 macro is meant to check
if a section-to-segment assignment is potentially valid, but
not to enforce a specific assignment policy.  Thus it is possible
for a section of type SHF_TLS to be placed into a PT_LOAD
segment - there are other ways for the loader to determine that
the segment contains some thread local data - it is just not
very intuitive.  At least that is how I see it.

I think that you have come across a case where the BFD library's
section placement heuristics do not work correctly.  Although the
circumstances are rather strange.  Please feel free to file a bug
report about the problem, including your reproducer, and we can
investigate further.

Cheers
  Nick

Re: Objcopy seems to consider tbss part of PTLOAD

[Nick Clifton]

Hi Vijay,

  In the future, it helps if report bugs, or potential bugs,
  via the binutils bugzilla system.  This allows us to track
  bugs individually and also add comments in the code that
  refer back to the bug report.  https://sourceware.org/bugzilla/



clang reprod.c -ffreestanding -c -o reprod.img


Which architecture is this for ?  Which versions of clang and
the binutils are you using ?


ld.lld --defsym VMA_START=0x8010 --defsym LMA_START=0x480 -T 
l.ld reprod.img -o reprod.img
objcopy --change-section-lma .*-0x8000 reprod.img
objcopy --adjust-start -0x8000 reprod.img
lld dosen't seem to consider tbss section to have proper lma
of lld
   TLS    0x2058 0x80100060 (vma) 
0x80100060 (lma)
  0x 0x0004  R  0x4
    03 .tbss
Ld Linker
   TLS    0x00100098 0x801000a0 (vma) 
0xc81000a0 (lma)
  0x 0x0004  R  0x4


I am sorry, but I did not understand what is wrong with the LMA.
Please could you explain some more.

Also, you say that objcopy does not consider the .tbss section
to be part of a PT_LOAD segment.  This is correct.  It is part
of a PT_TLS segment.  PT_TLS segments are considered to be
inherently loadable, so it is OK to use PT_TLS for thread local
data rather than PT_LOAD.

Cheers
  Nick

Re: MIPS32 - binutils-2.41

[Nick Clifton]

Hi Pete,


I believe it's the target normalisation in
config.sub (line 1055) that does it:

 mips3*-*)
 cpu=mips64
 ;;


Interesting...


That doesn't seem quite right to me but I don't know much about
binutils to know what the rationale is for that transformation.


I have no idea why that is there, but it does look strange, I agree.

In this particular case however the binutils are not to blame as the
config.sub file (and the config.guess file) are actually taken from a
different project:

  https://savannah.gnu.org/projects/config/

We just use copies of the files from that project.  We synchronize the
files occasionally, usually just before an official release.



TL;DR - I've got something that (I think...) works now by using 'mips-
mti-elf',


Good, I shall now stop panicking. :-)


but I'm unsure whether my initial post about the 'mips32-*'
targets being silently coalesced into 'mips64-*' by the configure
scripts is a bug or not, nor what the fix would be.  I'm happy to raise
a bug report if you think that config.sub clause is a typo.


If you feel motivated, please do take this issue up with the config
project.  If it caused problems for you then it is likely to cause
problems for other people in the future.  So fixing it, or at least
adding a comment explaining the reasoning to the config.sub file,
would be a good thing.

Cheers
  Nick

Re: MIPS32 - binutils-2.41

[Nick Clifton]

Hi Pete,


I've been attempting to build a cross-compiler for a MIPS32
microcontroller (specifically an M14KE) and I've been running into
problems that appear to stem from binutils silently coalescing 'mips32'
into 'mips64'.


What specifically are these problems ?

All configurations of the binutils for mips targets suppport at least one
64-bit variant.  Most also support a 32-bit variant.  But you may need to
explicitly specifiy which variant you want when you are assembling something.
It depends upon the exact configuration used and vpu that you wish to target.



./configure --target=mips32-none-eabi


I do not believe that there is an eabi variant of the mips configuration
so it is possible that this might be related to the problems that you are
having.



I've had a look in bfd/config.bfd and tried several variations of
target, such as mips-none-eabi, mips-none-elf, mips32-none-elf, mips32-
elf, etc. and they all seem to do the same thing.


Well there definitely are mips-elf and mips32-elf configurations so those
should work.

Cheers
  Nick

Re: Running strip on libpython3.so twice creates statically linked files

[Nick Clifton]

Hi Junsong,

  Please could you refile this problem using the binutils bug reporting
  system here:

https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

  It really helps to have a bug report where we can track problems and
  their solutions.


Hello, I find out strip (version 2.7 and 


  I assume that you mean version 2.37 ?


$ ldd python/install/lib/libpython3.so
         statically linked


  Strangely for me when I tried this sequence of instructions using
  a version of strip built from the latest sources I get a slightly
  different behaviour:

$ ldd python/install/lib/libpython2.so
$

  (ie no output at all).  Plus file still thinks that the binary
  is a dynamically linked entity:

$ file python/install/lib/libpython3.so
libpython3.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 
dynamically linked, stripped

  But obviously there is a problem here that needs to be resolved.

Cheers
  Nick

Re: Bug in linker script file matching after b1eecf6f66a4a642 (prefix tree)

[Nick Clifton]

Hi Andrew,


Apologies for the generic subject, I don't totally understand the
nature of the bug.


No worries.  You have the problem narrowed down to a single commit,
which definitely helps.


I have a basic linker script that stopped working after upgrading to
binutils 2.40.  I did a git bisect on the repository and it seems that
the breakage starts with commit
b1eecf6f66a4a642f4cb35688213e6c1c1ffdc79.


Please could you file a bug report for this problem here:

  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

Having a bug report like this really helps us to track the bug
and ensure that it can be reviewed in the future, should it ever
come back.



$ ${LD} -o out.bin -T linker.ld lib1.a lib2.a


You have now shown how lib1.a and lib2.a are created.  I assumed
that you did:

  $ ar cr lib1.a test1.o test2.o
  $ ar cr lib2.a test3.o



$ objdump -x out.bin | grep func
c01e g F .text  000a func3
c00f g F .text  000f func1
c000 g F .text  000f func2

you see that func1 and func2 are in .text rather than .init-text where
they should be.


Yes, this is a bug.  Not sure of the exact cause, but maybe the
new code in commit b1eecf6f66a4a642 in scanning the sections in
reverse order rather than forward order.

Cheers
  Nick

Re: Please make docs and makeinfo conditional on the --enable-docs variables, instead of being unconditional

[Nick Clifton]

Hi Yuri,


I need to install the latest binutils on an outdated CentOS system where no 
package manager is available, and the installed gcc is 4.5.2 from 10+ years ago.


If this problem is related to CentOS, then you really should file
a bug report with their system, rather than here.

In case it helps, the CentOS binutils sources include an option
to build the rpms without documentation, which should solve your
problem.



Binutils unconditionally requires 'makeinfo' which comes from print/texinfo.


No it doesn't.  The binutils sources only need the makeinfo program if the
documentation sources are newer than the compiled documentation files.  I
suspect however that you are encountering a know problem with the distribution
of the sources via tarballs: when you unpack the tarballs the documentation
source files end up having the same file creation date as their compiled
versions.  This leads the build system to think that the documentation needs
to be recompiled, and hence makeinfo is needed.

One workaround for this problem is to touch the compiled documentation files
after they have been extracted from the tarball.  For example:

  $ tar xvf binutils.tar.xz
  $ find . -name *.info -exec touch {} \;

Cheers
  Nick

Re: ORIGIN Grammar Typo in Some Documentation

[Nick Clifton]

Hi Matt,


Hello, just reporting that lines 492-494 of ld/ld.texi contain examples of 
MEMORY ORIGIN of the form:

 ORIGIN : offset

Where the grammar is:

origin_spec:
 ORIGIN '=' mustbe_exp


Oops!



Seems like hoops to raise a pull request, someone else can take the glory.


Glory stolen and documentation updated.  Thanks for reporting this snafu.

Cheers
  Nick

Re: bfd.h fails to compile on FreeBSD: error: unknown type name 'ENUM_BITFIELD'

[Nick Clifton]

Hi Yuri,


Where is ENUM_BITFIELD expected to come from?


/usr/include/anisdecl.h

Cheers
  Nick

Re: Binutils release 2.40 require texinfo due to missing gas .info files

[Nick Clifton]

Hi Benson,


This helps. However, the build script removes config.texi and then
copies all.texi into config.texi changing timestamps and forcing a
rebuild that requires makeinfo. This seems to have been encountered
elsewhere, for example https://github.com/spack/spack/pull/34173

The reason for doing this during the build is unclear to me. The
simplest fix is making a copy that preserves timestamps, but other
solutions such as not removing and replacing, or building just using
config.texi seem fine.


You are correct.  I have gone ahead and applied the patch that you
submitted for PR 28909.  (Sorry for the delay in reviewing it!)

Cheers
  Nick

Re: Binutils release 2.40 require texinfo due to missing gas .info files

[Nick Clifton]

Hi Benson,


The current binutils release 2.40 requires texinfo to build from source
because gas does not have .info files. 


I believe that it does:

  % tar tvf binutils-2.40.tar.xz | grep as.info
  -rw-rw-rw- root/root   1220923 2023-01-14 00:00 binutils-2.40/gas/doc/as.info



Typically texinfo is only needed
if the .texi files are modified as releases should contain .info files.


But when you extract files from a tarball they all end up having the same
creation date, so the make system will believe that it needs to generate
the info files.  If you touch the files first then the problem is avoided:

  % tar xvf binutils-2.40.tar.xz
  % find binutils-2.40 -name "*.info" -exec touch {} \;


Cheers
  Nick

Re: Overloading ld linker script is not working after 2_36

[Nick Clifton]

Hi Phil,


I can't get NOLOAD working any more.
This used to work before binutils_2_36.


The behaviour of the 2.36 binutils may have been accidental rather than 
intended...

The key thing here is that input source files that are actually linker
script fragments are interpreted as augmenting the *end* of the default
linker script, rather than the start.  So even though your fragment file
contains:


   .infoA  (NOLOAD)   : {} > INFOA


The default script contains:


   .infoA : {} > INFOA   /* MSP430 INFO FLASH MEMORY SEGMENTS */


And this is interpreted first.  Hence the sections do not gain the NOLOAD
attribute.

The best way to solve this issue is to just override the default linker
script with your own version using the -T command line option.

If that is not feasible then the only other solution that I can think of
is to rename the .infoA sections (using objcopy's --rename-section command
line option) to something else, eg .renamed.infoA, as a pre-link step
and then use your script fragment to assign the renamed sections, eg:

  .renamed.infoA (NOLOAD) : { *(.renamed.infoA) } > INFOA

Cheers
  Nick

Re: linking an assembler object creates an executable stack

[Nick Clifton]

Hi Alexander,


During development of a project I noticed that linking a object created
from assembler to another object created from C code results in a
binary with executable stack.


Blowing my own trumpet slightly, I wrote a blog about this kind of problem
which might be of help:

https://www.redhat.com/en/blog/linkers-warnings-about-executable-stacks-and-segments

Cheers
  Nick

Re: Binutils/ld: linker script does not work for AVR mega 0 series (avrxmega3)

[Nick Clifton]

Hi Konrad,


+  data   (rw!x) : ORIGIN = 0x802000, LENGTH = 0x1

The fixed origin seems very dubious to me and I wasn't able to debug 
__DATA_REGION_LENGTH__.


It is defined earlier on in script:


[cut]

I actually meant to ask: is there a way to debug the linker script? I.e. to 
output what real values are used and where they come from?


Absolutely.  Just run the linker with the --verbose command line option.
That will output the linker's internal script with values filled in.

Make sure to include any other command line options you would normally
use as the internal script varies based upon the presence of certain options.


Cheers
  Nick

Re: Binutils/ld: linker script does not work for AVR mega 0 series (avrxmega3)

[Nick Clifton]

Hi Konrad,


the linker fails on trying to arrange data/bss segments even with very few 
small variables. E.g.:


Please could you file a bug report for this problem here:

  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils



avr-g++ -Os -Wl,--gc-sections -B 
~/tronic/atmel-compiler-packs/mega/gcc/dev/atmega3208 -mmcu=atmega3208 -o 
fw.elf dimmer.o dmx.o input.o ledout.o pwm.o
<...>/lib/gcc/avr/12.2.0/../../../../avr/bin/ld: address 0x803004 of fw.elf 
section `.bss' is not within region `data'


If you can include these object files as an aid for reproducing the problem, 
that would be appreciated.


I narrowed the problem down to the Linker script avrxmega3.xn - it somehow messes up the data segment in the MEMORY section at the top. I was able to get it to link by 
changing that line:


-  data   (rw!x) : ORIGIN = 0x802000, LENGTH = __DATA_REGION_LENGTH__
+  data   (rw!x) : ORIGIN = 0x802000, LENGTH = 0x1

The fixed origin seems very dubious to me and I wasn't able to debug 
__DATA_REGION_LENGTH__.


It is defined earlier on in script:

  __DATA_REGION_LENGTH__ = DEFINED(__DATA_REGION_LENGTH__) ? 
__DATA_REGION_LENGTH__ : 0xffa0;

In terms of source code, it is defined in ld/scripttempl/avr.sc as:

  __DATA_REGION_LENGTH__ = DEFINED(__DATA_REGION_LENGTH__) ? 
__DATA_REGION_LENGTH__ : $DATA_LENGTH;

and DATA_LENGTH is defined in the ld/emulparams/avr*.sh files.



I consider my fix "an ugly hack". The linker script in Arduino looks more 
elegant and also works:


__DATA_REGION_ORIGIN__ = DEFINED(__DATA_REGION_ORIGIN__) ? 
__DATA_REGION_ORIGIN__ : 0x802000;
//...
data   (rw!x) : ORIGIN = __DATA_REGION_ORIGIN__, LENGTH = __DATA_REGION_LENGTH__


Actually this reasonable, and would provide some more utility to users.

Currently the avr.sc file (mentioned above) has this code:

   data   (rw!x) : ORIGIN = $DATA_ORIGIN, LENGTH = __DATA_REGION_LENGTH__

and the definition of DATA_ORIGIN can be found in ld/emulparams/avrxmega3.sh:

  DATA_ORIGIN=0x802000

I am not intimately familiar with the AVR architecture variants, so I do not
know if this is a reasonable value...

Cheers
  Nick

Re: A heap buffer overflow bug in binutils-2.39

[Nick Clifton]

Hi bjchan9an,


There is a heap buffer overflow bug in binutils-2.39 (commit 49c843e6).


Please could you file a binutils bug report about this issue here:

  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

Thanks.

Cheers
  Nick

Re: Report a bug of binutils-2.38

[Nick Clifton]

Hi bjchan9an,


There is an uncontrolled stack recursion vulnerability in binutils-2.38, which 
allows stack consumption in demangle_path_maybe_open_generics().


As Alan said, we are really only interested in bugs triggered by fuzzed binaries
if they are reported against the current mainline code.  Given the trouble that
I know that you have had in reporting this problem however I thought that I
would add a few more details:

  1. As it happens the string demangling code is part of the libiberty library
 which actually maintained by the GCC project not us.  (The binutils project
 makes use of the code, but it does not maintain the code).  Hence bug 
reports
 about demangling should be sent to the gcc mailing list.

  2. This problem - with the Rust demangler - has already been reported and 
fixed.
 If you try the current mainline GNU binutils sources you should find that 
the
 stack exhaustion does not occur.

Cheers
  Nick

Re: Report a bug of binutils

[Nick Clifton]

Hi bjchan9an,

Hello, we want to report a bug of bintuils. 


Thank you for taking the timer to do this.

However, we failed to create a new account of https://sourceware.org/bugzilla. The error information is: "Because of spam user 
account creation has been restricted.". What should we do?


I would suggest contacting overse...@sourceware.org.  They should be able to 
help you.

You can also report the bug on this mailing list.  It is not as helpful as 
creating
a bug report using the bugzilla system, but at least we would be able to 
investigate
and maybe give you some feedback.

Cheers
  Nick

Re: c function call issue from assembly program

[Nick Clifton]

Hi Arpan,


I found this interesting issue in binutils v2.38.
The following code works perfectly fine in ubuntu 20.04 (binutils v2.34)


I could not reproduce this failure.  That is when I compiled, assembled
and linked your test program using binutils 2.38 tools, the resulting
executable ran correctly.

I was however using Fedora rather than Ubuntu, so possibly the problem
is related to any Ubuntu specific changes that have been made to the
binutils sources.

Also when switching from Ubunti 20.04 to 22.04 it is likely that the
version of gcc has changed as well.  So possibly the problem is with
gcc rather than the binutils.

I suggest that you report the problem using the Ubuntu bug tracking
system.  They should be able to give you a more detailed answer.

Cheers
  Nick

Re: A request to add information on gprofng

[Nick Clifton]

Hi Kurt,


     I did inquire with the overseers about what was possible approximately two 
months ago and they suggested it would be best under binutils.


Makes sense to me.


     A few things we are thinking would help gprofng:
     - a gprofng FAQ where questions could be answered and recorded for 
users or developers
     - pointers to useful gprofng presentations that were recorded by 
conferences
     - helpful info to support developers interested in porting gprofng to 
new platforms

     These would likely be asynchronously and incrementally changing as there 
are new questions asked or new presentations

     Do other binutils projects provide this sort of info somewhere?


No - you would be the first. :-)

Well unless you count the online documentation which is really just
an HTML formatted copy of the .texi files found in the sources.



     If this might be too much we could ask for a savannah.org project page, 
put this sort of info there,
     and link to it from sourceware.org?


You can do either.  But I am totally OK with you having a sub-directorty
below the sourceware binutils main web directory.

Cheers
  Nick

Re: A request to add information on gprofng

[Nick Clifton]

Hi Ruud, Hi Kurt,


  gprofng - Collects and displays application performance data.


I have replaced the previous description of gprofng with this line.



Related to this, we were wondering if we can get a gprofng page on

https://sourceware.org/projects.html


Probably - but you will have to ask the overse...@sourceware.org for that.

Unless you want it to be a sub-page of the binutils page that is.  If you
do want to take this route then all you really need is write access to the
sourceware site and you can make your own changes.  (Ideally coordinating
with me... :-)


> also we might want to change the one liner on 
https://sourceware.org/binutils/ to match the new one above.

Actually it works the other way around.  I only have access to the sourceware
site, so I make the changes there and then ask the FSF webmasters to copy
over the changes to the www.gnu.org site.

(Just to confirm, this is what I have done with the updated description of
gprofng - ie updated the sourceware site and asked the FSF to copy the
changes).

Cheers
  Nick

Re: A request to add information on gprofng

[Nick Clifton]

Hi Ruud,


By the way, will you be at Cauldron? I plan to attend and would
love to meet in person!


Oh yes - I will be there. :-)

Cheers
  Nick

Re: A request to add information on gprofng

[Nick Clifton]

Hi Ruud,


Since we are now part of the GNU binutils 2.39 release, I wonder
if gprofng can be added to the list on the main binutils web site:


Doh!  Sorry - this is my bad.  I should have thought to ask you.


https://www.gnu.org/software/binutils/

If this is possible, please advise how to proceed.


Take a slice of lemon, wrap it around a gold brick and, oh no, sorry,
that is the recipe for a pan galactic gargle blaster.  Ahem.

If you can tell me what you want to say I will add it to the page.
Even better if you can provide me with some HTML formatted text I
can just insert it at the proper place.

Cheers
  Nick

Re: [binutils] ar -xo Archive reports cannot set time: Invalid argument

[Nick Clifton]

Hi canpool,


ar: 1.txt: cannot set time: Invalid argument



I provide a patch bound tv_nsec：


Thanks for providing a patch.  As it happens this bug has already been
reported and fixed:

  https://sourceware.org/bugzilla/show_bug.cgi?id=28391

Cheers
  Nick

Re: Binutils bug compiling Gnome Text Editor on Windows

[Nick Clifton]

Hi Zachary,

I'm unable to register on Bugzilla so I can't file this there. However, while trying to compile the Gnome Text Editor on Windows using msys2 I found the following error 
which caused compilation to cease. It's quite long so I pasted it here https://pastebin.mozilla.org/kbwhHzh7 


Unfortunately that gives me a "404 snippet not found error".

Some things that you might like to consider/try:

  * Are you running out of memory ?
(I am not familiar with the Gnome Text Editor, but Gnome programs
in general tend to be quite big).

  * Are you using the latest version of the binutils ?
(This is version 2.38 at the time of writing).

  * Is the error specific to the msys2 environment ?
(Maybe building under Cygwin or Linux might work).

Cheers
  Nick

Re: Bug: dlltool delaylibs corrupt float/double arguments

[Nick Clifton]

Hi Strager,


I think the solution is for dll's delaylib trampoline to
save xmm1 on the stack before calling __delayLoadHelper2.
I made a patch which does this, and it fixes the bug for my
code.


Thanks very much for taking the time to track down the cause
of this problem. and for creating a patch. :-)


See attached patch. I think my patch has two problems:

1. AVX/vmovupd/ymm might not be usable on the target
machine, but saving just xmm isn't enough. Should we
perform a CPUID check?


This would only work if the dlltool is run on the same machine,
or same type of machine, as the target machine.  Probably a
safer solution would be to add a new command line option to
select the extended trampoline.  Then it is up to the user to
select the correct trampoline type.

To be really paranoid if the new option is not enabled and
dlltool is running on an x86_64 host, then it could run a
CPUID check and if extended registers are available, issue
a warning message to the user, reminding them of the possible
problem.



2. We store unaligned with vmovupd. Storing aligned with
vmovapd would be better. I haven't looked into how to
align ymm registers when storing on the stack.


"Better" as in better performance, yes ?  I think that in this
case safer is more important than faster, so sticking with
unaligned moves should be OK.



I'd love to get this bug fixed so others don't spend two
days debugging assembly code!


Would you be willing to work on the improvements suggested
above and submitting a revised patch ?  The catch here is
that such a patch would need a copyright assignment from
you before we could accept it.  The links below should provide
more details on this.

Cheers
  Nick

https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html#Legally-Significant
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=doc/Copyright/request-assign.future;hb=HEAD

Re: size.exe

[Nick Clifton]

Hi Zane,

  Please could you file a bug report about this problem here:

https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

  When you do, please could answer the following questions as well:


Hi. I'm building binutils 2.38. When installing, it complains about being 
unable to find size.exe.


  Were there any error or warning messages when configuring
  or compiling the sources ?

  What is your target configuration ?
  Which other configuration options did you use (if any) ?
  What is your host system ?

  Is this a regression from compiling the binutils 2.37 sources ?



When I remove it from the Makefile, it just loops.


  How did you remove it from the Makefile ?

Cheers
  Nick

Re: ld-arm bug in encoding of blx calls jumping from thumb to arm instructions

[Nick Clifton]

Hi Jori,


We encountered a linking error in 11.1 and 11.2 of the ARM GNU Toolchain.


If this is a toolchain produced by ARM, then you really need to contact them,
not us.  If you can reproduce the problem using the GNU Binutils sources
directly, then please feel free to report the bug here:

 https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

Cheers
  Nick

Re: LD producing SegFault executables with FreePascal 2.6.4, in Binutils-2.36.1 and later

[Nick Clifton]

Hi John,


If you need some exe/object files, traces, etc. let me know and I will try to 
supply.


Yes please.  If you can give me an x86_64 version of the failing executable I 
can try examining it to see what is going wrong.

Is there any chance that you could provide a test case that only uses object
files and libraries ?  Ie no Pascal compiler involved, just a set of binary
files and the linker command line that combines them (and fails to create a
working executable).



The helloworld test case I gave is very easy to reproduce if you install FPC 
2.6.4.


I did try to reproduce the problem you described, but unfortunately the system I
am using (Fedora 34) only has FPC 3.2.2 available, so I did not get very far.


     Reason: Get rid of the linker warning, which was caused by the fact that 
we used the linker in an unsupported way (and which hence occasionally caused 
issues).


Hmm, slightly worrying.  If the linker is indeed being used in an unsupported
way then that is bad.  Plus if the remedy is to remove warning messgaes then
maybe an important (but unrelated to the original problem) message is being
removed.


Because FPC/Lazarus is a giant self-contained software stack, the approximate 
equivalent of binutils + gcc + libc + an entire graphical 
windows/component/object system.


OK.  I am sure that you already know that problems like this are likely
to continue appearing as time goes by, but I will do my best to help.

Re: LD producing SegFault executables with FreePascal 2.6.4, in Binutils-2.36.1 and later

[Nick Clifton]

Hi John,


It appears that LD in binutils versions after 2.35 is producing segfault 
executables with Free Pascal 2.6.4.  You cannot build a working HelloWorld.


Please could you file a bug report about this issue using the binutils
bugzilla system:

  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils


I have written up a full report, please see
https://gitlab.com/freepascal.org/fpc/source/-/issues/39324 



Has anyone been able to track down the exact cause of the segmentation
fault ?  For example is the loader rejecting the executable as being
malformed, or is the startup code branching off into a random memory
location, or something else ?



The Free Pascal developers believe this is a regression of a similar LD bug 
that previously occurred and was fixed in LD.


Do you know which bug this was ?



They put a workaround/redesign in later versions of FreePascal, the 3.x series, 
but are unable to backport their fix to FPC 2.6.4.


Not to be mean, but if the 3.x series is working, why worry about
the 2.6.4 release ?  If people want to use that release, can't they
also stick with binutils 2.35 ?

Cheers
  Nick

Re: Is this a bug?

[Nick Clifton]

Hi Zane,


Hi. I am trying to compile binutils 2.37. But when the Makefile run > gcc.exe: 
fatal error: no input files
What do I do?


There is some suspicious quoting in the command line, starting with:

  "-DBINDIR=\\C:/test/normalGcc/bin\"

(Note how the closing quote is escaped)

And ending with:

  ../../binutils-2.37/bfd/archive.c"

It looks to me like the command line defining one very long symbol
called BINDIR which contains a lot more than just a path to a bin
directory.

I have no idea why this is happening though.  Perhaps it is related
to how you ran the configure script ?

Cheers
  Nick

Re: [PATCH] readelf: dump the value contained in offset on Rel relocs when -AW are passed

[Nick Clifton]

Hi Andrea,

  Thanks for patch suggestion.  I do have a few comments:


Here is the suggested patch.  It will print the value at offset on Rel
relocs; for simplicity, it only does it on 32-bit files, because that's
what I need, but I can easily extend it; also, 64-bit ELFs tend to use
Rela relocs where this feature does not make sense.


True.  It felt a little odd only making the change for 32-bit, but less
changes to the code = less chance for new bugs...



The additional column is displayed when -A (--arch-specific) is passed,
as suggested, together with -W for wide mode (I can remove this last
requirement).


I think that that would be good.  (Ie make the change work with and without -W).

Also - I think that it would be neater if you put the extra field at the
end of the line, rather than after the Offset field.  That way the layout
isn't changed so much, and you can add the extra value-calculating-code
to the end of the loop.


+ value = 0;
+
+ if (sec)
+   {
+ file_offset = offset - sec->sh_addr + sec->sh_offset;
+
+ /* Now read value, or set to zero on failure */
+ if (!fseek (filedata->handle, file_offset, SEEK_SET))
+   if (fread (, sizeof (value), 1, filedata->handle) != 
1)
+ value = 0;


Rather than printing a value of 0 for locations that cannot be reached, it
might be better to print something like .  That way users can tell
at a glance that something is wrong...

When adding a new feature like this, you also need to document it.  Specifically
you need to add a line or two to the binutils/NEWS file, and a full decription
in the readelf section of the binutils/doc/binutils.texi file.

Finally you need to run the binutils testsuite and make sure that the change 
does
not introduce any new failures.  (It should not, since the behaviour is gated on
the -A option, which I think is not widely tested, but you never know).

Cheers
  Nick

Re: readelf: also dump the address contained in offset on R_386_RELATIVE relocs

[Nick Clifton]

Hi Andrea,


I see that, when dumping R_386_RELATIVE relocs in readelf, the format is
like this

Offset InfoTypeSym.Value  Sym. Name
   3d01  0008 R_386_RELATIVE


If I understand that type of relocation correctly, another information
is missing: the address contained at the given offset, which ld.so adds
to the load address of the module and then overwrites at the same
offset.

I think it is reasonable to provide that information.  Some users might
need it for debugging or learning purposes.


It could indeed be useful, but there is a downside: adding extra information
like this tends to break the binutils testsuites (since some tests wll not
be expecting the extra output) - and more seriously, it tends to break user
scripts that expect readelf's output to be in a certain format.

This is not to say that the feature should not be added, but rather than it
would probably be best to have it as an optional extra, controlled via a
command line option.  (Eg the --arch-specific option).

Also, this looks like it might be a suitable project for someone interested
in learning about the binutils.  So I am hoping that you, or someone else
will volunteer to have a go ... :-)

Cheers
  Nick

Re: nm/objdump --hep still display unsupported styles about --demangle.

[Nick Clifton]

Hi nora-pxh,


So  if you execute --demangle=gnu, it will display error message: unknown 
demangling style gnu.
Would you delete unsupported  styles from usage of nm and objdump?


Thanks for reporting this problem.  The issue has been fixed by commit 
0d64622696e0

Cheers
  Nick

Re: ar and objcopy stuck, failing on object name containing '/' inside an archive?

[Nick Clifton]

Hi Andrew,

  [Sorry for taking such a long time to reply to your email]



I am trying to localize some symbols in objects inside an archive.
Ultimately, it seems like the tools are failing because the .a appears to contain an 
object with the name "bin/thumbv7em-none-eabihf.o".


If you extract the object files, localize them one by one and
then put them back, does the problem go away ?

(In theory this should not make any difference at all, but you never know...)



When I try to extract everything in the archive:

arm-none-eabi-ar x librustlib.a

it extracts all objects up to that problem object with the '/' in the name, but 
none after it.

Is this a bug?


Yes. :-)  Either the extraction should complete with all of the
files being retrieved or else an error message should be displayed
and the exit status set to failure.

Please could you file a bug report for this problem here:

  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

If you could include a copy of the archive, or simple instructions
on how to create a similar one, that would help a lot.

Cheers
  Nick

Re: Problems with bfd: could it parse bin file built on arm64?

[Nick Clifton]

Hi 孟祥炜,


0 any bugs or errors in my using?


The BFD library supports a large number of different architectures,
but usually programs that use it are configured to only support a
limited subset of these architectures.  Often this is limited to
just the host architecture.  So for example if you were to use the
objdump program on an x86_64 host machine you might see output like
this:

  % objdump --help
  [...]
  objdump: supported targets: elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64 pei-i386 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big elf32-little elf32-big 
pe-x86-64 pe-bigobj-x86-64 pe-i386 srec symbolsrec verilog tekhex binary ihex plugin
objdump: supported architectures: i386 i386:x86-64 i386:x64-32 i8086 i386:intel i386:x86-64:intel i386:x64-32:intel i386:nacl i386:x86-64:nacl i386:x64-32:nacl iamcu 
iamcu:intel l1om l1om:intel k1om k1om:intel

  [...]

Note how there are lots of different target formats supported, but
they are all x86 related.  None of them are ARM related.

So in order to support arm64 you either want to use a BFD library
that has been built to run on an arm64 host (and of course run
your program on that arm64 host too), or else you need to build
your own version of the BFD library that has been configured to
support arm64 as well as any other formats that you care about.

To configure and build a BFD library with multiple different target
support you need to obtain the binutils sources and then use a
configure option to choose the targets.  For example:

  /configure --enable-64-bit-bfd 
--enable-targets=aarch64-linux-gnu,x86_64-linux-gnu

If you are not sure which targets you will need to support, you
can configure the library to handle all of them:

  /configure --enable-64-bit-bfd --enable-targets=all

I hope that this helps.

Cheers
  Nick

Re: Minus ("-") symbols in section memory region name causes syntax error

[Nick Clifton]

Hi Sebastiaan,


I've recently upgraded from binutils 2.36.1 to version 2.37.
(specifcally, it has a region called "bkup-ram" allowing one to store



While this used to work, it now throws a syntax error



Is this a regression in 2.37, or was it a bug that 2.36.1 even
accepted it in the first place?


It was a bug that it was accepted in the first place.  The dash
character should not have been allowed in memory region names (or
any kind of symbol name in linker scripts).  I am not sure exactly
which commit to the 2.37 sources fixed this oversight, but the new
linker is behaving correctly.

Cheers
  Nick

Re: GNU strip fails to set sh_link and sh_info on Solaris SPARC64

[Nick Clifton]

Hi Libor,


thank you for ideas. Obviously, the biggest problem is that we know too late 
whether the symbol section is empty and it is difficult to remove already created 
output sections (requires hacks). In that case, a safer and cleaner solution (but 
slow) is to call strip in two phases> Not sure whether I should attempt to 
implement it since this performance bottleneck could be no-go.


Safe and slow but working is better than fast and broken...

I forgot whther you said that having these sections present in a file when the 
symbol table is missing actually causes problems with their execution.  If it 
does not then the simplest solution is to do nothing and just leave them in.  
(A slightly better solution would be to add a comment to the code explaining 
why the sections are not removed).

Cheers
  Nick

Re: GNU strip fails to set sh_link and sh_info on Solaris SPARC64

[Nick Clifton]

Hi Libor,


Unfortunately the above code does not work for the following reasons:

- sections are already created in that point of code
- symbol filtering requires output sections to be created
- cannot find bfd_remove_section function that could handle it



However, this code removes the sections unconditionally regardless of whether 
.symtab is kept or not. I can image that GNU strip could be called in two 
passes: the first pass could remove .symtab and .strtab sections; the second 
pass would strip .SUNW_sym*sort sections if .symtab section was stripped in the 
first pass. A big disadvantage is that it introduces double performance 
overhead... Any ideas?


A few - but all untested...

  * Create a hook in elf64-sparc.c for the elf_backend_section_processing() 
function
and have it change the section's type to SHT_NULL, so that they are ignored.
(But still present which would be bad...)

  * Alternatively maybe the elf_backend_always_size_sections() can be used to 
detect
empty symbol tables and eliminate the special sections.

  * Or the elf_backend_begin_write_processing() function could adjust the 
section
header table to skip the offendng sections.

  * Add code to objcopy.c:is_strip_section_1 () that identifies these sections 
and
returns TRUE if their symbol section is empty.

Cheers
  Nick

Re: GNU strip fails to set sh_link and sh_info on Solaris SPARC64

[Nick Clifton]

Hi Libor,


Patch approved - please apply.

thank you for your approval. How can I obtain a write permission to binutils 
repository?


Ah right.  First of all do you have a FSF Copyright assignment for the binutils 
?
I assume, based upon your email address, that you are working for Oracle and 
that
this patch (and future ones) have been developed as part of your job.  In which
case you will be covered by Oracle's global copyright assignment and you do not
have to do anything.  But if not, then a personal copyright assignment is a 
must.

Once that is sort out, please fill out the form on this page:

  https://sourceware.org/cgi-bin/pdw/ps_form.cgi

You can use my email address as the approver.
This should only take a day to complete and then you will have write access.

Cheers
  Nick

Re: GNU strip fails to set sh_link and sh_info on Solaris SPARC64

[Nick Clifton]

Hi Libor,


I noticed that GNU strip produced invalid binaries on SPARC 64, the reason is 
that bfd/elf64-sparc.c was not updated in 
https://sourceware.org/bugzilla/show_bug.cgi?id=19938 issue.

The attached patch just follows Nick Clifton's changes for other architectures.


Patch approved - please apply.



Note that .SUNW_symtabsort, .SUNW_symtabnsort, and .SUNW_symtlssort sections 
refer to .symtab section, therefore, if .symtab is removed, theses sections 
should be skipped in copy as well. However, I am not sure how to properly 
implement it, maybe use handle_remove_section_option if the number of symbols 
is zero?


That should probably work.  If you have the time, please could you give it a 
try.

Cheers
  Nick

Re: [Bug ld/26701] New: Ability to suppress warnings due to tags in a library

[Nick Clifton]

Hi Eyal,

  Yes, the linker could suppress these warnings.  But the important point
  is that it is not at all clear that the linker should suppress them.
  The warnings are important, and the real way to get rid of them is to
  fix the code that is triggering them.

  Now I appreciate that this is not always possible.  But as pointed out
  in PR 12017 there are several ways to work around the problem without
  modifying the linker.  My stance is: why introduce new code, and 
  potentially new bugs, to the linker when there are other ways of solving
  the problem.

  So, if you do want to get a change like this in, I think that you are
  going to need to drum up some support from the community.  If enough
  people agree with you, then I will make the necessary changes.  One
  important point however is that you ought to make sure that the LLVM
  community agrees with the idea too, and that they are willing to put
  it into their linker (LLD).

Cheers
  Nick

Re: [PATCH] Fix typos

[Nick Clifton]

Hi Samanta,

  Thanks very much for telling us about these typos.  
  I have now applied your patch.

Cheers
  Nick

Re: GNU windres cannot compile BITMAP or OWNERDRAW menu items

[Nick Clifton]

Hi katahiromz,

> I'm using your resource compiler "windres".
> I found that windres cannot compile BITMAP or OWNERDRAW menu items.

Thank you for reporting this.  In the future, please could you
report any binutils bugs via the bugzilla system here:

  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

In the meantime I have checked in the attached patch to fix the problem.

Cheers
  Nick

binutils/ChangeLog
2020-07-09  Nick Clifton  

* rclex.c: Add OWNERDRAW keyword.
* rcparse.y: Add OWNERDRAW token.
(menuitem_flag) Add BITMAP and OWNERDRAW entries.
* rcparse.c: Regenerate.
* resrc.c (write_rc_menuitems): Add support for OWNERDRAW and
BITMAP flags.
* windres.c (extended_menuitems): Likewise.
* testsuite/binutils-all/windres/menuitem_flags.rc: New test.
diff --git a/binutils/rclex.c b/binutils/rclex.c
index d6a0f91c7d..fac74b0491 100644
--- a/binutils/rclex.c
+++ b/binutils/rclex.c
@@ -94,7 +94,7 @@ static const struct rclex_keywords keywds[] =
   K(LANGUAGE), K(LISTBOX), K(LOADONCALL), K(LTEXT),
   K(MANIFEST), K(MENU), K(MENUBARBREAK), K(MENUBREAK),
   K(MENUEX), K(MENUITEM), K(MESSAGETABLE), K(MOVEABLE),
-  K(NOINVERT), K(NOT),
+  K(NOINVERT), K(NOT), K(OWNERDRAW),
   K(PLUGPLAY), K(POPUP), K(PRELOAD), K(PRODUCTVERSION),
   K(PURE), K(PUSHBOX), K(PUSHBUTTON),
   K(RADIOBUTTON), K(RCDATA), K(RTEXT),
diff --git a/binutils/rcparse.y b/binutils/rcparse.y
index 78ce917e23..c0ed338ed0 100644
--- a/binutils/rcparse.y
+++ b/binutils/rcparse.y
@@ -124,7 +124,7 @@ static const rc_res_id res_null_text = { 1, {{0, _unichar}}};
 %token ICON
 %token ANICURSOR ANIICON DLGINCLUDE DLGINIT FONTDIR HTML MANIFEST PLUGPLAY VXD TOOLBAR BUTTON
 %token LANGUAGE CHARACTERISTICS VERSIONK
-%token MENU MENUEX MENUITEM SEPARATOR POPUP CHECKED GRAYED HELP INACTIVE
+%token MENU MENUEX MENUITEM SEPARATOR POPUP CHECKED GRAYED HELP INACTIVE OWNERDRAW
 %token MENUBARBREAK MENUBREAK
 %token MESSAGETABLE
 %token RCDATA
@@ -1088,6 +1088,14 @@ menuitem_flag:
 	  {
 	$$ = MENUITEM_MENUBREAK;
 	  }
+	| BITMAP
+	  {
+	$$ = MENUITEM_BITMAP;
+	  }
+	| OWNERDRAW
+	  {
+	$$ = MENUITEM_OWNERDRAW;
+	  }
 	;
 
 /* Menuex resources.  */
diff --git a/binutils/resrc.c b/binutils/resrc.c
index a875c3a4ac..5a6336ee6c 100644
--- a/binutils/resrc.c
+++ b/binutils/resrc.c
@@ -2841,6 +2841,10 @@ write_rc_menuitems (FILE *e, const rc_menuitem *menuitems, int menuex,
 	fprintf (e, ", MENUBARBREAK");
 	  if ((mi->type & MENUITEM_MENUBREAK) != 0)
 	fprintf (e, ", MENUBREAK");
+	  if ((mi->type & MENUITEM_OWNERDRAW) != 0)
+	fprintf (e, ", OWNERDRAW");
+	  if ((mi->type & MENUITEM_BITMAP) != 0)
+	fprintf (e, ", BITMAP");
 	}
   else
 	{
diff --git a/binutils/windres.c b/binutils/windres.c
index 427e9823ce..5c83dab8fc 100644
--- a/binutils/windres.c
+++ b/binutils/windres.c
@@ -527,6 +527,8 @@ extended_menuitems (const rc_menuitem *menuitems)
 		| MENUITEM_HELP
 		| MENUITEM_INACTIVE
 		| MENUITEM_MENUBARBREAK
+		| MENUITEM_BITMAP
+		| MENUITEM_OWNERDRAW
 		| MENUITEM_MENUBREAK))
 	  != 0)
 	return 1;
--- /dev/null	2020-07-09 07:00:33.444572683 +0100
+++ binutils/testsuite/binutils-all/windres/menuitem_flags.rc	2020-07-09 12:22:15.647286406 +0100
@@ -0,0 +1,16 @@
+// parse-only
+
+1 MENU
+{
+POPUP ""
+{
+MENUITEM "This is a test #1", 100, BITMAP
+MENUITEM "This is a test #2", 101, OWNERDRAW
+MENUITEM "This is a test #3", 102, CHECKED
+MENUITEM "This is a test #4", 103, GRAYED
+MENUITEM "This is a test #5", 104, HELP
+MENUITEM "This is a test #6", 105, INACTIVE
+MENUITEM "This is a test #7", 106, MENUBARBREAK
+MENUITEM "This is a test #8", 107, MENUBREAK
+}
+}

Re: Possible bug in objdump

[Nick Clifton]

Hi Joe,

> The possible bug is explained in the comments near the beginning of the file
> Bug.c

Please could file a bug report using the binutils Bugzilla system here:

  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

When you do, it would be really helpful if you could include a copy of the
"Bug" executable, as well as the other files, as it is very hard to ensure
that we have exactly the same compilation environment as you have.

As to the the bug itself:

  //  99f:  48 8b 05 8a 52 20 00movrax,QWORD PTR [rip+0x20528a] 
   # 205c30 
  //
  // The instructions access XtStrings+0x48f0.  However, if you look at Bug.elf 
you see
  //
  //  11: 00201340  2649 OBJECT  GLOBAL DEFAULT   21 XtStrings
  //
  // The size of XtStrings is 2649 decimal.  But XtStrings+0x48f0 is beyond the 
region occupied by XtStrings.

My guess is that the disassembler has chosen XtStrings as being the
nearest user-visible symbol to the address referenced, in the hopes
that it might be useful to the reader.  The disassembler is not saying
that the XtStrings array is actually being used, but merely that it
could find any closer symbol.

Cheers
  Nick

Re: windmc Typedef Bug

[Nick Clifton]

Hi Joel,

> I did not see anything in the current bug list for windmc that covers this, 
> but fortunately the solution seems straightforward. I have attached a patch 
> with a minimal fix. The changes make the typecasting logic match mc.exe. I 
> will be happy to make any other requested adjustments as well.

Thanks very much for reporting this bug - and supplying a patch to fix it. :-)

I have gone ahead and applied the patch along with the changelog entry below.

In the future, if you do run across further bugs with the binutils, would you
mind reporting them using the binutils bugzilla system[1] ?  It just makes them
easier to track and ensure that they get fixed.

Cheers
  Nick

[1] https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

binutils/ChangeLog
2020-06-03  Joel Anderson  

* windmc.h (struct mc_node): Add id_typecast field.
* mcparse.y (message): Initialise the id_typecast field.
* windmc.c (write_dbg): Use the id_typecast field as a parameter
when calling write_dbg_define.
(write_header): Likewise.

Re: Found a bug in objdump-2.34

[Nick Clifton]

Hi Natalie,

> Hi, I found a bug in objdump-2.34 by my fuzzing research tool (not published 
> yet), which I ran with ASAN and shows the information below.
> Information and also the 11 similar crashes in an archive file are in the 
> attachment.

Thank you very much for letting us know about this problem.
As it happens I think that this problem is a duplicate of PR 25447
which fortunately has already been fixed.  The patch is in the
mainline development sources, and the 2.34 branch sources, 
although unfortunately it was created to late too make it into
the official 2.34 release.

  https://sourceware.org/bugzilla/show_bug.cgi?id=25447

In the future, if you encounter more bugs like this, please
could you file a bug report here:

  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

Using this system helps us to keep track of bugs and their fixes.

Cheers
  Nick

Re: Strange singular/plural messages in 2.33.90

[Nick Clifton]

Hi Göran,

> While translating 2.33.90 to Swedish, I came across this code from readelf.c:
> 
> warn (ngettext ("debuginfod: Corrupt note: only %ld byte remains, "
>   "not enough for a full note\n",
>   "Corrupt note: only %ld bytes remain, "
>   "not enough for a full note\n",
>   data_remaining),
> (long) data_remaining);
> 
> It seems strange you would want the "debuginfod" prefix only in the
> case of singular, while the plural form has no such prefix.  I suspect
> that is a mistake.
> 
> The code snippet appears twice.

Thanks for reporting this.  I have checked in the obvious fix.

Cheers
  Nick

binutils/ChangeLog
2020-01-24  Nick Clifton  

* readelf.c (get_build_id): Fix warning messages about corrupt
notes.

Re: Request: utf-8 support in `strings`

[Nick Clifton]

Hi B9,

> "Strings" is a fabulous and under-appreciated program. However, it only works 
> on text which has a fixed number of bytes per character such as Latin-1 or 
> UTF-16. Since almost all Unix systems now default to UTF-8 (which can be from 
> 1 to 6 bytes long), it would be wonderful if strings was updated to handle it.
 
Would you mind opening a bugzilla request for this enhancement ?

  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

This will help us track the problem, and provide a suitable place
for other people to comment on the issue.

If possible, it would also help if you were able to provide a small
test file that uses UTF-8 encoding with at least some characters
being more than 1 byte long.  Supplying the correct decoding of these
strings would also help in order to make sure that we get the code
right.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Information leakage in nm-2.32

[Nick Clifton]

Hi Natalie,

> I found a crash with AFL and used valgrind to run it. Looks like it is 
> information leakage problem.

When you say "crash" do you mean that the nm program generated
a segmentation fault or some kind of illegal memory access ?
That certainly does not appear to be the case here.

> Could you possibly fix this issue?

Not if it is just a case of allocated memory not being freed
by the time the program exits.  The memory will be returned
to the system, so there is no real problem with it not being
freed.  Plus since nm always exits, there is no potential for
it to hog memory and prevent normal system operation.

Sorry, but we are just not interested in resource leak problems
at the moment.  If you do find other issues however, for example
memory corruption, or illegal memory accesses, then please feel
free to report a bug using the binutils bugzilla system:

https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Abort in arc_insn_length

[Nick Clifton]

Hi Philippe,

> Function arc_insn_length calls abort
> Binutils version is from commit d8f68fcb9378b5ab1c945fa676e11da15be56dd6
> It seems to me that this function should return failure instead of aborting
> The patch could be as attached.

Please could you file this bug report here:

  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils

If you could include the test case that triggers the problem as well
as your proposed patch that would really help.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Memory leak in disassemble_init_for_target

[Nick Clifton]

Hi Philippe,

> And I would like to report two bugs, and propose the fuzz target.

As a general rule it is best to report bugs with the binutils using
the bugzilla system here:

  https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils


> This is a memory leak in function disassemble_init_for_target

> And is seems to me that this ressource gets never freed (in programs such as 
> objdump) (or am I missing a clean function to be called ?)

Nope - but it is completely unimportant.  The memory will be
freed when objdump exits, and it will always exit, so the
memory is never consumed for very long.


Basically we are interested in fuzzing results that show illegal
memory accesses or buffer overruns or the like.  But memory leaks
are just not interesting because all of the tools are short term
programs that never stay permanently resident.

Cheers
  Nick



___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Bugs report for cplus-dem.c in GNU Binutils 2.31

[Nick Clifton]

Hi 乐泰,

  Thank you very much for reporting these bugs.  Unfortunately
  there are a few problems with this report:

  * Bugs related to demangling in cplus-dem.c should actually
be reported to the GCC project, not the BINUTILS project.
This is because cplus-dem.c is part of the libiberty 
library, which is maintained as part of GCC.  The binutils
project makes use of the libiberty library, but it does
not maintain it.

  * Bugs like this should be reported by using the appropriate
bug reporting system.  For GCC this is done by creating a 
new bug report here:

  https://gcc.gnu.org/bugzilla/show_bug.cgi

   (For future reference bug reports for the binutils project
   can be filed here):

   https://sourceware.org/bugzilla/

 * You should try to use the latest version of the binutils
   sources when you run your tests.  In this case the latest
   released version is 2.32 not 2.31.  This is particularly
   important in this case because 2.32 contains several fixes
   to the cplus-dem.c source file.  In fact when I tried to 
   reproduce the failures you reported using the current
   development version of the binutils, none of them worked.
   Ie there were no segmentation faults of address violations 
   detected.

  I hope that this information helps, and thank you once again
  for your interest in the binutils.

Cheers
  Nick Clifton



___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Namespace problem

[Nick Clifton]

Hi Sebastian,

> I do OO programming in gnu-as (microchips xc32-as).

First off, it should be noted that this is a very, umm, 
difficult thing to do.  Object Oriented programming is
generally speaking a high level concept, whereas assembly
programming is a very low level activity.

> Now I have programms using their object area so the variable names are the 
> same at 
> different places. And some member code or init code has to be at an absolute 
> address.
> How is such a task handled in gas ?
> - You don't have namespace functionality !?

No.  Assemblers do not support namespaces.

You are going to have to implement namespace encoding yourself.

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: How create small binaries with GNU binutils.

[Nick Clifton]

Hi Dmitry,

> Thank you for suggestion, but map did not reveal anything. The only part
> (section?) with non zero size is .text of size 0xd (=13). This is
> correct, raw instructions are really 13 bytes (according to `objdump -d').

> By the way, `readelf --sections' reports, that there is no sections in
> fasm-generated binary. I do not know, how does fasm do it, but probably
> is saves on section headers or something like this. Is is possible to
> make `ld' do the same?

Ah ha - maybe that is it.  Maybe fasm is generating a binary with just
program segments but no sections, whereas ld is generating a binary with
both sections and segments[1].  Unfortunately I do not know of a way to 
tell ld to stop generating the sections.  Unfortunately it also appears
that the objcopy tool does not have an option for removing the sections
either.  (Actually it does, but removing the sections would remove the
code as well, whereas what we want to do is to remove the section header
table but leave in the program header table).

I am sorry, but I think that I going to be unable to help you. :-(

Cheers
  Nick

[1].  You could check this theory by running "readelf --section-headers 
--program-headers"
on the two binaries.  Both should have program headers but, if the 
theory is right, only the ld generated binary will have section headers.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: How create small binaries with GNU binutils.

[Nick Clifton]

Hi Dmitry,

>>> Still, even this way, 400 bytes is more then twice as big, compared to
>>> fasm. Any suggestions, how to shrink binary futher?

> Thank you for suggestion. Tried both options; no difference -- 400
> bytes.

Ho Hum.  In which case, do you know what is in the extra bytes ?  If you
link with the -Map=foo.map option you should get a map file which shows 
you how the output was constructed.  Perhaps this can help you find out
where the extra bytes are coming from.

Cheers
  Nick



___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: How create small binaries with GNU binutils.

[Nick Clifton]

Hi Dmitry,

> Still, even this way, 400 bytes is more then twice as big, compared to
> fasm. Any suggestions, how to shrink binary futher?

This might be because the linker defaults to page aligning the binaries.
Have you tried linking with the --nmagic option ?  (Or alternatively the
--omagic option).

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: bug report for binutils-2.30

[Nick Clifton]

HI Dongdong,

> We are doing some fuzzing tests on Binutils-2.30 

Just as an aside the latest binutils release is 2.31.1 ...

> and find a heap overflow bug in nm-new 32 bit version.

Was there a binutils bug report filed for this problem ?  I may have missed it.

> We also filed a interger-overflow bug in binutils-2.30 recently at 
> https://sourceware.org/bugzilla/show_bug.cgi?id=23932.

Thank you for filing this bug report.  I am currently testing a fix for it.

> Can we get the corresponding CVE number for the two bugs reported?

Sorry - we do not allocate these numbers.  Normally they are automatically
allocated by the Mitre corporation, which regularly scans the binutils bugzilla
system for new bug reports.  You can find out more information here:

  http://cve.mitre.org/cve/request_id.html

I should also note that it usually takes a couple of weeks between filing a bug
report in the binutils bugzilla system and a CVE number being allocated.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug binutils/23919] bfd doesn't handle ELF compressed data alignment

[Nick Clifton]

Hi Mark,

>>   One very minor point - in the future, would you mind providing the
>>   ChangeLog entries as plain text, rather than a context diff ?  It

> OK, I will in the future.
> Do you have some script that helps you handle separate ChangeLog entries?

Nope. :-(

> Note that gnulib contains some helpers for merging ChangeLog entries that I
> have used somewhat successfully with mercurial and git. They work the other 
> way
> around though, you explicitly do add the ChangeLog entries in the
> commit/ChangeLog file, but when a merge action takes place they handle the
> entry specially.
> 
> https://gnu.wildebeest.org/blog/mjw/2012/03/16/automagically-merging-changelog-files-with-mercurial-or-git/

Fantastic - thanks - I have been looking for something like that for ages.
Please consider my request for plain text changelog entries withdrawn!

Cheers
  Nick



___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: c++filt stack overflow bug

[Nick Clifton]

Hi Peng,

> Peng Li at Baidu X-Lab found a stack overflow bug in c++filt of the latest 
> binutils code base, I have confirmed it with address sanitizer. Please use 
> the “c++filt < stack_overflow_input ” to reproduce the bug. If you have any 
> questions, please let me know.

Thank you for telling us about this bug.

I did try to reproduce the bug using the latest version of the 
binutils development sources, but the problem did not occur.
Possibly you are using an older set of sources, or you are
running the test on a machine with a limited amount of stack
space.

Either way, please could you check the problem, and if it
still exists, report it here:

  https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc

This is actually the gcc bug reporting system, since the C++
demangling feature of the xc__filt program is actually supplied
by the libiberty library, which is maintained as part of gcc
rather than binutils.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: readelf reporting of e_shstrndx is slightly wrong

[Nick Clifton]

Hi Mike,

> If the file has no section name string table, this member holds the value 
> |SHN_UNDEF|. 
> If the section name string table section index is greater than or equal to 
> |SHN_LORESERVE| (|0xff00|), this member has the value |SHN_XINDEX| (|0x|) 

> The current readelf -h seems to assume that if there are more than 0xff00 
> sections, then the shstrndx will also be past that.  But there is nothing to 
> prevent the section name string table from being section 1, in which case 
> e_shstrndx should just be 1.  But the readelf implementation has:
> 
>    else if (elf_header.e_shstrndx != SHN_UNDEF && 
> elf_header.e_shstrndx >= elf_header.e_shnum)
> 
>        printf(_(“”));

I disagree.  The readelf code actually looks like this:

 if (filedata->section_headers != NULL
  && header->e_shstrndx == (SHN_XINDEX & 0x))
printf (" (%u)", filedata->section_headers[0].sh_link);
  else if (header->e_shstrndx != SHN_UNDEF
   && header->e_shstrndx >= header->e_shnum)
printf (_(" "));
   
There is no check that the file itself has more than 0xff00 sections.
Instead it checks to see if the e_shstrndx field is SHN_XINDEX and if
so it follows the link.  Otherwise it checks that the index is either
SHN_UNDEF or a valid section number.

Note - the use if "& 0x" in the above code is confusing, and looks
surplus to me, but I do not think that it makes any difference to the
behaviour.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: crash accessing address 0 in readelf (binutils-2.2.7a)

[Nick Clifton]

Hi Laurent,

> I've come across an issue in readelf (binutils-2.2.7a), as follows:

Thanks for reporting this problem.  In the future, would you mind using
the binutils bugzilla system as this allows us to keep a track of the
bug and fixes that we create for it:

https://sourceware.org/bugzilla/enter_bug.cgi


> Even if the function slurp_hppa_unwind_table() fails, the function 
> dump_hppa_unwind() 
> is executed. In dump_hppa_unwind():

Your fix should work, but I think that it would be cleaner to update 
slurp_hppa_unwind_table
instead.  Would you mind checking this patch and letting me know if it works ?

diff --git a/binutils/readelf.c b/binutils/readelf.c
index 90dbdf7e2b..34acf6346a 100644
--- a/binutils/readelf.c
+++ b/binutils/readelf.c
@@ -7934,6 +7934,8 @@ slurp_hppa_unwind_table (Filedata *  
filedata,
   Elf_Internal_Sym * sym;
   const char * relname;
 
+  aux->table_len = 0;
+
   /* First, find the starting address of the segment that includes
  this section.  */
   if (filedata->file_header.e_phnum)


> I can give you the input to trigger the bug if you'd like. I tried to attach 
> it to this email but could not as your server thinks there is malware in it...

he he.  Well you should be able to upload it to the bugzilla system if you use 
that.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Bugs report for binutils-2.30 strip and readelf

[Nick Clifton]

Hi Dongdong,

> I am Dongdong She, a PhD student in computer security area from Columbia 
> University. We are doing some fuzzing tests on binutils-2.30 and found a 
> integer-overflow bugs in strip-new.
> 
> Integer-overflow bug in strip-new.

Thank you very much for reporting this bug.  Please could you create a bug
report in the binutils bugzilla system:

  https://sourceware.org/bugzilla/enter_bug.cgi

This allows us to track the bug, and its fix.

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Translatable strings not marked 'c-format'

[Nick Clifton]

Hi Ask,

> But what if by accident I change it to %pA?  In between the thousands
> of messages and dozens of languages, the probability of this happening
> approaches one (Murphy's law).  I mischievously typed "%pA" instead,
> and it produced no error. 

Hmm, well mistakes can always happen, and I am not sure if there is much
more that we can do about it. 

> Now we can be pretty certain that these
> errors will happen at runtime, and the question is whether the
> formatting functions handle them gracefully, crash, or output things
> from random places in memory.

An abort or garbage output are the most likely outcomes.  The formatting
functions do perform some sanity checks, but there is only so much that
can be done.

In the end we have to rely upon bug reports from the users saying something
like "the linker crashes when I run it with this input using this translation".

Cheers
  Nick





___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Certain files getting overwritten between GNU binutils and GDB

[Nick Clifton]

Hi Kaushal,

> I already have GDB 8.0.1 installed using that flow. But when I try to install 
> GNU binutils using the same flow, it fails because these files are the exact 
> same between the two installations:

If the files are exactly the same, then it should not matter which version you 
install.

> So, which versions should I keep.. the ones installed by GDB or the ones by 
> binutils?

This is a tricky one since the binutils and gdb share some files, as you have 
seen, but
they have different release cadences, so the files in one package may not match 
those
in the other package.

My suggestion for resolving this problem is as follows:

  * If the two versions of the file are the same, use the first version.
  * For files in the include/ directory, use the most recent version.
  * For files in the lib/ and share/ directories, use the versions from the 
binutils package.

Cheers
  Nick



___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Problems in objcopy.1, objdump.1, x86_64-linux-gnu-objcopy.1, x86_64-linux-gnu-objdump.1

[Nick Clifton]

Hi Eric,

> Problems with objcopy.1:

> -[\fB\-\-add\-symbol\fR 
> \fIname\fR=[\fIsection\fR:]\fIvalue\fR[,\fIflags\fR]
> +[\fB\-\-add\-symbol\fR 
> \fIname\fR=[\fIsection\fR:]\fIvalue\fR[,\fIflags\fR]]

This one has already been fixed in the development sources:

2018-02-20  Ronald Hoogenboom  

* doc/binutils.texi (objcopy): Add missing closing square
parenthesis to listing of objcopy's command line options.


> Problems with objdump.1:

> - 
> \fB\-\-dwarf\fR[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames\-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges,=gdb_index,=addr,=cu_index,=links,=follow\-links]
> + 
> \fB\-\-dwarf\fR[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames\-interp,=str,=loc,=Ranges,=pubtypes,=trace_info,=trace_abbrev,=trace_aranges,=gdb_index,=addr,=cu_index,=links,=follow\-links]]

This one has now been fixed.

Cheers
  Nick

binutils/ChangeLog
2018-06-13  Nick Clifton  

* doc/binutils.texi (objdump): Add missing closing square
parenthesis to listing of objcopy's command line options.

diff --git a/binutils/doc/binutils.texi b/binutils/doc/binutils.texi
index 863ef31e36..b87b1341fc 100644
--- a/binutils/doc/binutils.texi
+++ b/binutils/doc/binutils.texi
@@ -2077,7 +2077,7 @@ objdump [@option{-a}|@option{--archive-headers}]
 [@option{-R}|@option{--dynamic-reloc}]
 [@option{-s}|@option{--full-contents}]
 [@option{-W[lLiaprmfFsoRtUuTgAckK]}|
- 
@option{--dwarf}[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames-interp,=str,=loc,=Ranges,
=pubtypes,=trace_info,=trace_abbrev,=trace_aranges,=gdb_index,=addr,=cu_index,=links,=follow-links]
+ 
@option{--dwarf}[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames-interp,=str,=loc,=Ranges,
=pubtypes,=trace_info,=trace_abbrev,=trace_aranges,=gdb_index,=addr,=cu_index,=links,=follow-links]]
 [@option{-G}|@option{--stabs}]
 [@option{-t}|@option{--syms}]
 [@option{-T}|@option{--dynamic-syms}]

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug binutils/18616] oprofile fails with "BFD: Dwarf Error: found dwarf version '64617', this reader only handles version 2, 3 and 4 information"

[Nick Clifton]

Hi Marco,

>> I doubt if this is the same as oprofile will produce, but both tools
>> will be displaying processed DWARF line number information so they
>> should be roughly equivalent.
> 
> The objdump output looks fine. Does that mean the issue has to be in Oprofile?

Not "has to", but it is definitely the current most likely suspect.

I am not familiar with oprofile, so I cannot help debug it, but if
someone else is able to delve into it that would be a great help.

Cheers
  Nick



___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug ld/22929] x86_64 linker seg-faults when creating a shared object from an input containg relocations against note section without SHF_ALLOC

[Nick Clifton]

Hi H.J.

> The value will be wrong.  Linker can only resolve PC relative relocations> 
> against local definition.
But can't the linker assume that the object is located at address 0 and
resolve the relocations using that ?  It does not matter that this address
will not match the run-time address of the object, it is only going to be
used when performing a static analysis of the binary.

Cheers
  Nick



___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: bfd/elf32-arc.c:1537]: (warning) Redundant assignment

[Nick Clifton]

Hi David,

> bfd/elf32-arc.c:1537]: (warning) Redundant assignment of 'rel->r_offset' to 
> itself.

Thanks for reporting this problem.  I have checked in
a small patch to remove the assignment.

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: bfd/elf32-nds32.c:9693]: (warning) Redundant assignment

[Nick Clifton]

Hi David,

> bfd/elf32-nds32.c:9693]: (warning) Redundant assignment of 'irel->r_addend' 
> to itself.

Thanks for reporting this.  I have checked in the obvious fix
of removing the redundant assignment.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Translatable strings not marked 'c-format'

[Nick Clifton]

Hi Ask,

> Should I ask the translators for each language to individually submit
> the updates to their language?

Yes please.

> I assume the fixes should be applied to both the old and the new
> version.  Correct?

Correct - thanks very much.

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Translatable strings not marked 'c-format'

[Nick Clifton]

Hi Ask,

> Meanwhile, do we disable the strings that have translation errors?
> There are currently 6 affected languages, and we need only mark the
> relevant strings as 'fuzzy' in each po-file.  It would be bad to let
> the errors remain in a version that is to be shipped soon.

I think that that would be a good idea.  Is this something that you can do ?

Cheers
  Nick



___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Translatable strings not marked 'c-format'

[Nick Clifton]

Hi Ask,

> To solve this problem, BFD should either use only the formatting codes
> of printf (translation errors will be detected automatically) or avoid
> exposing any strings with %A and %B to translators.

I just wanted to let you know that your email has not been ignored.

I do have a plan to replace the %A and %B format characters in the binutils
sources, but I am going to wait until after the 2.30 branch is cut (ie Jan
12) as I suspect that the changes will create a lot of turmoil.

Cheers
  Nick



___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug gas/22492] Incorrect note section alignment

[Nick Clifton]

Hi Alan,

> https://sourceware.org/bugzilla/show_bug.cgi?id=22492

> Was the patch in comment #1 posted to the mailing list?

Sorry no - that was my bad.

> There's a small nit.. 
> I think it should be using record_alignment rather than
> bfd_set_section_alignment.

So it should.  I have checked in this patch to fix the problem.

Cheers
  Nick

gas/ChangeLog
2017-11-29  Nick Clifton  <ni...@redhat.com>

PR 22492
* config/obj-elf.c (obj_elf_version): Use record_alignment rather
than bfd_set_section_alignment.


diff --git a/gas/config/obj-elf.c b/gas/config/obj-elf.c
index 2d1d1679b8..61c573a5e4 100644
--- a/gas/config/obj-elf.c
+++ b/gas/config/obj-elf.c
@@ -1829,7 +1829,7 @@ obj_elf_version (int ignore ATTRIBUTE_UNUSED)
   bfd_set_section_flags (stdoutput,
 note_secp,
 SEC_HAS_CONTENTS | SEC_READONLY);
-  bfd_set_section_alignment (stdoutput, note_secp, 2);
+  record_alignment (note_secp, 2);
 
   /* Process the version string.  */
   len = strlen (name) + 1;

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Dwarf changes

[Nick Clifton]

Hi Parul,

> I have done porting of GNU binutils for a new architecture.
> Can you tell me if I have to do any changes for dwarf, while porting.

There are a few places where you will need to add dwarf support:

  * In your assembler function that generates an instruction (usually
md_assemble or one of its subroutines) you should call dwarf2_emit_insn
to let the dwarf code know how many bytes have been generated.

  * In the binutils/readelf.c source file you should make sure that any of
the relocations that you generate against DWARF sections are covered
by one of the is_32bit_abs_reloc() ... is_none_reloc() functions.

That should be it.  Running the testsuites may expose a couple of places 
that I have forgotten however.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Changes done in binutils revision

[Nick Clifton]

Hi Parul,

> Can someone help me, how can I check what all changes are done from 2.26 to 
> 2.27.
> I do not know how to use git.
> I want to know what all changes are done for x86-64.

I am not a git expert either, but this worked for me (when run at the top 
level of my cloned binutils repository):

  git diff origin/binutils-2_26-branch..origin/binutils-2_27-branch

This did produce lots of output however (~34 megabytes!) so you may want to 
restrict
it to just those files you are interested in.  For example:

 git diff origin/binutils-2_26-branch..origin/binutils-2_27-branch -- 
bfd/elf32-i386.c bfd/elf64-x86-64.c

will show you just the changes to the elf32-i386.c and elf64-x86-64.c files.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: There's some errors downloading binutils

[Nick Clifton]

Hi 정예주,

> When I download binutils and compile it, there's always errors.
> I don't know the reason, but I think the reason is the version.

You are correct.


> I'm using Mac, and I want to know if there is appropriate version of binutils 
> for mac.

Not specifically no.


> my professor recommended 2.19.tar.bz2

This is a very old version.  We are currently at release 2.29 and I would urge 
you to
try using this version instead.  If you still have problems with the 2.29 
release please
post again and we will try to help.

Cheers
  Nick




___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug gas/21934] gas build fails when using gcc 7

[Nick Clifton]

Hi H.J.

> Why don't I see on i386 cross to x86_64?  We have
No idea.  I was wondering that too.

> static char output_invalid_buf[sizeof (unsigned char) * 2 + 6];
> 
> It has 8 bytes, not 5.

But the printing of the value starts three bytes into the buffer
which is why gcc says that there are only 5 bytes left.

The warning looks wrong to me though, since the value has been
cast to an unsigned char, so no sign extension should be happening.
I was debating as to whether this was worth pursuing or whether
it would be simpler to just accept the patch and be done with it.

Cheers
  Nick



___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug ld/21251] Support $SYSROOT in ld -L and INPUT command

[Nick Clifton]

Hi Rainer,

>> Hmm, I was going to say not a lot, but then I remembered that GCC uses it:
>>
>>https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
> 
> Maybe I'm blind, but where did you see that?

Umm, do you mean "where in that web page do I see an '=' prefix being used
to indicate that a sysroot should be used ?"  Then, right at the start:

  -idirafter dir

  Add the directory dir to the list of directories to be searched 
  for header files during preprocessing. If dir begins with  ‘=’, 
  then the ‘=’ is replaced by the sysroot prefix; see --sysroot and -isysroot. 

If you mean, "where does this information come from ?"  The have a look in
gcc/doc/cppdiropts.texi.


> I'd have been surprised to find pure linker option descriptions repeated
> in the GCC manual, so I didn't even think to look.

Well to be honest it is talking about the c-preprocessor include path options
rather than the linker search path, but I think that it establishes a principle
which users will expect to be followed.  IE if include paths can use a '=' 
prefix
then library search paths should be able to as well.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: binutils options

[Nick Clifton]

Hi Parul,

> I am also able to do testing of binutils using dejaGNU. But, there are few 
> options for which I am stuck up and not able to test these options. These are 
> as follows if someone can help:
> 
> 1.--strip-discarded
> 2.--no-strip-discarded
> 3.--embedded-relocs
> 4.--fatal-warnings
> 5.--no-fatal-warnings
> 6.-fini SYMBOL
> 7.--force-exe-suffix
> 8.--init SYMBOL
> 9.--no-undefined-version
> 10. --no-warn-mismatch
> 11. --no-warn-search-mismatch
> 12. --spare-dynamic-tags COUNT
> 13.  --split-by-reloc [=COUNT]
> 14. --task-link SYMBOL

To be honest, I would not worry about any of these options.  None of them
(well except for --embedded-relocs) has any target specific effects, and 
so you should not need to test them for your particular port.

Cheers
  Nick

PS.  The --embedded-relocs option does have a target specific effect, but it
is only used by a very few targets (bfin, cr16, m68k) and I doubt if it is
needed for your target.

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: relocation information disappears

[Nick Clifton]

Hi Katsuya,

> # ~/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-readelf 
> -r w

I assume that you mean "readelf -D -r w" here, as you are looking for dynamic 
relocs ?

> Relocation section '.rel.dyn' at offset 0x270 contains 1 entries:
>  Offset InfoTypeSym.Value  Sym. Name
> 0002101c  0315 R_ARM_GLOB_DAT   __gmon_start__
> 
> There is no "debug_f" symbol.
> Why not?

I cannot reproduce this.  As in, when I compile your test file there is a 
reference
to the debug_f symbol in the dynamic relocations.  I am using a different 
version of
the compiler (7.0.1) and the binutils (2.28.51) however, so that might explain 
it.

What happens when you run the compiled w.c test program ?  Is there a seg-fault 
for
accessing memory at address 0 ?

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Fwd: GNU Binutils-2.7 - Unable to configure

[Nick Clifton]

Hi Neha,

> When I try to configure it, I get the following error -
> 
> binutils-2.7> ./configure
> Invalid configuration `x86_64-unknown-linuxoldld': machine `x86_64-unknown' 
> not recognized

It sounds like you are using an extremely old set of binutils
sources.  We are currently on release 2.27, so I would recommend
obtaining these and then trying again.

Cheers
  Nick

PS. The "x86_64-unknown-linuxoldld" triple was deprecated in 2009...

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug ld/20828] GC-ed DSO symbols make corresponding symbols defined by a linker script local

[Nick Clifton]

Hi Maciej,

> Fixed as per the automatic commit messages.

Unfortunately the new test fails for some targets:

Checking Binutils in: bfin-elf ... LD REGRESSION: PR ld/20828 dynamic symbols 
with 
Checking Binutils in: riscv32-elf ... LD REGRESSION: PR ld/20828 dynamic 
symbols with 
Checking Binutils in: metag-elf ... LD REGRESSION: PR ld/20828 dynamic symbols 
with
Checking Binutils in: riscv64-elf ... LD REGRESSION: PR ld/20828 dynamic 
symbols with
Checking Binutils in: x86_64-solaris2 ... LD REGRESSION: PR ld/20828 dynamic 
symbols with
Checking Binutils in: mn10300-elf ... LD REGRESSION: PR ld/20828 dynamic 
symbols with
Checking Binutils in: score-elf ... LD REGRESSION: PR ld/20828 dynamic symbols 
with
Checking Binutils in: sh-elf ... LD REGRESSION: PR ld/20828 dynamic symbols with
 
Could you have a look into these please ?

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: objdump '--stop-address' option stop on a wrong ending address

[Nick Clifton]

Hi Florian,

> I try to extract function assembly code with objdump using
> "--start-address" and "--stop-address" options but the stop address stop
> on the second to last address.

> $ objdump --start-address=0x50c40 --stop-address=0x50c5f -d

>50c59: b8 01 00 00 00  mov$0x1,%eax
>50c5e: c3  retq
> 
> As you can see the last address is wrong. The assembly code stop on
> 0x50c5e instead of 0x50c5f.

Actually this is the intended behaviour.  The --stop-address option 
specifies the address at which objdump should *stop* displaying data.  
So when objdump reaches address 50c5f it stops and does not display
the disassembly for that address.

In order to display the entire disassembly of a specific region you
need to set the stop address to one more than the last address of the
region concerned.  So in your example:

  $ objdump --start-address=0x50c40 --stop-address=0x50c60 -d

should work.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Translatable strings not marked 'c-format'

[Nick Clifton]

Hi Ask,

> Do you know when the translation
> templates on translationproject.org will be updated?

On translationproject.org - no.  But I have just updated the
bfd.pot template in the binutils source repository (which I
forgot to do yesterday, sorry).

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Translatable strings not marked 'c-format'

[Nick Clifton]

Hi Ask,

> In the translation template for bfd [1], very few strings have the
> c-format tag which makes gettext able to tell if placeholders (%s, %d,
> ...) are mistranslated.  This typically affects the substitution codes
> %B and %A.
> 
> It is very unlikely that any translator can translate all 1400 strings
> without a single error in the substitution codes, which could have
> nasty consequences - I think.  Can this be improved somehow?

I have checked in the attached patch to update the sources in the BFD
library.  Other directories (eg ld, gas, etc) will probably also need
an update, but I am leaving this for another time.

Cheers
  Nick

bfd/ChangeLog
2016-10-19  Nick Clifton  <ni...@redhat.com>

* aout-adobe.c: Add missing c-format tags for translatable strings.
* aout-cris.c: Likewise.
* aoutx.h: Likewise.
* bfd.c: Likewise.
* binary.c: Likewise.
* cache.c: Likewise.
* coff-alpha.c: Likewise.
* coff-arm.c: Likewise.
* coff-i860.c: Likewise.
* coff-mcore.c: Likewise.
* coff-ppc.c: Likewise.
* coff-rs6000.c: Likewise.
* coff-sh.c: Likewise.
* coff-tic4x.c: Likewise.
* coff-tic54x.c: Likewise.
* coff-tic80.c: Likewise.
* coff64-rs6000.c: Likewise.
* coffcode.h: Likewise.
* coffgen.c: Likewise.
* cofflink.c: Likewise.
* coffswap.h: Likewise.
* cpu-arm.c: Likewise.
* dwarf2.c: Likewise.
* ecoff.c: Likewise.
* elf-attrs.c: Likewise.
* elf-eh-frame.c: Likewise.
* elf-ifunc.c: Likewise.
* elf-m10300.c: Likewise.
* elf-s390-common.c: Likewise.
* elf.c: Likewise.
* elf32-arc.c: Likewise.
* elf32-arm.c: Likewise.
* elf32-avr.c: Likewise.
* elf32-bfin.c: Likewise.
* elf32-cr16.c: Likewise.
* elf32-cr16c.c: Likewise.
* elf32-cris.c: Likewise.
* elf32-crx.c: Likewise.
* elf32-d10v.c: Likewise.
* elf32-d30v.c: Likewise.
* elf32-epiphany.c: Likewise.
* elf32-fr30.c: Likewise.
* elf32-frv.c: Likewise.
* elf32-gen.c: Likewise.
* elf32-hppa.c: Likewise.
* elf32-i370.c: Likewise.
* elf32-i386.c: Likewise.
* elf32-i960.c: Likewise.
* elf32-ip2k.c: Likewise.
* elf32-iq2000.c: Likewise.
* elf32-lm32.c: Likewise.
* elf32-m32c.c: Likewise.
* elf32-m32r.c: Likewise.
* elf32-m68hc11.c: Likewise.
* elf32-m68hc12.c: Likewise.
* elf32-m68hc1x.c: Likewise.
* elf32-m68k.c: Likewise.
* elf32-mcore.c: Likewise.
* elf32-mep.c: Likewise.
* elf32-metag.c: Likewise.
* elf32-microblaze.c: Likewise.
* elf32-moxie.c: Likewise.
* elf32-msp430.c: Likewise.
* elf32-mt.c: Likewise.
* elf32-nds32.c: Likewise.
* elf32-nios2.c: Likewise.
* elf32-or1k.c: Likewise.
* elf32-pj.c: Likewise.
* elf32-ppc.c: Likewise.
* elf32-rl78.c: Likewise.
* elf32-rx.c: Likewise.
* elf32-s390.c: Likewise.
* elf32-score.c: Likewise.
* elf32-score7.c: Likewise.
* elf32-sh-symbian.c: Likewise.
* elf32-sh.c: Likewise.
* elf32-sh64.c: Likewise.
* elf32-spu.c: Likewise.
* elf32-tic6x.c: Likewise.
* elf32-tilepro.c: Likewise.
* elf32-v850.c: Likewise.
* elf32-vax.c: Likewise.
* elf32-visium.c: Likewise.
* elf32-xgate.c: Likewise.
* elf32-xtensa.c: Likewise.
* elf64-alpha.c: Likewise.
* elf64-gen.c: Likewise.
* elf64-hppa.c: Likewise.
* elf64-ia64-vms.c: Likewise.
* elf64-mmix.c: Likewise.
* elf64-ppc.c: Likewise.
* elf64-s390.c: Likewise.
* elf64-sh64.c: Likewise.
* elf64-sparc.c: Likewise.
* elf64-x86-64.c: Likewise.
* elfcode.h: Likewise.
* elfcore.h: Likewise.
* elflink.c: Likewise.
* elfnn-aarch64.c: Likewise.
* elfnn-ia64.c: Likewise.
* elfxx-mips.c: Likewise.
* elfxx-sparc.c: Likewise.
* elfxx-tilegx.c: Likewise.
* ieee.c: Likewise.
* ihex.c: Likewise.
* libbfd.c: Likewise.
* linker.c: Likewise.
* m68klinux.c: Likewise.
* mach-o.c: Likewise.
* merge.c: Likewise.
* mmo.c: Likewise.
* oasys.c: Likewise.
* pdp11.c: Likewise.
* pe-mips.c: Likewise.
* peXXigen.c: Likewise.
* pei-x86_64.c: Likewise.
* peicode.h: Likewise.
* ppcboot.c: Likewise.
* reloc.c: Likewise.
* sparclinux.c: Likewise.
* srec.c: Likewise.
* stabs.c: Likewise.
* vms-alpha.c: Likewise.
<   * vms-lib.c: Likewise.
* xcofflink.c: Likewise.


bfd.c-format.pat

Re: [Bug gas/20692] gas failed on SPARC

[Nick Clifton]

Hi Igor,

>> You could try adding "-D.volatile= -D.nonvolatile= -Wa,--no-relax" to the

> your solution doesn't work.
> GAS command line on SPARC not accepted -Wa,--no-relax
> we can use -no-relax 

Oops - I had too many dashes, sorry about that.

> - but it is not fixed my problem 

Well, it does fix the assembler problem you had.  Now you have a linker/
source file problem.

> and i can see:

> Text relocation remains referenced
> against symbol  offset  in file
> _GLOBAL_OFFSET_TABLE_   0x214   pics/_rtbootld.o
> _GLOBAL_OFFSET_TABLE_   0x194   pics/door.o

> ld: fatal: relocations remain against allocatable but non-writable sections

Well the linker error messages seems pretty clear.  My guess would be
that _rtbootld.o and door.o come from assembler source files, or else 
C/C++ source files containing inline assembler directives, and that
they are creating special sections of their own.  Can you modify the
sources files ?  If so you could use "objdump -r pics/"
to find out which sections have these problematic relocations, and
then you could edit the sources to add the writeable attribute to the
section declarations.

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Infinite recursion in binutils 2.27 (ld, gdb, c++filt)

[Nick Clifton]

Hi Matthieu,

> We are hitting an infinite recursion in "ld", eventually leading to a 
> stackoverflow 

Please could you file a bug report at:

  https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc

(Note - this is the GCC bug reporting system not the binutils bug reporting
system.  This is because the bug is in the C++ demangling functions provided
by libiberty.  The libiberty library is used by both GCC and binutils, but it
is officially maintained as part of the GCC package).

> $ /opt/imc/gcc-6.2.0/bin/g++ -fPIC -std=c++14 -O3 -ggdb -o main.cpp.o -c 
> main.cpp

When you file the report it would be helpful if you could skip this step, and
instead upload the main.cpp.o file.  Anyone attempting to reproduce the problem
may not have exactly the same version of g++ available as the one you used, and 
so eliminating the compiler makes things simpler.

> $ /opt/imc/gcc-6.2.0/bin/g++ -fPIC -std=c++14 -shared -o libCrash.so 
> main.cpp.o -Wl,--version-script=simple.map
> collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
> compilation terminated.

Please do include this command line however, and the simple.map script.

It would also be worth noting in the report that the problem is an infinite
loop between the libiberty/cp-demangle.c:d_print_comp() and d_comp_print_inner()
functions.


> $ c++filt --version
> GNU c++filt version 2.23.52.0.1-55.el7 20130226
> 
> $ /opt/imc/gcc-6.2.0/bin/ld --version
> GNU ld (GNU Binutils) 2.27

> However the symbol reported in this one does crash c++filt (although not ld):
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909

That is almost certainly because the version of c++filt that you are using is
based upon an older binutils release (2.23), whereas the linker is based upon
a newer release (2.27).

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug ld/20528] ld -r doesn't handle SHF_EXCLUDE section properly

[Nick Clifton]

Hi H.J.

> This works:
> 
> diff --git a/ld/emultempl/elf32.em b/ld/emultempl/elf32.em
> index dd4d35a..6ce4e00 100644
> --- a/ld/emultempl/elf32.em
> +++ b/ld/emultempl/elf32.em
> @@ -1903,9 +1903,16 @@ gld${EMULATION_NAME}_place_orphan (asection *s,
>   lang_insert_orphan to create a new output section.  */
>constraint = SPECIAL;
> 
> +  /* SEC_EXCLUDE is ignored when doing a relocatable link.  But
> + we can't merge 2 input sections with the same name when only
> + one of them has SHF_EXCLUDE.  */
>if (os->bfd_section != NULL
>&& (os->bfd_section->flags == 0
> - || (((s->flags ^ os->bfd_section->flags)
> + || ((!bfd_link_relocatable (_info)
> +  || (((elf_section_flags (s)
> +  ^ elf_section_flags (os->bfd_section))
> + & SHF_EXCLUDE) == 0))
> + && ((s->flags ^ os->bfd_section->flags)
>& (SEC_LOAD | SEC_ALLOC)) == 0
>   && _bfd_elf_match_sections_by_type (link_info.output_bfd,
>  os->bfd_section,

Looks good to me too - please consider the patch approved.

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [BUG] ld internal error while trying to link clang

[Nick Clifton]

Hi Lucien,

> /usr/bin/ld: BFD (GNU Binutils for Debian) 2.26.1 internal error, aborting at 
> ../../bfd/merge.c:905 in _bfd_merged_section_offset

Thanks for reporting this problem.  The 2.26.1 release is a little old now -
there is a 2.27 release available.  So the problem may have already been 
fixed.  But if you find that it is still reproducible using the 2.27 sources
(or even better - the current mainline development sources), then please let
us know by filing a bug report with the binutils bugzilla system:

  https://sourceware.org/bugzilla/

It will help immensely if you are able to provide a testcase that can 
reproduce the problem.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: ld 2.27: segfault on armv7h on input in 'binary' format

[Nick Clifton]

Hi redfish,

> $ touch foo.dat
> $ /usr/bin/ld -r -b binary -o /tmp/foo.o foo.dat
> Segmentation fault (core dumped)

Ah - snafu - fixed by this patch.

Cheers
  Nick

bfd/ChangeLog
2016-08-23  Nick Clifton  <ni...@redhat.com>

* elf32-arm.c (elf32_arm_count_additional_relocs): Return zero if
there is no arm data associated with the section.

diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c
index 1eba21b..4478238 100644
--- a/bfd/elf32-arm.c
+++ b/bfd/elf32-arm.c
@@ -18688,7 +18688,7 @@ elf32_arm_count_additional_relocs (asection *sec)
 {
   struct _arm_elf_section_data *arm_data;
   arm_data = get_arm_elf_section_data (sec);
-  return arm_data->additional_reloc_count;
+  return arm_data == NULL ? 0 : arm_data->additional_reloc_count;
 }
 
 /* Called to set the sh_flags, sh_link and sh_info fields of OSECTION which

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug ld/20436] New: Testsuite ld-plugin/lto.exp fails

[Nick Clifton]

Hi H.J.

  Please could you look at this bug report:

https://sourceware.org/bugzilla/show_bug.cgi?id=20436

  It appears to be a direct consequence of your patch from 2016-04-21:

* testsuite/lib/ld-lib.exp (check_lto_available): Return 1 on
Linux with GCC 4.9 or newer.
(check_lto_fat_available): Likewise.
(check_lto_shared_available): Likewise.

Cheers
  Nick

PS.  Incidentally, I could not find that entry in the ld/ChangeLog file.
  Was it omitted ?

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug gas/20427] Solaris rtld on SPARC does not allow R_SPARC_UA64 or R_SPARC_64 relocations in 32-bit executables

[Nick Clifton]

Hi Stefan,

> So, this is what happens if i re-write the test32.S program for the Sun
> SPARC assembler:


> .comm .gomp_critical_user_, 64, 8

> Relocation section '.rela.data' at offset 0xf8 contains 1 entries:
>  Offset InfoTypeSym. Value  Symbol's Name + Addend
> 0004  0303 R_SPARC_32 0008   .gomp_critical_user_ + 0

Interesting.  I wonder if this is a bug in the Solaris assembler ?  

Maybe it knows that a symbol's value can only ever be 32-bits, so in this
particular case the reloc will work.  But what if the test really needed a
(non-zero) 64-bit value to be installed into the memory location.

For example, how does the Solaris assembler handle this:

 .data
.global __kmp_unnamed_critical_addr

 __kmp_unnamed_critical_addr:
.xword .gomp_critical_user_ + 0x1234567890
.type __kmp_unnamed_critical_addr,#object
.size __kmp_unnamed_critical_addr, .-__kmp_unnamed_critical_addr


Looking at the output for GAS, it seems that the addition in the reloc 
is truncated:

   R_SPARC_UA64  .gomp_critical_user_+0x34567890

This is not reported as an error, either, so presumably it is expected
behaviour.  Which makes me think that your patch will be OK.  But I would
like to know the results of your search for other 64-bit tests.

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Missing support for demangling lambdas with auto paramters in libbfd?

[Nick Clifton]

Hi Ronny,

> c++filt and libbfd are unable to demangle the last two: (binutils
> version 2.26 on Kubuntu 16.04)

Thanks for reporting this problem.  Unfortunately you have reported
it to the wrong place.  Name demangling is handled by the libiberty
library which is part of the GCC project, not the binutils project.
(Binutils uses it, but GCC manages it).  Please could you repost 
your bug report to gcc-b...@gcc.gnu.org.

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug ld/20152] constructors for c++ objects are sometimes discarded when linked via a .a archive

[Nick Clifton]

Hi Dave,

>   * if foo.o is linked directly into an executable, f's ctor is run before
> "main".
>   * if foo.o is linked into a .a and then that .a is linked into an 
> executable,
> f's ctor may or may not be run before "main".  The constructor is only run if
> there's at least one symbol in foo.o that's referenced by the main program.

Right - this is the intended behaviour.

> Note that although the C++ object f isn't used, f's ctor may have interesting
> side-effects that need to happen; the parameters may reference things that 
> need
> to be linked (in my case I was using it to register unit testing functions 
> with
> a test runner).

Unfortunately the linker is unable to detect these interesting side-effects, and
so it cannot know that the object's constructor is actually needed.


> I don't know if this behavior is a bug, but this is sufficiently surprising to
> me that I wanted to capture it somewhere with a URL; it seems like a "gotcha"
> to me  (it took me a couple of days of stepping through the link of gcc to
> track down).

Did you read the linker documentation when you were looking for an answer ?
I was wondering whether it would be worthwhile adding a paragraph there to cover
this situation, in the hopes of helping future programmers.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: MIPS version of LD not honoring -Ttext for .MIPS.abiflags section

[Nick Clifton]

Hi Geoff,

> The problem with the first approach is I would like the linker 
> to just pack the MIPS abiflags section with the .text, .got and
> .rodata sections so I don't have to calculate the size of the 
> other sections ahead of time.

Is the .MIPS.abiflags section a fixed size ?  I suspect that it is.
If I am right then you could try something like this:

  --start-address=.MIPS.abiflags=0x8020 -Ttext=0x80200012

(If the section is 0x12 bytes long...)

If you cannot find a workaround for the problem, please feel free
to file a bug report here:

  https://sourceware.org/bugzilla/

Not that I am guaranteeing that we will be able to find a solution
ourselves, but it is worth a try.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: MIPS version of LD not honoring -Ttext for .MIPS.abiflags section

[Nick Clifton]

Hi Geoff,

> When compiling one of the u-boot demo applications using the 
> "-Ttext 0x8020" option, the resulting elf file has a 
> .MIPS.abiflags section with a load address of "004000b8".

Have you tried adding:

  --start-address=.MIPS.abiflags=0x8030

(or whatever address you want) ?


> The problem is the linker is not honouring the -Ttext flag 
> for the .MIPS.abiflags section like it does for the .got, 
> .rodata and .bss sections.

True.  I suspect that this is because it has a processor 
specific type, rather than a generic section type, although
I have not verified this.

The correct way to solve this would be to use your own linker
script.  Then you can the start address of the text section
and any other section you like, and make sure that the sections
are loaded where you want them to be loaded.

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: file stripping with a non root account seems problematic.

[Nick Clifton]

Hi Kyle,

> $ strip --strip-unneeded libubsec.so
> strip: unable to copy file 'libubsec.so'; reason: Permission denied
> 
> In rename.c
> on an existing file;
> prior to invoking function creat
> the file must unlinked?

Hmm, this sounds like a possible file permission issue.

Can you provide a more extensive test case ?  One where you explicitly 
set the file permissions before running strip, so that I can try 
reproducing the problem locally.

Cheers
  Nick


___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: Problems in as.1

[Nick Clifton]

Hi Eric,

> Problems with as.1:
> 
> Your Synopsis is exceptionally creative.  Unfortunately, that means
> it cannot be translated to structural markup even when things like
> running-text inclusions have been moved elswhere.
> 
> This page was generated from some sort of non-man markup.  Please
> fix the upstream markup so that it generates a well-formed
> manual page with the indicated corrections.
> 
> --- as.1-unpatched2014-06-01 20:05:07.053475183 -0400
> +++ as.1  2014-06-01 20:05:06.269457562 -0400
> @@ -158,6 +158,7 @@
>[\fB\-\-target\-help\fR] [\fItarget-options\fR]
>[\fB\-\-\fR|\fIfiles\fR ...]
>   .PP
> +.SH TARGET-SPECIFIC OPTIONS
>   \&\fITarget AArch64 options:\fR
>  [\fB\-EB\fR|\fB\-EL\fR]
>  [\fB\-mabi\fR=\fI\s-1ABI\s0\fR]


I found that I was unable to call the new section "TARGET-SPECIFIC OPTIONS", 
so instead I have opted for "TARGET".  This is probably due to my non-existent 
Perl programming skills, but anyway.  So I have checked in the attached patch 
in order to fix the problem.

Cheers
  Nick

gas/ChangeLog
2016-03-18  Nick Clifton  <ni...@redhat.com>

* doc/as.texinfo: Place the target specific command line options
into their own man page section.

etc/ChangeLog
2016-03-18  Nick Clifton  <ni...@redhat.com>

* texi2pod.pl: Add TARGET to the list of recognised man page
sections.
diff --git a/etc/texi2pod.pl b/etc/texi2pod.pl
index cd0ffd9..dd3e181 100644
--- a/etc/texi2pod.pl
+++ b/etc/texi2pod.pl
@@ -340,7 +340,7 @@ die "No filename or title\n" unless defined $fn && defined $tl;
 $sects{NAME} = "$fn \- $tl\n";
 $sects{FOOTNOTES} .= "=back\n" if exists $sects{FOOTNOTES};
 
-for $sect (qw(NAME SYNOPSIS DESCRIPTION OPTIONS ENVIRONMENT FILES
+for $sect (qw(NAME SYNOPSIS TARGET DESCRIPTION OPTIONS ENVIRONMENT FILES
 	  BUGS NOTES FOOTNOTES SEEALSO AUTHOR COPYRIGHT)) {
 if(exists $sects{$sect}) {
 	$head = $sect;
diff --git a/gas/doc/as.texinfo b/gas/doc/as.texinfo
index a0584d3..7b36931 100644
--- a/gas/doc/as.texinfo
+++ b/gas/doc/as.texinfo
@@ -246,8 +246,10 @@ gcc(1), ld(1), and the Info entries for @file{binutils} and @file{ld}.
  [@b{--target-help}] [@var{target-options}]
  [@b{--}|@var{files} @dots{}]
 @c
+@c man end
 @c Target dependent options are listed below.  Keep the list sorted.
 @c Add an empty line for separation.
+@c man begin TARGET
 @ifset AARCH64
 
 @emph{Target AArch64 options:}
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Re: [Bug ld/19623] regression: erroneous relocation for symbols in absolute section (vma == 0)

[Nick Clifton]

> Yes, the backport is fine with me.
> 
> Can the OP commit it ?

I think not, so I have taken the liberty and applied it myself.

Cheers
  Nick

___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils