https://sourceware.org/bugzilla/show_bug.cgi?id=30493
--- Comment #2 from Tom Kacvinsky ---
While binutils now understand how to write a PDB file, it needs the appropriate
CodeView debug information in the object files/libraries fed to it. As things
stand, GCC does not yet produce the CodeView d
https://sourceware.org/bugzilla/show_bug.cgi?id=30493
--- Comment #1 from Tom Kacvinsky ---
(In reply to Tom Kacvinsky from comment #0)
> gcc -o hello -Wl,--pdb hello.c
That should be "gcc -g -o hello -Wl,--pdb hello.c"
--
You are receiving this mail because:
You are on the CC list for the bu
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: tkacvins at gmail dot com
Target Milestone: ---
This is a placeholder for an issue I have with PDB files generated by ld --pdb.
I am using MSYS2 + MinGW-w64, with a
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #16 from Tom Kacvinsky ---
(In reply to Tom Kacvinsky from comment #14)
> The files in this archive contain dumps of files generated by binutils 2.36
> and 2.36. The .p files were generated by "objdump -p" and the .s files were
>
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #15 from Tom Kacvinsky ---
I am on vacation. When I get back, I will also upload the .exp file as
generated by the Visual Studio tool chain. Because the final link done via
gnatdll works with that .exp file, but not the one gener
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #14 from Tom Kacvinsky ---
Created attachment 14887
--> https://sourceware.org/bugzilla/attachment.cgi?id=14887&action=edit
Dump of files as generated by binutils 2.35 and binutils 2.36
The files in this archive contain dumps of
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #12 from Tom Kacvinsky ---
(In reply to Eric Botcazou from comment #11)
> > The problem is an access violation at startup, deep in the guts of the DLL
> > loader. Doing a debug session with Visual Studio and looking at registers
>
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #10 from Tom Kacvinsky ---
The problem is an access violation at startup, deep in the guts of the DLL
loader. Doing a debug session with Visual Studio and looking at registers and
memory locations, it was determined that loading t
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #8 from Tom Kacvinsky ---
I think it was actually this commit
dc9bd8c92af67947db44b3cb428c050259b15cd0
That had pep_dll_enable_reloc_section = 1 only if --enable-dynamicbase was
specified (which we hadn't been doing). Later on i
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #7 from Tom Kacvinsky ---
I don't understood _why_ those patches introduced the issue.
Looking at them, one was from 2018, and the problem started sometime after
2019, and the other patches are changing ld options for DLL characte
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #5 from Tom Kacvinsky ---
I've conflated things. The issues of building binutils 2.34 and 2.35 on
MinGW-w64 is a separate issue (perhaps an issue the MInGW-w64 folks know about
and could help solve my build problems without hacks)
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #4 from Tom Kacvinsky ---
Created attachment 14882
--> https://sourceware.org/bugzilla/attachment.cgi?id=14882&action=edit
pep.em patch
Attached is the patch for pep.em that fixed the problem in binutils 2.34
--
You are receiv
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #3 from Tom Kacvinsky ---
Have a different take on this issue now. I was able to get 2.34 working. I
had to modify pep.em to get it to build on MSYS2 + MinGW-w64.
The commit that was partially reverted was 1ff6de031241. In that
https://sourceware.org/bugzilla/show_bug.cgi?id=30448
--- Comment #2 from Tom Kacvinsky ---
Yes, --disable-reloc-section is a viable workaround. And it can be added to
the gnatdll option -largs (which is the option that allows you to specify
options to the linker).
I would have to check to see
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: tkacvins at gmail dot com
Target Milestone: ---
I found an issue when generating a DLL via gnatdll.
The issue was introduced btween 2.33.1 and 2.34, and I believe it was this
specific commit dc9bd8c92af6
https://sourceware.org/bugzilla/show_bug.cgi?id=30187
--- Comment #16 from Tom Kacvinsky ---
Nick,
Worked great! Thanks!
Tom
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30187
--- Comment #11 from Tom Kacvinsky ---
Hi Nick,
This worked perfectly. The linker didn't throw the PHDR error, and the
resulting executable now has the binutils version in the .comment section.
Thank you very much for your work on this. So
https://sourceware.org/bugzilla/show_bug.cgi?id=30187
--- Comment #9 from Tom Kacvinsky ---
(In reply to Nick Clifton from comment #7)
> Created attachment 14751 [details]
> Proposed patch
>
> Hi Tom,
>
> (Sorry for the delay in updating this PR).
>
> Please could you try out this revised
https://sourceware.org/bugzilla/show_bug.cgi?id=30187
--- Comment #8 from Tom Kacvinsky ---
Created attachment 14752
--> https://sourceware.org/bugzilla/attachment.cgi?id=14752&action=edit
simple C reproducer file
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30187
--- Comment #6 from Tom Kacvinsky ---
I found an issue with the patch. I applied against master and built it. I
then used gcc 12.1.0 and got this:
$ /opt/gcc-12.1.0/bin/gcc -B /opt/binutils-2.40-version/bin -fuse-ld=bfd -o
wchar wchar.c
/o
https://sourceware.org/bugzilla/show_bug.cgi?id=30187
--- Comment #5 from Tom Kacvinsky ---
(In reply to Nick Clifton from comment #4)
> (In reply to Nick Clifton from comment #3)
>
> > What do you think of the this patch ?
>
> I have discovered a flaw in the patch. :-(
>
> Since the ver
https://sourceware.org/bugzilla/show_bug.cgi?id=30187
--- Comment #2 from Tom Kacvinsky ---
(In reply to Nick Clifton from comment #1)
> (In reply to Tom Kacvinsky from comment #0)
> Hi Tom,
>
> > Results in the ld.gold version not being in the .comment section.
>
> But - just to be clear - i
https://sourceware.org/bugzilla/show_bug.cgi?id=30187
Tom Kacvinsky changed:
What|Removed |Added
CC||tkacvins at gmail dot com
--
You
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: tkacvins at gmail dot com
CC: ian at airs dot com
Target Milestone: ---
Using a simple "hello world!" program
#include
int main(int argc, char** argv)
{
https://sourceware.org/bugzilla/show_bug.cgi?id=27206
--- Comment #6 from Tom Kacvinsky ---
For compatibility reasons, I want to update my automated build machine, but
build GCC and auxiliary support libraries in such a fashion that we can target
older Linux distributions That is, build on a mach
https://sourceware.org/bugzilla/show_bug.cgi?id=27206
--- Comment #4 from Tom Kacvinsky ---
This worked for me in my simple reproducer, but unfortunately we are doing
"naughty" things with third party code build such that a linker map is not an
option, unless we hack that library's build process.
https://sourceware.org/bugzilla/show_bug.cgi?id=27206
--- Comment #2 from Tom Kacvinsky ---
I know you mentioned this message comes from the referenced PR, but is what I
am seeing an unintended consequence of the change made in this PR, or is this
expected behavior?
--
You are receiving this ma
Assignee: unassigned at sourceware dot org
Reporter: tkacvins at gmail dot com
Target Milestone: ---
Created attachment 13134
--> https://sourceware.org/bugzilla/attachment.cgi?id=13134&action=edit
Reproducer code
The attached code, when built with
gcc -fPIC -o thread.so
28 matches
Mail list logo
